Where inference sits, and where human judgement stays

← Architectures

Reference structure · Applied AI · Technology × Organisations

One arrangement for placing model inference inside existing systems while keeping accountability, review and fallback explicit.

This is one possible structure, not a target state and not a record of a system observed in a specific environment. It is useful while its assumptions hold, and it says where a different arrangement would fit better.

The structural question

Which decisions should a model act on directly, and where must a person remain between the inference and the effect?

Components

Each part is here for a reason: what it owns, and what it depends on.

• Decision inventory

  Owns: The record of which decisions are in scope and what their cost of error is.

  Depends on: Depends on decisions being nameable; where they are not, scoping is guesswork.

• Context supply

  Owns: What data reaches the model, and under what permission.

  Depends on: Depends on upstream ownership and consent boundaries already being clear.

• Model layer

  Owns: Inference. It owns no entity and is not a source of record.

  Depends on: Depends on being replaceable; models change faster than the systems around them.

• Review and guardrails

  Owns: Whether an inference is allowed to act, and what is retained about the decision.

  Depends on: Depends on a person or rule being accountable for the class of decision, not for each output.

• Acting system

  Owns: The effect — the message sent, the price changed, the case routed.

  Depends on: Depends on a defined behaviour for when inference is unavailable or refused.

Ownership and source of record

The model owns no entity. Accountability stays with the system and the team that owns the affected decision — a boundary that tends to blur when a model is introduced as a shared platform capability.

Movement through the structure

1. 01

   Decision inventory

2. 02

   Context supply

3. 03

   Model layer

4. 04

   Review and guardrails

5. 05

   Acting system

6. 06

   Retained record

The structurally important arrows are the ones usually left out: what is retained about each inference, and what the acting system does when the model returns nothing.

Dependencies

The question is whether the dependency matches what the organisation needs.

Intentional coupling

Inference and retained record belong together. An inference that cannot be reconstructed cannot be reviewed after it is wrong.

Costly coupling

Embedding a specific provider's interface throughout the acting systems couples product behaviour to a vendor's model lifecycle.

What is hard to reverse

Keeping inference behind an internal boundary preserves the ability to change model or provider. What becomes embedded is the workflow assumption that a decision no longer needs a person.

When something fails

When inference is unavailable, the acting system should fall back to a defined behaviour rather than block. When inference is wrong, the question is what surfaced it — the retained record, or the customer.

Assumptions

A reference structure is only reusable when its assumptions travel with it.

What must hold

If these are not true in a given environment, the structure is the wrong starting point.

• The decisions in scope can be named and their cost of error estimated.
• Context needed by the model can be supplied within the permissions that already exist.
• There is capacity for review at the volume the decision occurs.
• Model behaviour will change over the life of the surrounding system.

Trade-offs

Each improves something and costs something. Neither side is universally preferable.

• Speed of an automated decision against the review that would have caught the error.
• Provider convenience against portability of the inference boundary.
• Broader coverage against the difficulty of monitoring what the model is doing.

What this makes possible

Inference can be introduced where the cost of error is understood, and withdrawn without redesigning the systems around it.

What it constrains

It slows introduction, requires accountability to be named before deployment, and rules out treating a model as an autonomous layer over the business.

How you would know whether it helped

Whether error is detected internally before it reaches a customer, and whether review load falls or simply moves.

What informed this

Technical reasoning about failure behaviour and provider dependency, published vendor documentation on model interfaces, and observed situations where adoption stalled at review capacity.

Another structure may fit when

Another structure may fit when inference is confined to a single low-consequence surface; the provider's own tooling may be enough until a second surface appears.

Where this stops fitting

Stops fitting where decisions cannot be named, where no review capacity exists, or where the cost of an individual error is low enough that the structure is overhead.

Related

Related reading

Industry

• Retail
• BFSI
• Logistics
• Consumer Technology
• Enterprise SaaS
• Healthcare

Knowledge · Playbook

• Deciding Which Decisions to Delegate to AI
• When the Organisation Waits on One Person

Evidence · Observed Situation

• When routine decisions were being escalated because no system carried the context

The situations linked above informed this representation. They do not establish that this structure is right for another environment — that remains a question about the specific organisation, its ownership and its constraints.

Architecture, as a question →Work with Cralgo →