Text Is Not a Decision: The Typed Decision and the Controlled Workflow

A prompt library records an instruction. It does not record which source was approved, what the output must contain, how failure is detected, or who may change the method. That is the difference between standardising an instruction and standardising responsibility, and it is why a controlled workflow is a different object from a well-written prompt.

This is the mechanism strand of configured is not controlled. The regulatory case for a record sits in what GDPR, NIS2, DORA and the EU AI Act ask of a system that acts; this post is about the component that produces one.

Eight stages that make a method repeatable

A controlled workflow has the same shape whether the work is reconciling positions, drafting client letters, triaging onboarding files or classifying matters. Eight stages fix the things a prompt leaves floating:

1. Trigger. When the process starts, so informal use is not the default route in.
2. Approved inputs. Which documents, data classes and versions may be used, refused rather than discouraged when breached.
3. Model task. A step narrow enough to test: extract, draft, summarise, or decide.
4. Deterministic checks. Requirements that must never vary, mandatory wording, thresholds, eligibility, arithmetic, as encoded rules, not model judgement.
5. Human review. A reviewer with knowledge, time and authority, who owns the consequential decision, evidenced in the record.
6. Final output. Released through the normal channel, never straight from the model.
7. Measurement. The full effect, including correction, review and operating cost, because time saved is a hypothesis and the net effect is the value.
8. Review cycle. A finding is fixed by a versioned release, so the fix is in the record.

Risk does not enter when someone opens a tool. It enters when an output moves to the next stage: a summary becomes a recommendation, a draft becomes a client communication, a classification changes how someone is treated. Governance has to alter the sequence before that happens, which is why in our harness, Fulcrum, the eight stages are a controller's dispatch table: which step runs next is decided deterministically, and the reasoning inside a step is the only probabilistic part.

Text is not a decision

Step three is where most designs go wrong, because they ask one model to both write and decide. Those are not the same operation.

A model that writes produces open-ended prose someone has to parse, can invent an option nobody offered, can give two different answers to the same input, and says nothing about how sure it was. A typed decision produces a choice from options the caller supplied, structured so the application acts on it directly. The model cannot answer outside the set. Every option carries a probability, and the answer carries a confidence. What it leaves behind is a record, not a paragraph in a log:

request
  state:      "My card was charged twice. Please refund it."
  question:   choice  "Which team should handle this?"
  options:    billing · technical · sales · abstain
response
  answer:     billing
  p:          billing 0.67 · technical 0.24 · sales 0.06 · abstain 0.03
  confidence: 0.58
  versions:   decision-head v3.2 · options v7

The shape matters more than the model behind it. A small local encoder with a scoring head can do this, and a frontier model can be made to with constrained decoding. What both share is the contract: the answer space is fixed before inference, and the output is a number per option, not a sentence.

The caller owns the option space

The most important line in the contract is the one the model never sees: the application decides what the allowed answers are. That single property removes a class of failure that free-text integration cannot remove by any amount of prompting. The set of actions the system can take is enumerated in code, reviewed like code and versioned like code, so a model update cannot add a fifth option to a four-option decision. It also removes the parsing layer: there is no free-text output to validate, no regular expression over a sentence, no "the model said something unexpected" path in the incident log.

It clarifies where everything else lives, too. Hard constraints, thresholds, arithmetic and eligibility stay in application code before and after the decision call. The model ranks; it does not compute a fee or apply a lock-up. The model earns its place only where inputs are unstructured and mapping them to a known category needs judgement: which queue, which risk tier, which clause, whether a human is needed at all.

A useful test: if you cannot list the acceptable answers before you call the model, you are not ready to automate the decision. You may be ready to draft with it, which is a different workflow with different controls.

Confidence is concentration, not correctness

The confidence figure measures how concentrated the distribution is, zero when every option is equally likely, one when a single option takes everything. It says nothing about whether the top option is right. A confident wrong answer is possible, and calibration done on one population does not carry to another. A threshold is therefore a routing rule, not a truth test: below it the case goes to a person, above it it proceeds, and where the line sits is a business decision set against a baseline and revisited when the case mix changes.

Abstain and escalate are answers

All of the probability goes to the options you supplied, even when none of them fits. If you do not give the model a way out, it will pick the least wrong door. The fix is not a better prompt; it is a bigger option set.

options:  approve · decline · request more information · escalate to reviewer

Abstain is an option, not an error: the model can say "none of these" with a probability, and the application routes on it like any other answer, instead of discovering the gap in a complaint. Escalation is a first-class answer, a defined entry point for the human checkpoint rather than a vague catch-all. And because options are scored on their descriptions, "Billing: payments and refunds" and "Billing" are different inputs, so option text is configuration under change control, with a version in every record.

That leaves four components with four jobs: a language model that drafts, a typed decision endpoint that decides, deterministic rules that enforce, and a named person who owns the approval. The model that drafts is not the model that decides, and each component is replaceable without touching the others. What the deciding step leaves behind, and how it becomes evidence an auditor can verify, is in the decision record.

The framing and the decision contract are drawn from the Rob-otix Ai field note "Configured is not controlled" (2026).