15 Separate probabilistic judgment from deterministic control

A model can propose a design, interpret an error, or suggest a patch. A system can deterministically enforce a revision precondition, check a permission, or reject an invalid state transition. Combining these capabilities is useful, but their responsibilities should remain clear.

A deterministic check is reliable only about the predicate it actually evaluates. It does not make an unchecked proposition true.

Separate four questions

When an agent proposes a change, ask four different questions:

1. Is the proposal structurally valid?
2. Is this actor authorized to perform it?
3. Are the relevant state and revision preconditions still true?
4. Does the result serve the intended outcome?

A schema can help answer the first. An authority mechanism can answer the second within its policy. A revision guard can answer the third. The fourth usually requires a combination of domain checks, tests, observation, and judgment.

Confusing these questions creates false confidence. A valid JSON object can request the wrong action. An authorized operation can use a stale assumption. A revision-correct patch can violate an invariant the controller does not know about.

Construct a two-stage failure

In the illustrative resource system, an agent proposes changing publication behavior against revision A. Another change creates revision B before application. The controller rejects the stale proposal. That is useful: the proposal was prepared against assumptions that may no longer hold.

Now prepare a proposal against B that passes the revision check but announces ready before verification finishes. The controller accepts it if readiness semantics are not among its predicates. The first guard worked correctly; the system still needs another way to detect the second defect.

This exercise prevents a common overstatement. “Guarded application” describes a boundary. It is not synonymous with correct implementation.

CaMeL provides a related architectural comparison by separating model processing from policy-enforcing interpretation and tracking data provenance. Its guarantees depend on a defined threat model and correctly specified policies. It does not solve every misleading-text problem or remove the need to establish what the policy should be. CaMeL.

Put the rule with its owner

A resource owner should enforce the lifecycle conditions that make its resource safe to use. A caller can validate its own inputs, but duplicating the authoritative rule across callers invites disagreement.

For publication, the component that makes a candidate visible should check the relevant readiness state at that boundary. A user interface disabling a button may help ordinary interaction, but it is not sufficient if other callers can invoke the operation.

The same principle applies to agent coordination. A proposal may describe an allowed write set, but the applying mechanism must enforce the relevant scope if correctness depends on it. A prompt instruction and an execution boundary provide different kinds of assurance.

Do not centralize every rule in one universal controller. Different owners may have distinct authority and consistency responsibilities. The design should make the handoff explicit rather than pretend a global validator can infer every domain condition.

Keep probabilistic information attributable

A model's estimate that a task is low risk may be useful input. It should remain an estimate, not silently become a verified fact. A generated explanation can help a reviewer understand a proposal, but it should not replace the actual diff or observed test result.

When uncertain judgment influences an action, record which claim was made, by whom or by which system, and which checks followed. This makes later disagreement tractable. It also prevents an interface from laundering a model's confidence into an authoritative status.

Decide what happens when evidence is missing

Some operations can proceed reversibly while uncertainty is investigated. Others require a pause because the unresolved condition affects a consequential action. That choice is part of the product's policy and risk model.

A controller that rejects every incomplete description may make ordinary work impossible. A controller that accepts every plausible proposal may leave critical authority to generation. The useful middle is explicit: which conditions are mandatory at this boundary, which are advisory, and how does a rejected operation become actionable?

For your system, list one check in each of the four categories. Then create a proposal that passes three while failing the fourth. If the team cannot explain the outcome, the boundary is probably relying on a vague idea of validation rather than a precise set of promises.