The Bespoke AI Business Case: From Token Costs to Operating Leverage

A metrics-heavy framework for comparing packaged AI, internal development and a partner-built enterprise system using total cost, accepted outcomes, risk and strategic control.

Executive answer

The financial case for bespoke enterprise AI should never begin with model enthusiasm. It should begin with an operating constraint that has a measurable cost.

Examples include:

• clinicians spending time correcting medical transcripts;
• logistics teams manually chasing shipment exceptions;
• factory supervisors reconciling employee, fuel and production records;
• advisers searching policy and product documents;
• contact-center agents moving between five systems during one call;
• legal teams reviewing the same clause patterns across thousands of documents;
• field technicians documenting work after leaving the asset.

A bespoke system is justified when it can change the economics of that workflow after accounting for implementation, inference, integration, human review, errors, governance, support and switching.

The correct financial unit is not cost per token, seat or API call. It is:

total cost per accepted business outcome

An accepted outcome is one that meets the enterprise's quality threshold, requires no unplanned rework, respects policy and reaches the correct system of record.

This article provides a complete decision model. It also explains why commissioning a specialist can outperform both packaged software and a fully internal build. The enterprise retains the business-specific assets and operating control. The specialist supplies the concentrated engineering needed to turn models, data and workflows into a production system.

Why the visible AI price is usually the wrong number

Procurement sees prices that are easy to compare:

• a per-user monthly license;
• input and output token rates;
• speech minutes;
• GPU hours;
• a platform subscription;
• an implementation statement of work.

The lowest visible price can produce the highest operating cost if the system has weak adoption, poor retrieval, high correction rates, excessive latency or expensive integration.

In its 2024 enterprise analysis, Andreessen Horowitz reported one executive's estimate that “LLMs are probably a quarter of the cost of building use cases.” The quote is anecdotal, not a universal budget ratio. It is directionally important. Model access is only one line in the cost structure.

Menlo Ventures' 2024 enterprise report reinforces the point. Its surveyed buyers ranked measurable value and industry-specific customization well above the lowest price. It also reported unexpected implementation cost as a contributor in 26% of failed pilots, ahead of data privacy at 21%, disappointing ROI at 18% and hallucinations at 15%.

The business case must therefore model the complete production system.

A nine-part total cost of ownership model

Calculate enterprise AI TCO across an agreed period, normally three years for procurement comparison and one year for operating management.

1. Discovery and workflow redesign

This includes process mapping, baseline measurement, stakeholder time, data-access analysis, risk classification and operating-design work.

It is tempting to classify discovery as consulting overhead. That is a mistake when the existing process contains undocumented exceptions, shadow approvals and workarounds. Automating the process as described in policy rather than as performed in reality produces a polished system that users bypass.

Measure discovery with:

• number of process variants mapped;
• percentage of exception categories represented;
• baseline handling time and error rate coverage;
• percentage of required systems and data owners identified;
• unresolved policy decisions before build begins.

2. Data preparation and knowledge engineering

This includes extraction, cleaning, segmentation, labeling, taxonomy, metadata, access controls, temporal validity and source-ranking rules.

A 10,000-document repository is not automatically an AI-ready knowledge base. The same policy can exist in draft, approved and superseded versions. A retrieval system that ignores effective date can return a semantically relevant but operationally wrong answer.

Measure:

• document coverage and freshness;
• metadata completeness;
• permission accuracy;
• retrieval recall at the required depth;
• duplicate and superseded-content rates;
• label agreement between domain experts;
• cost per validated example.

3. Model and inference cost

Include:

• commercial model API charges;
• speech recognition and speech generation;
• embeddings and reranking;
• self-hosted compute;
• model routing and fallback calls;
• repeated calls in agent loops;
• evaluation traffic;
• idle capacity and peak headroom for hosted models.

An agent request is not one model call. It may classify intent, retrieve, rerank, generate, call a tool, validate the result and retry. Estimate calls per completed outcome, not calls per user message.

4. Application and integration engineering

Include connectors, identity, authorization, workflow state, APIs, queues, retries, interfaces, observability and error handling.

Integration is often where packaged software loses its apparent cost advantage. If the product supports only a generic connector, the enterprise may still need a parallel integration team. Conversely, a packaged product with mature native integration can be much cheaper than custom work.

5. Evaluation and assurance

