From assistance to bounded AI authority

Most industrial AI today assists: it predicts, reports or recommends, and a qualified person closes the decision. Bounded authority is the point where an AI model can carry a defined decision inside stated conditions and hand back when those conditions no longer hold.

Capture, Expand and Reinvent are commercial development horizons, distinct from the technical Design, Production and Controlled Evolution loops. They are not a required sequence: customers may enter directly into a justified redesign programme. This article describes one practical path. For why prediction alone leaves decisions with people, read Why prediction is not enough when machines must decide. For what the model returns, read The integrated decision object.

Pick one consequential problem the business already funds: an existing learned model, a model-design or diagnosis problem, an operational decision, a product function, a subsystem-design constraint or an application-specific assurance problem. Agree one measurable success criterion before any model work begins.

Phase 1 is a funded engagement, typically three to six months, addressing a consequential model, decision, function or programme the customer has already prioritized. Agree the success criterion at scoping: economic, operational, technical, mission-related, quality-related, product-related or assurance-related. Work uses the customer's data and engineering environment, within its constraints. Phase 2 is a potential agreed extension across models, systems, assets, processes or products, informed by Phase 1 results and evidence.

The capability being evaluated is assessed against the customer's agreed success criterion and engineering constraints. Where the application involves an operational decision, the customer defines how the model output is used, including when the system may act, hold or escalate. Other engagements may focus on model design, structural diagnosis, product functions or engineering margins.

The agreed KPI, measured against the current baseline, shows the application's performance and economics in practice. That result is what informs how wide Phase 2 should be.

A useful starting point is a consequential problem with an identifiable owner and an existing cost or performance constraint, rather than a broad ambition to transform an entire process. Define what is constrained today, what evidence is missing, how the current situation is handled and what measurable change would justify further investment. This makes the assessment about an industrial or engineering outcome rather than a model demonstration.

Choose a KPI that can be compared with the current way of working. Expert effort, scrap or downtime may be relevant, but the choice belongs to the application. Define the baseline, the measurement period and the conditions under which a comparison is meaningful. A better prediction score is useful evidence; on its own it does not show that the decision's economics have improved.

Before evaluation, identify the constraints that do not change: physical and engineering limits, operating conditions, qualification requirements and customer responsibilities. For operational decisions, specify when the surrounding system may act, hold or escalate. For model-design or product-engineering work, define the required validation of any proposed model or design change. A hold is a system state, not necessarily a request for human review.

The practical output of Capture is therefore more than a model. It is an assessment against an agreed baseline, using the customer's own tools and processes, with the conditions and unresolved exceptions visible. If the evidence does not support the intended use, the decision can remain assisted or its proposed scope can be narrowed.

Engineering judgment stays central. In one anonymized programme, a sensor that a global ranking would have rated low was retained for safety reasons once its role was visible; the full example is in What signal-level explanation means.

Evidence from the first engagement can support extending to more models, additional decisions, more equipment or assets, other sites or processes, and additional product variants or functions. Expansion does not necessarily mean increasing delegated authority. Each extension is a separate decision, made on measured results and an assessment of applicability to the new context.

Where an expansion concerns bounded decisions, customer rules define when a decision may be acted on, the surrounding system keeps control, and exceptions are handled by people. Expert attention shifts toward the cases that need it.

The question at this stage is not simply whether the first model performed well. It is whether the evidence covers the next proposed scope. Another asset or site may have different inputs, operating conditions or constraints. Identify those differences before carrying over a conclusion. Results from one bounded use do not establish the performance or economics of another.

A practical expansion review brings together the measured KPI, the conditions represented in the evaluation, the exceptions encountered and the engineering team's conclusions. It then asks what evidence is missing for the proposed extension. The next decision needs its own assessment criteria and customer approval, even when it reuses learning from the first engagement.

Keep the exception path in the economics. A wider scope that sends more cases to experts may not deliver the intended benefit. Conversely, a deliberately limited scope may be useful without covering every condition. Expansion is a choice about where demonstrated capabilities and evidence can be applied next. When it involves delegated decisions, the customer determines the permitted scope and exception handling. Other forms of expansion concern models, engineering work, assets, sites or product functions without changing delegated authority.

When learned models provide better-characterized estimates, structural understanding and supported decision capabilities, a wider design space may open. Processes, subsystems, material requirements, product functions, sensor architectures and operating models can then be examined under the customer's engineering constraints.

Reinvention can involve subsystem design, product architecture, material requirements, services or operating models around Xpdeep’s native architecture. Equipment may be designed around model-estimated states rather than conservative uncertainty margins, subject to customer engineering validation. It is a direction to evaluate, not a delivered result or a promise. Capture is valuable on its own.

For processes, the design question is whether operating margins or the organization of decisions could be reconsidered once the actual state is better understood. For products, it is whether a function previously held back by uncertainty merits evaluation. Neither question changes a customer's hard limits or establishes that a new function is ready to use.

Sensor architecture is another design question: which inputs serve overall prediction, and which matter in particular regions? The retained-sensor example above shows why a simpler architecture cannot be inferred from a global ranking. Operating models raise a different question: how should expert effort be organized when routine decisions and exceptions can be distinguished under customer rules?

These possibilities belong in a design agenda with evidence requirements, not in the first engagement's promised results. The Applications page develops the transformation patterns. Use them to frame questions worth evaluating for a justified redesign programme, rather than as proof that an application will achieve them.

The surrounding system remains in control. Xpdeep supplies model-level inputs; it is not the system's safety authority, and model corrections are targeted and validated between operating periods, not learned continuously.