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 a learned model can carry a defined decision inside stated conditions and hand back when those conditions no longer hold.

Companies rarely get there in one step. This article describes a 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 decision the business already pays for, in expert time, conservative margins, scrap, downtime or extra sensing, and agree one measurable KPI before any model is built.

In practice, Phase 1 is a 3 to 6 month delivery on a model or loop the customer already funds, using the customer's data and a KPI set at scoping. Phase 2, the potential extension across a fleet, line or portfolio, is named at the same time. Phase 1 ends with a decision about Phase 2's scope; it is not a verdict on whether Xpdeep works.

The model's decision object is then assessed inside the customer's existing rules and engineering constraints. The customer's system decides whether to act, hold or escalate; your team validates the model with its own tools and processes.

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 decision with an identifiable owner and an existing cost, not a broad ambition to automate a whole process. Write down what is decided, how often it is decided, what evidence the decision uses today and what happens when the answer is uncertain. That makes the assessment about a business decision 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: engineering limits, operating conditions, qualification requirements and who handles exceptions. Specify what the customer system may act on, what it must hold and what it must escalate. A hold is a system state, not necessarily a request for a person; expert review belongs where the customer's exception rules require it.

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 decision can support extending bounded authority to further decisions, assets, sites or product lines. Each extension is a separate decision, made on measured results.

What does not change: 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 which decisions can be carried under explicit rules, not a requirement to eliminate people from the process.

As more decisions can be carried within stated conditions, a wider design space opens: processes, products, sensor architecture and operating models may be reconsidered.

Transform is a direction to evaluate, not a delivered result or a promise. Capture is valuable on its own; nothing in it depends on going further.

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 after Capture, 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.