Include expert rubric design, test-set creation, automated evaluation, human review, adversarial tests, security testing, performance tests and release regression.

Evaluation is not a one-time acceptance test. Every model, prompt, retrieval, policy or data change can alter behavior. Morgan Stanley's public implementation used expert evaluations and daily regression testing. That discipline is part of the operating cost, and likely part of why the system reached high adoption.

6. Human review and exception handling

Human-in-the-loop is not free. Calculate:

• percentage of outputs requiring review;
• average review minutes;
• loaded reviewer cost;
• escalation percentage;
• average exception resolution time;
• rework caused by false acceptance;
• queue delay at peak volume.

A system with 95% model accuracy can still be uneconomic if every output must be reviewed as carefully as manual work. The target is not simply higher accuracy. It is lower effort at the required residual risk.

7. Error and risk cost

Not all errors have the same consequence. Assign severity classes.

For high-severity errors, expected-value math is not enough. A low-probability catastrophic error may require a deterministic control or human approval even when the average ROI would support autonomy.

NIST's Generative AI Profile recommends governing, mapping, measuring and managing risk across the AI lifecycle. That means risk controls belong in architecture and TCO, not in a legal review after the build.

8. Adoption and change cost

Include training, communication, workflow updates, product support, user research and management attention.

A tool that saves five minutes when used but reaches 10% adoption saves less than a tool that saves three minutes at 80% adoption. Model expected annual value as:

eligible volume × adoption × acceptance × value per accepted outcome

All four terms matter. A demonstration usually proves only that the system can generate an output. It does not prove eligible volume, adoption, acceptance or realized value.

9. Operations, maintenance and exit

Include:

• monitoring and incident response;
• data-source changes;
• model and API migrations;
• prompt and policy updates;
• retraining or adapter refresh;
• evaluation expansion;
• uptime and disaster recovery;
• security patches;
• vendor management;
• documentation and transition assistance.

IBM's 2026 AI sovereignty survey found that 71% of 1,000 surveyed executives said changing a primary AI vendor or model would be difficult. Among respondents that switched or attempted to switch, 75% described the process as difficult. IBM sells technology and services, so this is not neutral market evidence. The underlying cost categories, such as data portability, revalidation, compliance and technical coupling, are concrete and should appear in a buyer's exit model.

The core equations

Use the following model for each option.

Annual benefit

annual benefit = labor capacity released + avoided loss + incremental contribution margin + working-capital benefit + risk reduction

Do not automatically count released hours as cash savings. Time becomes financial value only if the company reduces external spend, avoids hiring, increases throughput, improves revenue or reallocates capacity to measured work.

Annual run cost

annual run cost = licenses + inference + hosting + support + review + monitoring + maintenance + expected remediation

Implementation-adjusted three-year TCO

3-year TCO = initial implementation + year 1 run cost + year 2 run cost + year 3 run cost + expected migration cost

Cost per accepted outcome

cost per accepted outcome = total run cost / accepted outcomes

Where:

accepted outcomes = eligible volume × adoption × technical completion × quality acceptance

Risk-adjusted net present value

risk-adjusted NPV = discounted benefits - discounted costs - probability-weighted loss - option penalty

The option penalty represents lost flexibility. Examples include a proprietary data format, a fine-tune that cannot be exported, a workflow tightly coupled to one vendor's agent runtime or missing evaluation data needed to revalidate a replacement.

Payback period

payback months = initial implementation / monthly net realized benefit

Use realized benefit after adoption and review cost, not the maximum benefit in the sales demonstration.

A worked example: high-volume enterprise case handling

The following example is an illustrative decision model, not a Conscious Engines client result and not a forecast. Replace every assumption with measured enterprise data.

Baseline assumptions

A regulated service operation handles 600,000 cases per year.

• Average manual handling time: 12 minutes.
• Loaded labor cost: $35 per hour.
• Baseline annual handling labor: 120,000 hours.
• Baseline direct labor value: $4.2 million.
• Avoidable rework rate: 8% of cases.
• Average rework time: 10 minutes.
• Annual rework labor: 8,000 hours, or $280,000.

Three options are considered.

Option A: packaged AI assistant

Illustrative assumptions:

