The Work-Order Governance Unit — Constrain an Agent by an Externally-Owned Contract and a Witnessed Deliverable, Not by Trust

Accepted

ontoref
A project was stopped because an agent, session after session, skipped the

Context

A project was stopped because an agent, session after session, skipped the project's own guardrails — constraints, tiers, validators — and built runtime configuration as CLI flags in direct violation of a hard invariant ("NCL config as source of truth") that was queryable in `describe constraints` the whole time. The honest diagnosis, reached in the 2026-06-23 role-swap interview, was not "the agent forgot": it was that a rule written as prose, with no gate that checks it, is — to a probabilistic agent biased toward visible progress — a suggestion its sampling is free to skip.

The failure is structural. Ontoref's knowledge surface is overwhelmingly read-side (`describe`, `qa show`); information only changes behavior if something consumes it and blocks. The validators exist as modes the agent may choose to run, not as gates. The layers with real teeth (compiler, tests, pre-commit, CI, harness permissions) were never wired to the ontology. And because the agent writes the NCL, the validators and the hooks, almost every guardrail lives inside its own editable surface — a lock it can edit in the same gesture it breaks it (the fox builds the henhouse). A guardrail that does not block is, for an agent like this, decoration.

A minimum mechanism is a trap: a minimal gate still depends on the agent respecting it. The interview converged on a different category of fix — not a better guardrail but a reusable governance unit whose terms are owned outside the worker and whose "done" carries a validator's witnessed output instead of the agent's word. It was demonstrated once (Work Order #0, config-NCL check, three red-team runs) before being recorded here.

Decision

Adopt the Work-Order Governance Unit (Spanish: Encargo) as the protocol's pattern for constraining agent work, recorded as typed glossary terms (`encargo`, `pliego`, `orden-de-trabajo`, `testigo-verificado` in `.ontoref/ontology/glossary.ncl`). It separates terms from execution along the one boundary the worker must not cross:

- A Statement of Work (SOW · Pliego), the terms — scope (minimal context + one-sentence objective), a FALSIFIABLE contract (a machine check, schema or constraint), and the validation mode ('Machine | 'Adversarial, signed or not). The SOW is authored and owned by a human, OUTSIDE the agent's editable surface. One SOW authorizes many Work Orders.

- A Work Order (WO · Orden de Trabajo), the execution — disposable, contained, owned by the agent: deliverable, an observability envelope, the verified witness, and a contained verdict ('Accepted | 'Rejected | 'Escalated).

Two atomic behavioral rules, short and at the point of use, are the whole gate: (1) no scope + contract, no start; (2) no witness, no done. Where the deliverable is not machine-checkable (open design), the contract falls back to 'Adversarial — a second unit whose contract is to refute the first — never to prose.

This ADR accepts the pattern as the governance APPROACH; the SUBSTRATE stays unbuilt. Promotion to a typed `Sow`/`WorkOrder` schema and an orchestrator wired into the daemon/CLI is GATED on a second realized instance beyond Work Order #0 — specifically a domain Work Order exercising `signed = true` end-to-end — mirroring the project's standing rule for nascent primitives (bl-036 phase-transition-witness, gated on a second instance). Accepting the decision activates the constraints below; it does not declare the substrate built.

Constraints

  • Hard The SOW (scope + contract + validation mode) MUST be authored and owned outside the executing agent's editable surface. A Work Order MUST NOT modify the SOW that invoked it.
  • Hard A Work Order MUST NOT reach 'Accepted without a verified witness carrying the contract's real output (exit code / validator result). A prose claim of completion is inadmissible by itself.
  • Soft A SOW contract MUST be machine-checkable (cmd | schema | constraint). Where the deliverable is open-ended, the validation mode MUST be 'Adversarial (a refuting second unit) — never unverified prose passing as a contract.
  • Soft Promotion of this pattern to a typed Sow/WorkOrder schema or a built orchestrator MUST be gated on a second realized instance beyond Work Order #0 (a domain WO exercising signed witness end-to-end). DISCHARGED 2026-07-04: the second instance is realized — wo-adr001-zero-deps-v2 ran end-to-end through the enforcing run-lifecycle executor (guards block at run start, `verify` derives step status, mode complete verifies the receipt's detached signature), corroborated by an eight-attempt falsification closed only by two out-of-band human signatures. Both promotion targets now exist: the typed schema (code/ontology/schemas/sow.ncl) and the built orchestrator (reflection/modules/run.nu), distributed via migration 0041. The promotion this gate authorized is recorded as ADR-066 (Governed Delivery — the Work-Order Unit Promoted to an Enforcing Executor), Accepted 2026-07-04; the gate no longer holds the pattern Proposed.

Alternatives considered

  • Hooks (PreToolUse) as the core that constrains the agentrejected: A hook needs a guarantor that it is invoked, is provider/version/context dependent, and chains awkwardly with git/CI/linter hooks. It is one more external guard that itself needs a guard — infinite regress, and it lives near the agent's editable surface.
  • VCS (branches/worktrees, protected CI) as the corerejected: With multiple agents on one codebase it degrades into rebase/sync hell; centralized forges can collapse access and reorder priorities; jj+radicle+bare+worktrees multiply the surface. It governs the artifact after the fact, not the act.
  • Signed witness alone as the preconditionrejected: A witness is post-hoc evidence that X happened, not a barrier that forbids not-X (ADR-050). It becomes governance only when a control point refuses to proceed without a valid witness — i.e. inside a unit like the Work Order, not on its own.
  • Keep the constraints as typed prose in core.ncl / CLAUDE.md and rely on the agent reading themrejected: This is the exact failure being recorded: typed-but-unforced is still prose-unforced with better syntax. Loading context is not obeying it; only a unit that gates on a machine-checkable contract changes behavior.

Anti-patterns

  • Selling the Gate's Friction as the Permanent Product — Treating the Work-Order friction as the deliverable — 'ontoref makes your agent comply' — and forgetting it is transitional. This is the forbidden Yang-capture collapse of enforcement-vs-emergence: it repels, and it mistakes the teacher (friction) for the lesson (a form internalized until coherent action feels effortless).
  • The Operator Authoring the SOW It Must Satisfy — The executing agent writes (or edits) the Statement of Work whose contract it then satisfies, collapsing the ownership boundary. The lock is edited in the same gesture it is broken — the unit becomes advisory.
  • Claiming Done Without a Witness — A Work Order is treated as 'Accepted on the agent's prose claim, with no witness carrying the contract's real output. 'Done' degrades back to 'trust my word' — the exact failure the unit exists to forbid.
  • A Non-Machine-Checkable Contract Masquerading as a Gate — A SOW carries a 'contract' that is actually prose ('design the auth well') with no machine check and no 'Adversarial fallback. The unit looks governed but gates nothing — the failure mode wearing the costume of the fix.

Related ADRs

ADR-066 · ADR-050 · ADR-052 · ADR-056 · ADR-024 · ADR-029 · ADR-031

Was this useful? Rate it
Got something to add? Tell me what you think, what you'd suggest, or whether we should keep exploring this topic.
· reads

We use cookies to help this site function, understand service usage, and support marketing efforts. Cookie Policy for more info.