> ## Content Index
> Fetch the complete content index at: https://machina.mmalc.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# Probabilistic Advice, Deterministic Authority
- URL: https://machina.mmalc.com/pada/
- Published: 2026-10-13T16:38:27.000Z
- Updated: 2026-10-13T16:49:05.000Z
- Description: AI can interpret a request, suggest a plan, and help recover from a mistake. This architecture puts explicit rules in charge of what happens next — checking evidence, controlling actions, and reassessing permission when circumstances change.
- Author: mmalc Crawford

An owner’s manual for a new car is ready to publish. The words have been reviewed, the illustrations checked, and the procedures approved for the right vehicle models. Then engineering reports that one version of the car needs a different towing procedure.

> Note: Companion to [Compiling Dinner](https://machina.mmalc.com/compiling-dinner/). This article is in "early draft" stage, but I'm disinclined to pursue it further. I hope the concept/architecture may be useful to others.

Nobody has touched the manual. It is still the document everyone approved. It may also now be wrong.

An AI assistant could be useful here. It could compare specifications, find passages that might need attention, and suggest new wording. It could also miss the connection, misunderstand the change, or explain very convincingly why no revision is needed.

The publishing system needs a dependable answer to a practical question: may this version still go out?

That fictional example captures the problem this article explores. We want the flexibility of AI without making its judgment the final authority over consequential actions. A former colleague, an AI specialist, put the underlying concern broadly: programming with AI can sometimes produce surprising failure conditions. His observation helped focus the question developed here: which failures can the surrounding software prevent, even when the AI gets something wrong?

The guiding principle is **Probabilistic Advice, Deterministic Authority.** AI may interpret, explain, plan, and propose. Explicit rules and accepted evidence determine what the system is allowed to do.

The distinction has to survive beyond the moment someone approves a suggestion. Evidence changes. Other work happens. Commands fail. Permission needs a continuing relationship with the reasons it was granted, and the system needs an honest account of what happened afterward.

## Giving advice without holding the keys

In the manual example, the AI can propose a correction and explain its reasoning. It cannot give that correction engineering approval, change the publication rules, or publish through a separate route. The surrounding software controls those powers.

This is an architectural boundary enforced through permissions and interfaces. An instruction in a prompt asking the AI to be careful does not establish it. If the model can directly replace an approved file or use publication credentials, it already holds authority that the supposed checker cannot reliably contain.

The useful role on the AI side can remain substantial. It can interpret an awkward request, suggest how to divide the work, assemble a candidate plan, and investigate why a check failed. It can return with a better proposal. A new problem during execution can send it back to work.

Each consequential proposal must still pass through the same boundary. Repeated interpretation is compatible with dependable execution when interpretation never acquires permission merely by being persuasive.

“Compile with AI; execute deterministically” describes one useful arrangement: turn a messy request into a checked plan, then run it without further model calls. The broader principle also accommodates repeated advice. What matters is that every protected action remains under explicit control.

The same treatment can apply to an ordinary scheduling program. If it proposes two jobs that need the same machine at the same time, the checker should reject the conflict. The boundary follows responsibility for enforcing the rules, whoever produced the proposal.

## Boring software has an important job

Here, *deterministic* means that the same proposal, relevant state, rules, and recorded inputs produce the same decision. We should be able to inspect why a request was allowed and reproduce that decision from its recorded basis.

The inputs can include a clock reading, an engineering review, or a report from another system. Determinism does not require the outside world to stand still. It requires the software to be clear about which version of that world informed its decision.

For the fictional manual, the checks might include whether the required reviews cover this exact revision, whether the evidence applies to the intended vehicle configuration, and whether the publication destination is permitted. A confident explanation from the AI cannot substitute for a missing review or make evidence about one configuration apply to another.

Below that boundary, I would want as much as possible to be boring software: defined operations, explicit conditions, recorded decisions, and controlled changes of state. Its dependability would come from making particular mistakes difficult or impossible to carry through.

There is a limit worth establishing early. Deterministic software can enforce a bad rule perfectly. It cannot discover every fact that the people designing its checks left out. Its strength is the ability to enforce known conditions consistently, independently of whether the adviser understands them.

That is a useful gain. A system can prevent publication with obsolete approval even if it cannot judge every sentence in the manual. It needs to say clearly which assurance it provides.

## The pieces the architecture needs

Following a proposal through the system reveals six responsibilities. They do not require six separate services or a particular programming language.

| Responsibility           | What it does                                                                                                        |
| ------------------------ | ------------------------------------------------------------------------------------------------------------------- |
| **Advisers**             | Interpret information and suggest assertions, plans, or repairs.                                                    |
| **Candidate workspace**  | Holds suggestions, supporting material, alternatives, and unanswered questions without treating them as accepted.   |
| **Governed model**       | Defines the available operations, their meaning, and the rules and evidence required to use them.                   |
| **Admission authority**  | Checks a proposal against those definitions and the relevant current state.                                         |
| **Authoritative record** | Preserves accepted decisions, their supporting basis, and reports of what happened.                                 |
| **Effect gateway**       | Controls protected actions, checking permission for the actual action and destination when that permission is used. |

An admission check can accept a proposal, reject it with reasons, or leave it pending because something material is missing. Pending is a useful result. It gives the system a specific question to resolve while other permitted work continues. Neither silence nor a more confident answer automatically supplies the missing evidence.

Each accepted decision needs two things: a **subject** and a **basis**. The subject is exactly what has been authorized, including its scope and destination where those matter. The basis is the evidence, rules, judgments, and state conditions that justified it. “Publish the manual” is too vague if the approval covers only one revision for one vehicle configuration.

Underneath, the information can be fairly compact: facts or assertions, operations, constraints, and events. An assertion might record that a particular reviewer approved a particular revision. An operation defines what publishing does. Constraints say when it is permitted. Events record approval, a source change, dispatch, or a reported outcome. Assertions retain their source and status; a confidence score does not turn a suggestion into an accepted fact.

This leaves room for different views of the same work. An editor may see chapters and reviews; an engineer may see specifications and affected procedures. Both must derive publication status from the same authoritative record. The presentation should not quietly create a second source of permission.

## What has actually been checked?

“Validated” can sound more reassuring than the checks deserve.

A system might establish that a warning is present, yet overlook a nearby sentence that contradicts it. It might establish that every required field has a value, while accepting the wrong value. A plan can be neatly structured and still accomplish the wrong task.

Useful checks therefore need to reach the meaning of the action wherever a guarantee depends on that meaning. For some material, a value can come directly from an accepted engineering specification. Some transformations can use established operations with fixed behavior. Other claims may require an authorized expert’s judgment.

In that last case, the software checks that the required judgment covers the right subject and remains applicable. It does not become an expert itself. A reviewer can still approve misleading prose; recording the approval faithfully will not correct the prose.

Operations also need carefully bounded parameters. A tool called “format report” may look harmless, but if one of its arguments accepts an arbitrary program, the model has regained a much broader ability to act. Checking that the argument contains text tells us little about what that text can make the system do.

The governing rules need similar care. Moving an AI-generated claim into a configuration file does not establish its correctness. Someone must establish and maintain what the operations mean, which evidence is acceptable, and which changes require review. AI can help with that work, but an ordinary task proposal cannot rewrite the rules used to judge itself.

This is where much of the engineering effort belongs. Once a useful set of operations and conditions has been established, the system can enforce them across many fallible proposals. If every new request requires inventing new rules, far less has been made dependable.

## Approval has a shelf life

Return to the manual. Its approval was real. The engineering change does not erase the review meeting or make the historical record false. It changes whether that review still justifies publication.

An “approved” checkbox collapses those two questions. The architecture needs to preserve the earlier decision while reassessing current permission against its basis.

That reassessment should be selective when the evidence supports selectivity. A change to a towing procedure need not stop unrelated work on the audio-system chapter. But the system needs an accepted account of the dependencies before it can make that distinction. An AI-generated list of affected passages cannot establish its own completeness. Otherwise, anything the AI forgets becomes permission to proceed.

Where the impact is uncertain, the affected action remains pending. If the uncertainty cannot be narrowed reliably, the pause must cover the broader potentially affected work. The system may continue work whose independence has an accepted basis.

There is another trap: checking only the sources already cited. A newly issued restriction may affect a release even though none of its old references changed. The rules need an account of what new information becomes relevant, as well as how existing evidence becomes obsolete. An incomplete dependency model can still miss an affected procedure; maintaining that model is part of the job.

Finally, permission needs checking when it is used. A publication request may sit in a queue while engineering issues another change. Approval at the start of the queue cannot guarantee permission at the end.

The implementation must define when authorization takes effect and ensure that the check and the authorization agree on the relevant state. Interacting decisions need a clear order. Independent work can still proceed in parallel.

## Sending a command does not make it happen

Suppose the system has authorized publication and sent the manual to a distribution service. The service stops responding. Has the manual been published?

The honest answer may be that the system does not yet know.

The record needs to distinguish permission, dispatch, a reported result, and an accepted conclusion about that result. An instruction to publish establishes none of the later stages by itself. A receipt might establish that a service accepted the file without establishing that readers can access it.

The gateway must also preserve the connection between the checked proposal and the actual effect. Approving one file and sending another defeats the entire arrangement. If the approved material is rendered into a PDF, the rendering must preserve the checked properties or the resulting artifact needs the appropriate checks.

Timing becomes awkward when another engineering change arrives after dispatch but before confirmation. The software cannot retroactively prevent an action that has passed the point of cancellation. It can preserve the earlier authorization, record the new information, and determine what reassessment or recovery is now required.

A late report of an unwanted publication must remain recordable. Refusing to acknowledge it because the system would no longer authorize it would leave the official account less accurate than reality. Recording a report need not endorse every claim it makes: the record can preserve who reported what, when, and with what uncertainty.

AI can help interpret confusing reports and propose recovery. Its suggestions cross the same boundary as the original plan. Recovery starts from the best accepted account of current conditions, including uncertainty and actions already in progress. A replacement plan does not undo an earlier publication. Withdrawal or correction is another action with its own conditions and possible failures.

For ongoing physical processes, the rules may need to hold throughout execution. That requires observations and an available response. Writing down a temperature limit cannot protect equipment the system can neither monitor nor control. Refusing a new command is also not a universal fallback: sometimes the system must act promptly to preserve safety.

## Automation without a person at every step

Because a manual involves reviews, it is easy to mistake this architecture for a series of human approval gates. The same separation can operate automatically.

Consider a fictional service that produces a daily report of maximum temperatures. The report definition already specifies the sensors, time period, units, day boundaries, and permitted destination. A maintained catalogue identifies the measurement fields and their units.

An AI adviser can interpret a request and suggest a plan: select the measurements, convert units if necessary, group by day, calculate maxima, and produce the report. The available operations have defined behavior. The checker compares their selection and parameters with the accepted report definition.

It can reject a plan that substitutes averages for maxima, uses the wrong date range, or relabels Fahrenheit measurements as Celsius without conversion. If the measurement units are unknown, the work stays pending until an accepted source supplies them. The model’s best guess is insufficient.

Once accepted, the plan can run without another AI call or routine human confirmation. The assurance is specific: this is the required calculation on these accepted inputs under these rules. It does not establish that the sensors were calibrated or that the report definition captured the requester’s intention. Missing and invalid measurements also need explicit treatment; quietly dropping them can change the question being answered.

The example works because the task and the operations are bounded. Checking their composition is a manageable engineering problem. Asking a checker to determine whether arbitrary generated software does whatever its author intended is a much larger one.

Across both examples, the architecture stays the same. The application supplies the operations, evidence, and constraints that give its checks substance.

## Familiar ideas, brought together

This separation has recognizable antecedents. The sources below do not establish that the proposed architecture is novel. They help explain both why it is plausible and where its responsibilities come from.

The **reference monitor** tradition describes an enforcement mechanism that mediates protected access, resists tampering, and is constrained enough to examine thoroughly. Those requirements are directly relevant to a boundary the adviser must be unable to bypass. They establish control over access, without by themselves proving that an authorized action accomplishes the intended task. [NIST](https://csrc.nist.gov/glossary/term/reference%5Fmonitor?ref=machina.mmalc.com)

The **Clark–Wilson integrity model**, published in 1987, is particularly close. It distinguishes establishing that transformations preserve the required integrity from enforcing their use. It also addresses how unconstrained input may enter controlled data. Much of the work described here follows that established separation between defining acceptable changes and controlling how they happen. [Clark and Wilson](https://groups.csail.mit.edu/ana/Publications/PubPDFs/A%20Comparison%20of%20Commercial%20and%20Military%20Computer%20Security%20Policies.pdf?ref=machina.mmalc.com)

**Simplex**, from process control, combines less trusted controllers with a trusted decision mechanism and a reliable safety controller. Its assumptions include detecting problems in time and having a feasible fallback. It is a useful reminder that dependable execution can require a continuing response to the world, beyond checking a plan before it starts. [Software Engineering Institute](https://www.sei.cmu.edu/library/an-architectural-description-of-the-simplex-architecture/?ref=machina.mmalc.com)

More recent work makes the AI connection explicit. **LLM-Modulo** combines model-generated proposals with external model-based verifiers in an iterative process. **PlanCompiler** provides a close compilation example: in its evaluated configuration, a language model selects and supplies parameters for predefined operations; structural checks precede compilation, and execution requires no further model calls. Its paper also identifies meaningful limits: some incorrect plans pass structural validation. [LLM-Modulo](https://proceedings.mlr.press/v235/kambhampati24a.html?ref=machina.mmalc.com), [PlanCompiler](https://arxiv.org/html/2604.13092v1?ref=machina.mmalc.com)

The emphasis here is the continuing relationship between advice, evidence, permission, and outcomes. Bringing those responsibilities together provides a way to reason about a whole application. It does not require claiming that its constituent mechanisms have just been invented.

## When the separation earns its keep

This architecture is most useful where a worthwhile range of actions can be given stable meanings and important conditions can be checked more reliably than proposals can be generated. AI then has room to interpret messy inputs and explore options while the execution system has definite conditions to enforce.

The cost is maintaining that foundation. Operations need owners. Dependencies need updating. Decisions need records. Connections to other services must preserve what was authorized. The infrastructure that protects identities, rules, and records belongs within the system’s trust assumptions, too. Even resource limits matter if a malfunctioning adviser could prevent the checker from running.

Conservative checks can also leave work waiting. Applications need explicit rules for fallback and escalation, including what can proceed independently. Availability and timely intervention deserve as much attention as refusal.

The benefits are narrower where success is mostly subjective or every new task requires another unconstrained interpretation. Even there, the system may usefully restrict destinations, spending, or available operations. Those controls should be described for what they establish; they do not verify the substance of every answer.

A small executable exploration of the manual scenario helped test selected contracts, including the possibility that approved prose could still be wrong. It was a bounded design exercise, not a production demonstration. The technical note below records its scope.

“No hallucinations on the critical path” remains a useful engineering intention, provided it is understood precisely. A mistaken interpretation may still pass inadequate checks. The enforceable requirement is that the interpretation has no direct authority to bypass those checks, expand its permissions, or alter the rules that govern it.

For any consequential action, an engineer should be able to identify exactly what is permitted, why it is permitted, what would invalidate that permission, and what evidence would establish the outcome. The answers should remain meaningful even when the adviser is entirely mistaken.

That is the practical ambition of Probabilistic Advice, Deterministic Authority: AI can become more capable while the system retains explicit control over what its advice is allowed to cause.

---

## Technical notes and sources

**Scope of the design exercise.** The existing executable model exercised 33 focused cases and all 720 permutations of six actions, each occurring once, in a review-and-release scenario. It also included a deliberate case in which misleading prose remained admissible after the required reviewers approved it. These checks support selected contracts within that model. They do not establish production reliability, general correctness, or performance across domains. The temperature-report example is a conceptual walkthrough.

**Concurrency and external effects.** Reproducing an admission decision requires the relevant state and the ordering of conflicting changes to be identifiable. Repeated requests need an identity that distinguishes recovering an earlier outcome from authorizing a new action. Preventing duplicate remote effects depends on the receiving service’s protocol; a local record alone cannot guarantee that an external action happens exactly once. Conditions may apply at initiation, throughout operation, or at completion, with different observation and recovery requirements.

**Reference monitor.** National Institute of Standards and Technology, [CSRC Glossary](https://csrc.nist.gov/glossary/term/reference%5Fmonitor?ref=machina.mmalc.com), citing NIST SP 800-53 Revision 5.

**Clark–Wilson.** David D. Clark and David R. Wilson, [*A Comparison of Commercial and Military Computer Security Policies*](https://groups.csail.mit.edu/ana/Publications/PubPDFs/A%20Comparison%20of%20Commercial%20and%20Military%20Computer%20Security%20Policies.pdf?ref=machina.mmalc.com), IEEE Symposium on Security and Privacy, 1987\. See certification and enforcement rules on printed pages 189–191.

**Simplex.** Jose German Rivera, Alejandro Andres Danylyszyn, Charles Weinstock, Lui R. Sha, and Michael J. Gagliardi, [*An Architectural Description of the Simplex Architecture*](https://www.sei.cmu.edu/library/an-architectural-description-of-the-simplex-architecture/?ref=machina.mmalc.com), CMU/SEI-96-TR-006, 1996\. See sections 2.2.1 and 4.2.5 for containment assumptions and the decision component.

**LLM-Modulo.** Subbarao Kambhampati and colleagues, [*Position: LLMs Can’t Plan, But Can Help Planning in LLM-Modulo Frameworks*](https://proceedings.mlr.press/v235/kambhampati24a.html?ref=machina.mmalc.com), Proceedings of the 41st International Conference on Machine Learning, PMLR 235, 2024, pp. 22895–22907.

**PlanCompiler.** Pranav Harikumar, [*PlanCompiler: A Deterministic Compilation Architecture for Structured Multi-Step LLM Pipelines*](https://arxiv.org/html/2604.13092v1?ref=machina.mmalc.com), arXiv:2604.13092v1, 8 April 2026\. Preprint. Sections 3, 6.5, and 7.5 describe the evaluated architecture, validation limits, and scope. The evaluation covers ordered single-stream workflows; broader control-flow and application claims require further evidence.

*Related:* [*Compiling Dinner*](https://machina.mmalc.com/compiling-dinner/) *tells the story of the conversation that led to this architectural exploration.*