• Initial integration and rollout: $250,000.
• Annual licenses and support: $480,000.
• Adoption: 65% of eligible cases.
• Technical completion: 85%.
• Quality acceptance without full rework: 72%.
• Average time reduction on accepted cases: 5 minutes.
• Human review: 2 minutes per technically completed case.

Accepted outcomes:

600,000 × 0.65 × 0.85 × 0.72 = 238,680

Gross handling capacity released:

238,680 × 5 minutes = 19,890 hours

Gross labor value:

19,890 × $35 = $696,150

Review cost:

600,000 × 0.65 × 0.85 × 2 minutes / 60 × $35 = $386,750

Year-one direct net before error, change and opportunity effects:

$696,150 - $386,750 - $480,000 - $250,000 = -$420,600

The packaged option is fast, but under these assumptions it does not pay back from labor capacity alone. It may still be correct if the value comes from customer experience, risk reduction or revenue.

Option B: fully internal build

Illustrative assumptions:

• Initial product, data, model, security and integration work: $1.8 million.
• Annual run team and infrastructure: $1.15 million.
• Adoption: 80%.
• Technical completion: 92%.
• Quality acceptance: 88%.
• Average time reduction: 7 minutes.
• Human review: 1.2 minutes per technically completed case.

Accepted outcomes:

600,000 × 0.80 × 0.92 × 0.88 = 388,608

Gross handling capacity released:

388,608 × 7 minutes = 45,337.6 hours

Gross labor value:

45,337.6 × $35 = $1,586,816

Review cost:

600,000 × 0.80 × 0.92 × 1.2 minutes / 60 × $35 = $309,120

Year-one direct net:

$1,586,816 - $309,120 - $1,150,000 - $1,800,000 = -$1,672,304

Steady-state annual direct net before other benefits:

$1,586,816 - $309,120 - $1,150,000 = $127,696

The internal build produces better operating performance but carries a heavy permanent team. It only becomes attractive if the platform supports additional workflows, the value per accepted outcome is higher, or strategic control justifies the investment.

Option C: bespoke partner-built system

Illustrative assumptions:

• Initial discovery, data, evaluation, build and integration: $900,000.
• Annual inference, monitoring, maintenance and support: $650,000.
• Adoption: 80%.
• Technical completion: 92%.
• Quality acceptance: 88%.
• Average time reduction: 7 minutes.
• Human review: 1.2 minutes per technically completed case.

The operating output matches the internal option in this illustration because both systems are benchmarked against the same specification.

Year-one direct net:

$1,586,816 - $309,120 - $650,000 - $900,000 = -$272,304

Steady-state annual direct net:

$1,586,816 - $309,120 - $650,000 = $627,696

Simple payback after launch:

$900,000 / ($627,696 / 12) = approximately 17.2 months

Three-year undiscounted net benefit:

3 × $1,586,816 - 3 × $309,120 - 3 × $650,000 - $900,000 = $983,088

This is not evidence that a bespoke build will produce these numbers. It demonstrates the condition under which it wins: custom performance close to an internal system, without the full fixed cost of maintaining a permanent specialist team.

Sensitivity analysis

The same bespoke option changes materially when acceptance or adoption moves.

The table assumes 92% technical completion, seven minutes saved per accepted case, 1.2 minutes of review for completed cases, $35 hourly labor and$650,000 annual run cost. It is deliberately sensitive to adoption and acceptance. Those are operating metrics the implementation must earn.

Why a partner-built system can beat both alternatives

The economic advantage is not simply lower engineering rates. It comes from changing the structure of the work.

Concentrated specialist utilization

A production AI system may need an ASR engineer, data engineer, ML engineer, application engineer, security architect, evaluation lead, product manager and domain experts. An enterprise may need each role intensely for part of the build but not as a permanent full-time team.

A specialist partner can reuse operating knowledge, evaluation infrastructure, deployment patterns and integration components while customizing the business layer. The customer buys focused capability during the period when it is needed.

Faster diagnostic convergence

Many AI projects waste time treating every quality problem as a prompting problem. A specialist should distinguish among:

• bad input capture;
• missing or stale knowledge;
• retrieval failure;
• model reasoning failure;
• inconsistent output behavior;
• incorrect tool selection;
• permission or policy failure;
• user-interface and adoption failure.

Each has a different remedy. More training data cannot fix a broken authorization rule. A larger model cannot recover audio that speech recognition discarded. RAG cannot reliably enforce an approval limit without deterministic workflow logic.

