Operational accountability for machine-mediated judgment

Operational AI

When AI helps decide what happens next, the model is only one part of the decision. The result also depends on what information was available, where the system ran, what it was allowed to do, whether a person could intervene, and what evidence remains afterward. Those operational conditions increasingly determine whether a decision can be trusted.

This series examines that problem one bounded function at a time: one particular judgment within a larger workflow. Some functions only advise; others can act. Each has its own requirements for evidence, authority, placement, and human control, and those requirements can change as models and operating conditions change.

Together, the essays develop a practical discipline for making machine-mediated judgment accountable in operation.

How the essays relate

A spine, with one companion. Each essay is a different view of the same discipline.

  1. Decompose the system.
  2. Test the decomposition in operation.
  3. Determine what must be provable.
    • Part One: Establish valid placement.
    • Part Two: How is validity maintained over time? · In progress

Start here

The essays, in reading order

Oldest first — the order in which the argument is built.

01 June 29, 2026

Operational AI Becomes a Distributed Systems Problem

Start here. Once AI moves from a demonstration into operations, success depends less on any one model and more on how many bounded functions work together across a distributed system. This essay explains why lasting value moves from individual components to their composition.

Where it leads — If functions can run throughout the system, how do we decide where each one belongs? The placement contract takes up that question later in the series.

02 July 2, 2026

Operational AI in Search and Rescue

See the framework under pressure. A search and rescue mission puts AI into the field, where connectivity fails, resources are limited, and command must remain human. The essay shows why function, placement, and authority must be designed separately.

Where it leads — If a function must move as conditions change, what requirements and limits must move with it? The placement contract returns to that question later in the series.

03 July 12, 2026

Evidence Debt

Most systems are built to make decisions, not to prove them later. This essay names the resulting gap as evidence debt and shows why the necessary proof must be created while the work is happening.

Where it leads — A complete record can show what was captured. Is that enough to show that the decision was justified?

04 July 16, 2026 Companion to Evidence Debt

From SBOM to Decision BOM

A Decision BOM records what produced an outcome. This companion essay asks the harder question: does that record contain enough evidence to support the decision? It offers a practical vocabulary for distinguishing evidence that is sufficient, insufficient, or still unable to settle the question.

How it connects — The Decision BOM gives Evidence Debt a concrete record and a way to assess what that record can actually support.

05 July 23, 2026 Part One of The Inference Control Plane

The Placement Contract

Where can an AI function make a valid judgment? This essay pairs what the function requires with what an execution environment can actually provide and permit. That pairing is the placement contract.

Where it leads — How does the system keep that contract valid as models, policies, data, load, connectivity, and operating conditions change?

The vocabulary

Terms the series defines, in the order the argument builds them.

Operational accountability
The discipline of defining what a machine-mediated judgment is permitted and required to do, creating the conditions in which those obligations can be met, preserving sufficient evidence to assess the judgment afterward, and reassessing the arrangement as conditions change.
Machine-mediated judgment
A judgment produced or materially shaped by computational inference, whether its result acts directly or informs a human decision.
Bounded function
A discrete unit of inference within an operational workflow. Its contract defines the judgment it makes, the context and reasoning basis that judgment requires, the data and tools it may access, the effects it is authorized to cause, the evidence it must produce, and how it behaves when conditions degrade.
Meaningful human control
A human decision point at which the person has the information, time, authority, and effective means to challenge, reject, or stop an outcome. A recorded approval alone does not establish meaningful control. (One possible obligation of a bounded function — not what makes something a bounded function.)
Evidence debt
The gap between what a function must prove and what its implementation can actually produce.
Completeness vs sufficiency
Completeness asks whether the required fields or events are present. Sufficiency asks whether the record contains enough evidence for the obligation. A complete record does not establish that the decision was right.
Decision BOM (DBOM)
A per-decision record of what produced an outcome: the model and prompt versions, the data consulted, the tools invoked, the policies in force, the human actions taken.
The placement contract
Each bounded inference function declares what a valid judgment requires; each execution environment declares what it can provide and enable. The pairing is the contract.
The evidence plane
The systems that produce proof as a byproduct of doing their work: enforcement points that emit logs, policy engines that record their grants, attestation services.
Function / placement / authority
Three independent axes: what the function does, where it runs, and what it is permitted to decide or cause.

Obligations are proportional

These obligations exist on a gradient. An advisory function with limited consequences may need little beyond basic provenance and ordinary operational records. A function capable of consequential action may require strong evidence, constrained effects, explicit human authority, and a full continuity plan. The appropriate controls must be reasoned about for the particular function rather than inherited from a universal checklist.

The result is not set once. Changes in mission, policy, risk, connectivity, available evidence, model capability, or execution environment can change where a function may validly run, what authority it may exercise, and what it must prove. Material changes require the contract to be reassessed and versioned. Moving a function or changing its implementation does not silently carry its authority forward.

What this builds on

Accountability did not begin with AI. This series builds on work that long predates it:

  • · distributed systems and operational resilience
  • · safety engineering and control systems
  • · administrative accountability and reasoned decision making
  • · human factors and automation bias
  • · zero trust and policy enforcement
  • · software supply chain records such as SBOM and VEX
  • · AI traceability and record keeping

EU AI Act ↗ · NIST SP 800-207, Zero Trust Architecture ↗ · OASIS CSAF / VEX ↗

Part Two — How is validity maintained over time? · In progress