June 15, 2026

The Semantic Contract Is a Governance Object

Holly Prole

The strongest critique of runtime control is not that drift is imaginary. It is not that long outputs and agentic workflows never lose the thread. It is not that prompts, retrieval, fine-tuning, guardrails, and review already solve the problem.

The strongest critique is that runtime control depends on a contract.

If an AI system is supposed to remain attached to a governing objective, then that objective has to be represented somehow. It has to be translated into requirements, constraints, evidence obligations, exclusions, escalation triggers, and acceptance criteria. In Assiduity’s language, that representation is a semantic contract.

The critique is straightforward: what if the contract is wrong?

A semantic contract can be incomplete. It can be ambiguous. It can be stale. It can encode the letter of a policy while missing its purpose. It can omit an edge case that later turns out to matter. It can capture what one department thought the objective meant while another department would have defined it differently.

If runtime control faithfully holds the system to a flawed contract, the system may still be wrong. It may hold the wrong thread.

That objection is real. The answer is not to pretend otherwise.

Yes, runtime control moves part of the alignment problem up a level.

That is the point.

From runtime drift to governable specification

The question is not whether semantic contracts eliminate human judgment. They do not.

The question is whether moving part of the problem into a contract changes the problem’s governance properties. It does.

A drifted generation and a semantic contract are different kinds of objects.

That distinction matters.

A drifted AI workflow is an execution path. It unfolds through intermediate states, local continuations, tool calls, summaries, and decisions that may never repeat in exactly the same way. By the time a reviewer sees the final output, the drift has already happened. The reviewer is left reconstructing the path after the fact.

A semantic contract is different. It is a governance artifact. It can be reviewed before deployment. It can be versioned. It can be redlined. It can be approved by legal, compliance, risk, product, or the business owner. When it is wrong, the correction can be logged. When it changes, the change can be attributed. When people disagree, the disagreement has an object.

Runtime control does not remove human accountability. It makes the object of accountability clearer.

That is the operational shift.

Institutions already know this work

No serious enterprise assumes that a project charter is perfect because someone wrote it. Charters are reviewed. Scope is negotiated. Deliverables are clarified. Acceptance criteria are refined. Risks are logged. Change requests are approved or rejected. The charter can be wrong, but it is the kind of wrong organizations know how to handle.

The same pattern appears across institutional life.

An investment manager does not treat an investment guideline as self-interpreting. Guidelines are drafted, reviewed, updated, and applied through governance processes.

A compliance team does not assume a checklist captures every future fact pattern. Checklists evolve through policy review, incident review, and regulatory interpretation.

A model-risk team does not assume documentation eliminates model risk. Documentation gives reviewers something to inspect, challenge, approve, and revise.

A procurement team does not assume requirements are self-executing. Requirements are clarified, exceptions are documented, and approvals are assigned.

These are not perfect disciplines. But they are disciplines.

They turn implicit judgment into explicit governance objects.

That is what a semantic contract does for AI execution. It does not guarantee that the objective was perfectly defined. It gives the institution a defined artifact against which execution can be governed.

The alternative is worse. A prompt, a policy document, or a retrieved file sits in context, and the system is left to preserve its governing force across a long sequence of generation or action. If the system drifts, the organization may not know where it drifted, why it drifted, or whether the same drift would recur.

A flawed contract can be fixed. An unobserved execution path can only be investigated after the fact.

Implicit governance is not safer governance.

Displacement can be progress when it moves a problem to a layer where better controls exist. Enterprises already know how to review requirements, approve policies, version documents, assign accountability, log changes, and run post-incident reviews when a specification failed. They do not yet have native mechanisms for governing a probabilistic execution path that changes every time an agent acts.

That is the value of moving part of the problem up a level. It converts a hidden runtime failure into an explicit specification question. It gives the organization something to inspect before execution and something to improve after execution.

Return to the vendor-selection agent

Consider again the vendor-selection agent.