A reusable evaluation system

The enterprise evaluation set is one of the most valuable outputs of bespoke development. It turns expert judgment into a versioned test. It can compare model providers, protect against regressions and define release acceptance.

That is why the evaluation asset should belong to the enterprise. For a deeper treatment, see why the evaluation set becomes an AI moat.

Variable architecture rather than vendor loyalty

The architecture can route different tasks to different components:

• a deterministic rule for a hard policy;
• a small classifier for high-volume routing;
• a domain ASR model for noisy speech;
• retrieval for current facts;
• a task-specific SLM for stable structured output;
• a frontier model for low-volume complex reasoning;
• a human for high-severity ambiguity.

This usually produces better economics than sending every task to the same model. The detailed model-efficiency argument is covered in why the right model is rarely the biggest.

Explicit transfer and exit

A partner engagement can be designed to end with customer-controlled artifacts, documented interfaces and an agreed operating model. Internal capability grows without requiring the enterprise to discover every production failure mode alone.

Public company evidence through an economic lens

The company cases below show different ways to allocate cost and ownership.

Morgan Stanley: evaluation turned access into adoption

Morgan Stanley's system used purchased foundation capability, but the operating investment went into private retrieval, expert evaluation, daily regression, security arrangements and workflow integration.

The company reported more than 98% adviser-team adoption, document access rising from 20% to 80%, and retrieval across 100,000 documents. The public case study also reported that meeting follow-ups that once took days could happen within hours.

The economic lesson is not the absolute size of those gains, which was not fully disclosed. It is the mechanism. Evaluation and integration increased trust and reduced friction. That improved adoption, one of the multipliers in the value equation.

Uber: route for quality and cost rather than standardize on one model

Uber's model gateway combined external and internally hosted models, added cost attribution and protected data. In July 2024, the company reported 16 million monthly queries across close to 30 internal teams.

Uber explicitly stated that external models served broad knowledge and difficult reasoning, while fine-tuned open models could perform Uber-specific tasks with lower cost and latency. Its Michelangelo account also warned that deep learning was not automatically superior, noting that XGBoost outperformed it on performance and cost in several cases.

That is disciplined model economics. Use the least expensive architecture that clears the business threshold. Keep high-capability models available for the tasks that need them.

Intuit: proprietary data justified a custom financial layer

Intuit reported 400,000 financial attributes per small business, 55,000 per consumer and connections to more than 24,000 financial institutions. It created custom financial LLMs and a runtime that selects the model and data sources for each request.

The Intuit announcement also reported 730 million AI-driven interactions per year and 58 billion machine-learning predictions per day. At that scale, small improvements in routing, latency, acceptance and inference cost can compound. The data layer can also differentiate the customer experience.

The lesson for a smaller enterprise is not to copy GenOS. It is to ask whether proprietary data changes outcomes enough to justify a custom layer.

BBVA: horizontal purchase plus thousands of custom workflows

BBVA bought enterprise access, but the reported value appeared in configured and internally created workflows. The bank reported more than 20,000 custom GPTs, around 4,000 in frequent use and 83% weekly active usage. One assistant reportedly reduced average query handling time from 7.5 minutes to about one minute.

The case shows how buy and build can be complementary. A horizontal platform reduced experimentation friction. Workflow-specific assets captured local value. A company should not force every useful customization through a central bespoke program, but it should identify repeated, high-value workflows that need stronger engineering, integration and assurance.

Walmart: domain data can justify a specialist model family

Walmart developed retail-specific Wallaby models trained with decades of company data and designed them to work with other LLMs. The company's public description linked those models to customer experiences and action-taking service workflows.

No audited Wallaby ROI was disclosed in that announcement. The investment logic is visible: retail terminology, catalog structure, customer context and fulfillment actions are core to the product experience. Generic language capability is necessary but insufficient.

JPMorganChase: scale changes the internal-build equation

JPMorganChase reported deploying LLM Suite to more than 200,000 employees and described it as a shared controlled environment. It also reported more than 60,000 technologists, more than 6,000 applications and nearly an exabyte of data in its annual-report discussion.

That organizational scale can support a permanent internal platform. Most enterprises should not use the existence of a large bank's internal stack as proof that they should build everything themselves. The more relevant question is whether their expected project portfolio will keep an equivalent team economically utilized.

