Probabilistic Boundary

COADF P-1 states the minimum: a probabilistic component returns a value together with a confidence and the method the value was obtained by, never a bare value, and it never reaches an output directly. This pattern is about the second half, which is the half implementations lose. A model's answer may enter the system. What it may not do is become, by any path, the thing the system treats as established.

Three things have to hold at once:

• The output has a type of its own. A proposal and an authoritative record are different types, different tables or different messages. Code holding one cannot pass it where the other is expected without an explicit step somebody can review.
• The boundary validates at run time. The contract is checked when the reply arrives, in the process that receives it, whatever the sender says it checked.
• Provenance travels with the value. The method, the model and its revision, the prompt revision and the location in the source stay attached through every step, serialisation included. Without them P-4 cannot reconstruct and P-5 cannot disclose.

P-1 also has the component report a confidence. How confidence is expressed, assigned and used belongs to P-2, which COADF publishes as a principle only. This Companion does not describe it, and nothing below depends on it.

A model's output comes from a process that cannot be reproduced from its inputs the way a parser's output can: sampling, model updates and prompt changes all move it. That is acceptable for a proposal and unacceptable for a fact. The risk is not that a model is sometimes wrong; everything is sometimes wrong. The risk is losing the ability to say which values came from where, because every later control depends on it. A gate stops only what it can see, a disclosure names only what is marked, and a reviewer checks only what still points at its source.

The loss is rarely a decision. It happens on an ordinary line of code: an ORM entity populated from the model's JSON because the field names happened to match, a response model that drops the provenance because nobody added it, a batch import that bypasses the form where the validation lived. The pattern exists to make that line impossible to write without noticing.

Isolation is architectural, not necessarily physical

Microservices are not required. The property holds when no code path lets the probabilistic side produce an authoritative object, and a single process can keep it as well as a network can. Choose the topology for its own reasons (scaling an inference workload separately, isolating a vendor's client library, deploying independently) and then build the boundary in whichever shape you chose. The four figures below keep the same property in four shapes.

The same four elements in every topology

• Distinct types. The probabilistic side can construct a proposal and nothing else. The authoritative record is built only by domain code, from a proposal plus something the probabilistic side cannot produce.
• Runtime validation on every receiving side. A strict schema: undeclared fields rejected, no type coercion, closed vocabularies for categorical values, bounded lengths. In a distributed topology each receiver validates, the domain side included when the sender is your own service: "we validated before sending" is a claim about another deployable, possibly an older version of it.
• Provenance in the contract. Declared, required, and preserved by every mapper and serialiser on the way out.
• An explicit promotion step. The only route from proposal to authoritative record is a function, endpoint or command that demands what the probabilistic side cannot supply. For values derived by a language model, COADF's public fence F-03 requires human verification before they reach a published output. The promotion is itself recorded in the audit trail.

Deterministic validation around stochastic output

Checks that read only the value (its form, its vocabulary, its unit, the ranges the domain itself defines) run before any person looks at it. They do not make a value true. They make an impossible value impossible, and they do it the same way every time, which a person reviewing the value can rely on.

Enforcement options, from weakest to strongest

Most systems want the first three always, and the last two when the probabilistic component is deployed on its own. The Python and FastAPI profile implements the first three; the Cloud-Native profile adds the last two.

• Suggestion-only interfaces. Model output is shown to a person as a suggestion and never stored as a value. Simple and strong; it gives up the traceability of what was suggested unless suggestions are recorded as well.
• A shared, language-neutral contract (JSON Schema, Protocol Buffers) instead of language-native models. Better across languages; it moves the strictness question into the schema, where additional properties and formats have to be decided explicitly.
• Structured-output modes of model APIs. They reduce malformed replies at the producer. They do not relieve the consumer of validating, because the consumer cannot verify how the producer was configured.
• Separate storage for proposals and records, two tables or two stores rather than one table with a status. Heavier, and it makes the separation visible to every query anybody writes.

• The boundary controls where model output can go. It does not make model output correct, and a well-formed wrong value passes every check in this pattern.
• Type separation stops accidents, not intent. A developer with write access to the domain can construct an authoritative object by hand; code review and the audit trail are what make that visible.
• This pattern does not say when a proposal needs a person, or how confidence is expressed. Those belong to P-2 and P-3, which COADF publishes as principles only.
• Validation is only as good as the contract. A permissive schema, validated strictly, is still permissive.