Reliable AI Workflows Need Boundaries, Abstention, and Evidence

Scope note: This article extracts reusable design principles from an AI-assisted BIM, drawing interpretation and quantity workflow. The subject is not a particular model or product. It is how to allocate authority, let a system abstain honestly, and make every conclusion traceable and reproducible.

The conclusion first

A reliable AI workflow does not try to make an agent answer every question. It makes the following decisions explicit:

Which operations belong exclusively to deterministic code?
Which judgments may be delegated to an agent?
Which decisions require human adoption and approval?
Can insufficient evidence result in pending or null?
Under what conditions must the agent stop?
Can a delivered conclusion be traced to its sources, versions and human corrections?

In BIM, quantity surveying, finance, medicine and compliance, a wrong answer is not merely awkward prose. A wrong number can enter a quotation, purchase order, construction plan or accountability decision. The durable asset is therefore not the prompt. It is an authority and evidence architecture:

Human > Agent > Rule

Rules provide reproducible defaults. Agents interpret evidence that rules cannot completely describe. Humans own engineering conventions, exceptions, adoption and delivery. A rerun must never allow a lower-authority result to erase a higher-authority decision.

Separate three kinds of capability

A common mistake in AI workflow design is to express every operation as an agent task. A dependable system should first divide responsibilities among Code, Agent and Human.

Actor	Appropriate responsibility	Inappropriate responsibility
Code	Geometry transformations, unit conversion, schema validation, hashes, versions, quantity calculations and diffs	Interpreting ambiguous drawings or choosing engineering conventions
Agent	Understanding title blocks, layers, tables and text; organizing evidence; proposing candidates; choosing the next inspection	Delivering unsupported final quantities or overwriting human approval
Human	Defining conventions, handling exceptions, adopting candidates, approving and delivering	Repeating mechanical calculations that code can perform reliably

The division follows the shape of errors rather than current technology fashion.

Deterministic questions should move into code wherever possible. Equal input should produce equal output and be protected by unit and regression tests.
Semantic interpretation can move to an agent, but its output remains an evidence-backed candidate.
Decisions involving responsibility, risk or business convention remain human decisions.

The agent does not emit an unquestionable final answer, which keeps its failure radius bounded.

flowchart LR
  S[Drawing / BIM / table] --> C[Code<br/>parse · coordinates · schema · hash]
  C --> A[Agent<br/>interpret · organize evidence · candidates]
  A --> V[Code<br/>validate · calculate · regressions]
  V --> H[Human<br/>adopt · correct · approve]
  H --> D[Deliverable result]

Human > Agent > Rule is an authority order, not an execution order

All three layers may produce a value for the same field. For example:

A rule infers from a layer name that an object is a structural wall.
An agent reads the legend and nearby annotation and proposes that it is a partition.
An engineer checks a design change notice and confirms that it must be measured as structural.

If the system stores only the latest value, the next rerun may apply the rule or agent again and erase the human decision. Instead, preserve candidates and their provenance, then resolve them with an explicit priority:

type Authority = 'rule' | 'agent' | 'human';

const priority: Record<Authority, number> = {
  rule: 1,
  agent: 2,
  human: 3,
};

The value must carry its origin:

{
  "field": "wallType",
  "value": "structural",
  "status": "accepted",
  "authority": "human",
  "sourceDrawing": "A-203",
  "location": "Grid B4-B7",
  "reason": "Confirmed by design change notice DCN-17",
  "runId": "run_2026_10_04_0031",
  "decidedBy": "reviewer-12",
  "decidedAt": "2026-10-04T09:30:00Z"
}

Two kinds of power should remain distinct:

Humans hold final adoption authority.
Code retains non-bypassable contract validation.

A person can select the engineering convention, but cannot silently send malformed data, nonexistent units or schema violations into a calculation. A legitimate exception should be an explicit, reasoned, approved and versioned override—not a disabled validator.

`pending` and `null` are first-class results

Many AI systems treat an empty field as failure, implicitly rewarding the model for filling every slot. In high-risk work this converts uncertainty into a precise-looking error.

A better state model makes uncertainty explicit:

State	Meaning	Next action
`candidate`	Initial interpretation with evidence, not yet adopted	Validate or review
`accepted`	Adopted by the required authority	Permit downstream calculation
`rejected`	Candidate was declined	Preserve the reason and prevent automatic reuse
`pending`	The value may exist, but current evidence is insufficient	Obtain another drawing, table or human decision
`null`	Explicitly absent or not applicable in the current scope	Do not infer or calculate
`conflict`	Credible sources disagree	Stop and escalate

The scoring model must support the same behavior. If a correct guess earns one point, abstention earns zero and a wrong guess loses only one, guessing can still be rational. For high-risk fields, false positives should cost substantially more than abstention:

Correct with evidence: +1
Pending / cannot determine: 0
Incorrect adoption: -5
Missing or fabricated evidence: fail the run

The goal is not a timid agent. It is confidence calibrated to actual evidence. Knowing that the system does not know is often more valuable than a wrong value that nobody notices.

Candidates and final results need different storage

An agent should narrow the human decision space, not disguise a candidate as a final answer.

A field may preserve several sources at once:

{
  "field": "floorHeightMm",
  "candidates": [
    {
      "value": 3200,
      "authority": "rule",
      "evidence": "Default floor schedule rule R-12"
    },
    {
      "value": 3350,
      "authority": "agent",
      "confidence": 0.78,
      "evidence": "Section S-04, elevation annotation near Grid C"
    }
  ],
  "resolved": null,
  "status": "conflict"
}

This is more data than storing 3350, but it preserves the fact that the workflow must not calculate yet. If downstream computation requires status === "accepted", unresolved candidates cannot accidentally enter a bill of quantities.

A skill contract needs stop conditions

Most agent procedures describe only the happy path: open the file, extract the table, classify fields and emit JSON. A trustworthy skill must answer five additional questions:

Under what conditions may it start?
Which data may it read or change?
What counts as complete?
Under what conditions must it stop?
Who takes over after completion or a stop?

Treat a skill as a small contract:

name: classify-drawing-elements
inputs:
  - normalized_drawing
  - layer_manifest
allowed_actions:
  - inspect_text
  - inspect_geometry_preview
  - propose_candidates
completion:
  - every candidate has source and location
  - output passes candidate schema
stop_when:
  - drawing version is missing
  - two authoritative sources conflict
  - required scale cannot be established
  - confidence is below the field threshold
forbidden:
  - overwrite human decisions
  - emit final quantities
handoff:
  success: quantity-validator
  blocked: human-review-queue

Stopping is not agent failure. It is the workflow correctly defending an authority boundary. Without stop conditions, an agent can only keep trying forever or invent an answer to declare completion.

Evidence is part of the output

Every candidate should answer:

Which drawing and revision produced it?
Where is the title block, table, coordinate or element?
Which rule or inference was used?
How was confidence obtained?
Which model, prompt, skill and code version created it?
Was it later changed by a person, and what were the before and after values?

A run needs a manifest too:

{
  "runId": "run_2026_10_04_0031",
  "inputHash": "sha256:...",
  "drawingVersion": "REV-C",
  "model": "model-name-and-version",
  "skillVersion": "classify-elements@1.4.2",
  "ruleSet": "bim-rules@2026.10.1",
  "startedAt": "2026-10-04T09:12:03Z",
  "completedAt": "2026-10-04T09:29:41Z"
}

Human corrections should be appended as audit events rather than overwriting history:

{
  "field": "wallType",
  "before": "partition",
  "after": "structural",
  "reason": "Design change notice DCN-17",
  "actor": "reviewer-12",
  "timestamp": "2026-10-04T09:30:00Z"
}

This evidence chain makes results reproducible, exposes regressions, supports model comparisons and answers the operational question: “Why did we adopt this number at the time?”

Convert experience into rules cautiously

Another strong property of this workflow is that repeated human work can gradually become a rule. The right process is not to create a rule after one correction:

flowchart LR
  H[Human correction] --> L[Preserve before / after / reason]
  L --> P[Find a repeated pattern]
  P --> R[Propose a candidate rule]
  R --> B[Replay historical cases]
  B --> D{Better without new regressions?}
  D -->|no| K[Keep as human knowledge]
  D -->|yes| A[Human approval + version]
  A --> E[Release and monitor exceptions]

Before entering the official rule set, a rule should have:

support from several cases rather than one exception;
an explicit scope;
positive, negative and boundary examples;
replay against historical data;
human approval;
a version, rollback path and expiry condition.

Knowledge should also move into the strongest appropriate layer:

Kind of knowledge	Best destination
Fixed mathematical or geometric relationship	Code / tests
Required format and field contract	Schema
Explicit classification condition	Rule engine
Context-dependent interpretation procedure	Agent skill
Engineering convention or exceptional decision	Human decision record

Not every correction belongs in a prompt, and not every experience deserves a skill.

Rerun should recompute without forgetting

Reproducible workflows must be rerunnable, but rerun cannot mean deleting every decision and asking the agent to guess again.

A sound rerun should:

identify new input by hash and revision;
rerun deterministic extraction and calculation;
allow the agent to propose new candidates;
preserve existing human decisions by default;
create a conflict rather than overwrite when new evidence disagrees;
reopen adoption only when a person revokes the decision or a new revision invalidates it.

flowchart TD
  N[New run] --> X[Reparse and recalculate]
  X --> A[New agent candidates]
  A --> M{Existing human decision?}
  M -->|no| R[Resolve by authority]
  M -->|yes, consistent| P[Preserve human decision]
  M -->|yes, conflicting| C[Mark conflict<br/>await human review]

This is where Human > Agent > Rule becomes more than an architecture diagram. It becomes an executable merge policy.

A practical health check

Before introducing AI into a high-risk workflow, I would check:

My reading

The strength of this design is that it does not treat AI as a smarter function, nor reduce the human role to pressing Approve at the very end.

It accepts three realities:

Some questions can be calculated exactly and should not be guessed by a model.
Some questions require semantic interpretation, but interpretation should remain an evidence-backed candidate.
Some decisions carry engineering convention and responsibility. A person must adopt them, and a later rerun must not wash them away.

A good AI workflow does not try to eliminate null; it keeps unknowns visible. It does not insist that the agent always finish; it teaches the agent when to stop. It does not treat a human correction as a disposable patch; it preserves the evidence and only then considers promoting the lesson into a verifiable rule.

That is closer to engineering progress than switching to a larger model.