The architecture a bespoke business case should price

The words “custom model” can hide a weak estimate. Price the complete architecture.

Input layer

• domain speech-to-text;
• document OCR and layout extraction;
• structured event ingestion;
• entity resolution;
• language identification and normalization.

Knowledge layer

• source connectors;
• permission-aware indexing;
• version and effective-date management;
• hybrid retrieval;
• reranking;
• citation and provenance;
• data-quality monitoring.

Intelligence layer

• task router;
• model gateway;
• commercial and open model options;
• task-specific SLMs or classifiers;
• prompt and schema versioning;
• fine-tuning or adapters where evidence supports them;
• deterministic policy checks.

Action layer

• tool contracts;
• least-privilege credentials;
• transaction limits;
• approval gates;
• idempotency;
• rollback and reconciliation;
• human escalation.

Assurance layer

• offline evaluation;
• shadow testing;
• production sampling;
• trace and cost logging;
• drift and data-freshness checks;
• incident response;
• model replacement testing.

Experience layer

• web or mobile workflow;
• voice interaction;
• operator review queue;
• feedback capture;
• accessibility and language support;
• status and failure communication.

A vendor quote that omits these layers may be cheaper because it has priced a demonstration, not the operating system.

The metrics that should govern the investment

Quality metrics

• task success rate;
• severe-error rate;
• precision and recall by class;
• citation correctness;
• retrieval recall;
• groundedness;
• tool-selection accuracy;
• action completion rate;
• human acceptance without editing.

Time metrics

• end-to-end latency, not only model latency;
• average handling time;
• time to first useful answer;
• escalation delay;
• queue age;
• time from policy change to system update;
• time from incident to rollback.

Economic metrics

• cost per accepted outcome;
• review cost per outcome;
• rework cost;
• avoided loss;
• capacity released;
• throughput gained;
• gross-margin effect;
• payback period;
• risk-adjusted NPV.

Adoption metrics

• eligible-user activation;
• weekly active use;
• repeat usage;
• workflow coverage;
• override rate;
• abandonment rate;
• user trust by error category.

Control metrics

• percentage of calls attributable by use case;
• percentage of outputs traceable to source and version;
• percentage of actions under least privilege;
• time to switch a model;
• time to revoke a tool;
• evaluation coverage for each production version;
• recovery-point and recovery-time performance.

An executive dashboard should show business value and risk together. High usage with rising severe errors is not success. High benchmark accuracy with low workflow adoption is not success.

A 12-week evidence program before full commitment

A buyer does not need to approve a multiyear transformation on faith. It can commission an evidence program.

Weeks 1 to 2: define the economic baseline

• Select one workflow with meaningful volume or risk.
• Measure handling time, throughput, rework, errors and escalation.
• Identify the economic owner.
• Define unacceptable outcomes.
• Inventory systems, data and permissions.

Weeks 3 to 4: build the evaluation asset

• Sample representative and difficult cases.
• Create expert answers or decision labels.
• Define acceptance and severity rubrics.
• Hold out a final test set.
• Establish the manual and packaged-product baselines.

Weeks 5 to 7: run an architecture bake-off

• Test a commercial frontier model.
• Test retrieval and tool use.
• Test a smaller or task-specific model where volume supports it.
• Test the best credible packaged product.
• Measure quality, latency, review and run cost at the same threshold.

Weeks 8 to 10: integrate under constrained authority

• Connect read-only systems first.
• Add action tools with least privilege.
• Run shadow traffic.
• Capture traces and failure categories.
• Train a small user cohort.

Weeks 11 to 12: make the investment decision

• Recalculate eligible volume and adoption.
• Price production hardening and three-year operations.
• Review security and legal requirements.
• Decide buy, bespoke commission, internal build or stop.
• Define ownership and exit terms.

The approach aligns with the broader 90-day pilot-to-production framework, but the decision can still be “do not proceed” if the accepted-outcome economics fail.

Contract terms that protect the enterprise business case

A bespoke engagement should convert project spend into durable assets.

Data and derived artifacts

State that customer data remains customer data. Define permitted processing, retention, deletion and whether any data may improve models outside the engagement. Address cleaned datasets, annotations, synthetic examples and embeddings.

Evaluation ownership

The enterprise should own or retain durable rights to the evaluation cases, rubrics, test harness results and regression history. Without them, the buyer cannot independently compare a replacement model.