The enterprise has asked the system to identify three compliant vendors for a specific internal workflow. The agent must use approved sources, exclude vendors without required certifications, flag unresolved data-handling risks, and escalate any vendor that fails a required control.

A semantic contract for that workflow would not merely say: “Find good vendors.”

It would define the mandate more operationally. It would specify the approved source universe. It would identify required certifications. It would state exclusion criteria. It would define what counts as unresolved data-handling risk. It would require evidence for each recommendation. It would prohibit substituting popularity, funding status, or brand reputation for compliance evidence. It would define escalation triggers and acceptance criteria for the final recommendation.

That contract can still be wrong.

It may define certification too narrowly. It may fail to account for a vendor with equivalent foreign certification. It may omit a new data-handling standard. It may treat one control as mandatory when the business process only requires it for certain use cases. It may reflect legal’s view but not procurement’s operational need.

Those are real problems.

But they are governable problems.

The contract can be reviewed by procurement, legal, security, compliance, and the business owner before the agent runs. It can be versioned when the certification rule changes. It can be redlined when the escalation trigger is too broad. It can be audited after a failure. It can be improved when an edge case appears.

Without a contract, the same ambiguity still exists. It is just hidden inside the prompt, the retrieved policy, the model’s interpretation, and the final output. The institution has not avoided the specification problem. It has made the specification problem implicit.

The contract is not the objective

This distinction is important.

The contract is not the objective itself. It is an institutional representation of the objective. It is a way of making the objective operational enough to govern execution.

That means the contract is always subordinate to human purpose, policy, law, and judgment. A contract that faithfully encodes the wrong mandate is still wrong. A contract that preserves the letter of a rule while defeating its purpose is still defective. Runtime control does not absolve the institution of responsibility for what it asks the system to do.

But that is not an argument against semantic contracts. It is an argument for treating them as governance objects.

The same point applies to project charters, investment policies, clinical protocols, procurement rules, underwriting guidelines, and compliance checklists. None of them is perfect. None of them eliminates judgment. None of them captures every future contingency. But organizations still use them because governed execution requires explicit reference points.

A project without a charter does not become more flexible in a useful way. It becomes harder to govern.

An AI workflow without a contract does not escape the alignment problem. It makes the alignment problem harder to see.

The contract has to stay active

There is one more step.

A semantic contract is not useful if it remains passive. If the contract is only text in a prompt, it may help the system start correctly. But it does not by itself govern the execution path. The contract has to remain active while the system works.

That is where runtime control enters the argument.

Assiduity’s premise is not that semantic contracts eliminate judgment. It is that once an institution has defined the mandate, the mandate should not sit passively in a prompt. It should remain active during execution.

This claim should be kept modest. A semantic contract does not guarantee truth. It does not validate every source. It does not decide the moral purpose of the workflow. It does not eliminate legal review, domain expertise, compliance oversight, or human accountability.

Runtime control is not a certificate that the AI system was right. It is a way to govern whether execution remained attached to the mandate the institution defined.

In high-consequence work, the enterprise needs more than a polished answer. It needs evidence of how the answer came to be, which constraints remained active, where the system approached the edge of the mandate, and whether review should focus on particular parts of the workflow.

The contract gives that process a reference point.

The critique is therefore half right. Semantic contracts do move part of the alignment problem up a level. But that is not a fatal weakness. It is the governance move.

A drifted generation is difficult to govern because it is continuous, path-dependent, and only visible after execution. A semantic contract is easier to govern because it is discrete, reviewable, versionable, and auditable.

The question is not whether the alignment problem moves.

It does.

The question is whether it moves to a level institutions can govern.

Series note: This article is part of AI Drift Is Scope Creep, a three-part follow-on to Losing the Thread. The series argues that agentic AI turns prompt engineering into a project-governance problem: once AI systems begin executing multi-step work, organizations need mandates, contracts, runtime controls, and process evidence showing whether execution stayed attached to purpose. Assiduity is building the runtime control layer for that execution-to-mandate gap.