Model and configuration rights

Specify ownership or license rights for prompts, adapters, task-specific weights, retrieval configuration, policy rules and routing logic. Separate the partner's reusable background components from customer-specific foreground work.

Portability

Require documented interfaces, export formats, model-provider abstraction where practical, deployment configuration and transition assistance. Define what happens if a provider deprecates a model or changes commercial terms.

Observability

The enterprise needs access to task success, latency, cost, traces, model version, retrieval sources, tool actions and incidents, subject to privacy controls. A monthly invoice is not sufficient observability.

Acceptance and service levels

Tie acceptance to the enterprise evaluation set and operating thresholds. Define uptime, severe-incident response, rollback time, data freshness and remediation responsibilities.

Knowledge transfer

Require architecture documentation, runbooks, administrator training and a clear division of operating responsibility. The customer should not be dependent on one individual at either organization.

When the bespoke case should be rejected

Do not commission a bespoke system merely because AI is strategic.

Reject or delay the build when:

• the workflow has no measured baseline;
• annual volume is too small to recover implementation cost;
• the process owner cannot define a correct outcome;
• source data is inaccessible or legally unusable;
• a mature product already clears the acceptance threshold;
• integration is prohibited and manual copy-paste would erase value;
• severe errors cannot be controlled;
• no team will own adoption and operations;
• the sponsor counts all saved minutes as immediate cash savings;
• the system is a branding exercise rather than an operating priority.

The willingness to reject weak custom work is part of the case for trusting a bespoke partner.

What a Credible Bespoke AI Proposal Includes

A credible bespoke AI proposal does not default to model training. It presents an evidence-based route to an enterprise capability the buyer can operate, measure, and control.

The proposal should include:

1. A quantified baseline and target outcome.
2. A representative evaluation set.
3. A comparison of packaged, frontier, RAG, tuned and task-specific options.
4. An architecture that uses deterministic software where deterministic software is safer.
5. Cost per accepted outcome at expected volume.
6. Security, data and action-control design.
7. Production monitoring and model-refresh policy.
8. Ownership, portability and knowledge-transfer terms.
9. A phased commercial plan with stop gates.
10. A clear statement of which parts should be bought rather than built.

For the strategic sourcing decision behind this model, read build vs buy is the wrong question for enterprise AI. For the full cost categories beyond model pricing, see the hidden economics of enterprise AI.

The conclusion

Packaged AI wins when the problem is common, the product is mature and the workflow can adapt to the tool.

An internal build wins when the company has a large permanent AI portfolio, deep technical capability and a strategic reason to operate the platform itself.

A bespoke partner-built system wins in the middle: the workflow is valuable and specific, but recreating a full AI organization would be slower and more expensive than commissioning specialists.

That middle is not a compromise. For many enterprises, it is the highest-leverage allocation of capital:

• buy general intelligence;
• build only the differentiated system;
• use specialist capacity instead of permanent excess headcount;
• retain the data, evaluation, controls and operating assets;
• measure value per accepted outcome.

The enterprise is not paying Conscious Engines for tokens. It is paying to convert proprietary process knowledge into a measurable production capability.

Research note

This article uses first-party corporate engineering posts, annual-report disclosures and attributed vendor case studies, plus enterprise surveys and government risk guidance. Company results are self-reported unless noted. The worked financial model is illustrative and is not a customer outcome, quotation or forecast. Build-and-buy definitions differ across surveys, and no universal break-even point exists. Evidence reviewed through September 5, 2026.

Related Conscious Engines research

• The executive build-versus-buy decision framework
• The hidden economics of enterprise AI
• Why an enterprise evaluation set becomes an AI moat
• Why the right model is rarely the biggest
• A 90-day path from AI pilot to production

Building a Production-Ready System

Conscious Engines designs and builds bespoke AI systems around enterprise data, workflows and deployment constraints. A solution may combine domain speech-to-text, text-to-speech, voice agents, permission-aware RAG, task-specific small language models, deterministic controls and agentic workflows.

The engagement starts with the enterprise baseline and evaluation set. We compare the simplest architectures that could clear the target, measure cost per accepted outcome, and build only when the bespoke option has a defensible operating advantage. The goal is a production system with measurable value, documented control and a clear transfer path, not a permanent experiment.