[Architecture] General conditional work contracts: five-axis separation, anti-monolith schema invariant, acceptance-authority model

[Sequela02]

Parent and status

• Related: [Architecture] Replace monolithic visual-reference-research with conditional visual-work contracts #9 (visual-specific first instance), [Architecture/Security] Make trusted-execution integrity reachable: operator authorization, effective-runtime observation, permanent-limitation acceptance #52 (operator authorization — authorizedBy precedent for axis separation).
• Research base: [Architecture] Replace monolithic visual-reference-research with conditional visual-work contracts #9 comments 5188090142 (vision + notes 31/32), 5188340139 (note 33 completion authority), 5188557099 (final advisor decision).
• Audited repository baseline for this specification: 1d090810 (dev).
• Research currency: 2026-08-05.
• Status: specified, awaiting independent audit. Implementation is not authorized until a findings-first review ratifies this contract or records amendments a maintainer accepts.

Objective

Make Kiln's governed-work contract model domain-neutral in its base by enforcing that the five separable axes of a work contract — intent, capability/identity, process/phase, evidence, assurance/acceptance — are never owned by a single token. Bind axes through explicit references, not through monolithic identifiers that silently fuse evidence with phase, route, capability, and identity.

The motivating defect is visual-reference-research (#9), which conflates all five axes into one token. This issue generalizes the lesson: the contract model must forbid the next monolith by construction, admit domain-specific overlays without baking them into the base, and resolve completion authority through a typed acceptance decision rather than through worker self-assessment or tool invocation.

Kiln's governing thesis is:

Kiln is a governed control plane for assigning, executing, reviewing, and reconciling work across agents, tools, runtimes, and human operators.

A capable token that fuses five axes is not governed merely because its tools are authorized and its final evidence is replayable. The contract must represent each axis as a separate field with its own validation, bind them through explicit references, and resolve completion through a typed acceptance decision that may require independent review depending on policy.

Decision requested

Determine whether Kiln should extend canonical Work Governance with a versioned, hash-bound general work-contract schema owned by Core, enforced by Runtime, and projected across every supported surface.

The review should decide:

1. whether the five-axis separation (intent, capability/identity, process, evidence, assurance/acceptance) is the correct minimal partition, or whether temporal context and risk triggers deserve promotion to first-class axes;
2. whether routeBinding is an execution binding outside the five axes (Kiln-general but not domain-general) or a sub-field of capability/identity;
3. whether the anti-monolith invariant is enforceable as a typed schema rule, a config validator, a runtime admission gate, or a combination;
4. how the acceptance-authority model resolves completion claims when self-assessment is insufficient;
5. which research and paired benchmark evidence is required before selecting defaults or making efficiency claims.

Motivation

The monolithic-token defect (root evidence)

#9 inventory (204 occurrences of visual-reference-research + 27 of browser-qa + 13 of implied visual-researcher across 28 files) proved that a single token can fuse five axes:

1. evidence type — KilnWorkGovernanceEvidence literal member;
2. workflow phase — ManagedInvocationPhaseId 1:1-mapped from the evidence id;
3. route selector — phaseRoutes["visual-reference-research"] key;
4. capability bundle — DEFAULT_EVIDENCE_REALIZATION["visual-reference-research"] = ["read","glob","grep"];
5. implied agent identity — taskAffinityForPhase("visual-reference-research") = ["research","frontend-design"].

No other evidence id in Kiln carries all five. The others group into semantic phases (surface-diagnosis, planning, implementation-verification, managed-review-closeout) without a dedicated route key, a 1:1 evidence→phase mapping, or an implied identity. The overloading encourages repeating the pattern: the next time Kiln needs to govern a new kind of work, the easiest path is to mint another monolithic token.

Self-assessment is not completion authority

Note 31 (AI-harness research) identified self-assessment as the dominant failure mode across OSWorld (best model 12.24% vs human 72.36%), WebArena (14.41% vs 78.24%), and the Anthropic long-running agent harness. Note 33 (cross-domain completion-authority research) confirmed from human governance: self-attestation may be admissible evidence for explicitly low-risk, reversible, or informal work, but it must not be labelled independent verification nor acquire implicit acceptance authority.

Kiln today treats browser-tool invocation as the success signal for the visual-reference-research obligation (governed-turn-outcome.ts:398-408), which is exactly the conflation the issue targets: a tool invocation is a capability, not completion evidence, and never acceptance authority.

Cross-domain convergence

Note 32 surveyed contract theory (Hart & Holmström 2016 Nobel), construction (FIDIC: plan→permit→build→inspect→occupy), medicine (clinical pathways, non-prescriptive), law (adversarial system exists because the dimensions must separate), audit (ISA 500 / PCAOB AS 1105: evidence-provenance hierarchy), ISO 9001:2015 (risk-based thinking, no fixed lifecycle), CMMI V3.0 (independent appraisal), and open-source CLAs. The five-axis separation recurs across every surveyed domain. The conflation evidence===phase===route===capability===identity does not appear in any non-programming governance domain.

Advisor decision (comment 5188557099)

The final advisor verdict: option C — implement #9 visual-specific with the schema constraint, open a separate general issue. The five-axis partition is the minimal defensible partition today. routeBinding is Kiln-general but not domain-general. Review independence is conditional (the universal rule is to declare completion claim, admissible evidence, and acceptance authority; if policy requires independence and no eligible reviewer exists, completion fails closed). The anti-monolith invariant is sound with a necessary refinement: a contract binds axes through explicit references; a token does not own them implicitly.

Current Kiln state

Kiln already has the correct architectural foundation for the axes individually:

• GoalRun owns objective, authority envelope, route policy, evidence requirements, lifecycle, and closeout (packages/core/src/work-governance/goal-run.ts);
• WorkItem owns scope identity, workflow/risk classification, dependencies, attempts, evidence, verification gates, pause requirements, and residual risk (packages/core/src/work-governance/work-item.ts);
• managed invocations preserve profile, provider/model route, authority, context mode, child identity, terminal state, handoff, usage, resources, and replay evidence;
• work-governance policy selects direct versus orchestrated execution and requires evidence before closeout;
• context governance bounds the active working set;
• evidence-realization.ts maps evidence requirements to required tool capabilities;
• governed-turn-outcome.ts enforces turn-level completion gates;
• phase-recovery.ts builds phase-specific recovery contracts;
• [Work Governance] managed_agent.invoke is not surfaced in kiln run sessions, so the orchestrate posture cannot be honored #50 made kiln run sessions admit managed_agent.invoke under read_only with child-authority bounding, and records a structured capabilityGap when delegation is required but unavailable or unused;
• [Architecture/Security] Make trusted-execution integrity reachable: operator authorization, effective-runtime observation, permanent-limitation acceptance #52 is producing operator trusted-authorization (authorizedBy, authorizedAt, scope, revocable) and effective-runtime observation — both are precedents for axis separation.

However, repository inspection shows that the canonical work contract does not currently enforce:

• a typed schema where each axis is a separate field with its own validation;
• an anti-monolith invariant that rejects a token owning semantic authority over more than one axis;
• a completionClaim / acceptanceDecision distinction that separates "the worker declared done" from "the resolved acceptance policy ratified it";
• a routeBinding field that is execution binding outside the five axes;
• a domain-overlay mechanism that admits domain-specific controls (safety gates, inspection, custody, stamps, waiting periods) without baking them into the base;
• an incomplete-contract default that treats silence as unresolved, not permissive.

Proposed architecture direction for investigation

The exact schema is intentionally not prescribed, but the review should evaluate these canonical concepts under the existing Work Governance bounded context.

1. Five-axis typed schema

A versioned, hash-bound work-contract schema owned by Core, enforced by Runtime, projected across every surface. The five axes:

Axis	Owns	Open question
Intent	objective, behavioral acceptance criteria, permitted effects, non-goals, scope envelope	is "scope envelope" a sub-field or its own axis?
Capability / identity	who or what is responsible; qualifications/tools/capabilities; licensing	is routeBinding separable or subsumed?
Process / phase	lifecycle stages; phase transitions; stopping conditions	declarative (config) or imperative (runtime state machine)?
Evidence	what was observed or produced; provenance (producer, subject/target, method, observedAt, version/freshness, scope/coverage, integrity, verdict, limitations, supersession, redaction)	full audit hierarchy or Kiln subset?
Assurance / acceptance	independent verification of completion; reviewer independence level; acceptance gate	universal or conditional? (note 33 settles: conditional)

Candidate axes NOT promoted (per advisor decision): temporal context (metadata distributed across axes); risk triggers (inputs to the policy resolver, not a first-class axis).

2. Route binding outside the five axes

routeBinding is Kiln-general but not domain-general. It is an execution binding: provider/model/runtime/tool/subagent resolved against the five-axis constraints. It must be a separate field, not a sub-field of capability/identity, and never a source of canonical semantics for any axis.

3. Anti-monolith invariant

No single contract token may be the canonical source of semantics for more than one axis. Links between axes must be explicit, validated references.

A contract binds axes together; a token does not. Composite profiles and references are permitted; implicit semantic ownership is not. An evidence id must not be 1:1-mapped to a phase id, a phaseRoute key, a capability bundle, and an agent identity at the same time.

The invariant must be enforceable. The review should determine whether it lives in the Core type system, config validation, runtime admission, or a combination.

4. Completion-claim and acceptance-decision

A worker (agent, child, human operator) may emit a completionClaim. Only the resolved acceptance policy may produce an acceptanceDecision. The two are distinct states and distinct actors:

• claimed — the worker declared done;
• verified — evidence satisfies the policy gates;
• accepted — the resolved acceptance authority ratified the claim;
• final — no supersession remains possible.

Self-assessment is not acceptance authority. Tool invocation is not completion evidence. Absence of error is not acceptance.

5. Conditional review independence

Review independence is conditional (note 33). The universal rule is to declare completion claim, admissible evidence, and acceptance authority. If policy requires independence and no eligible reviewer exists, completion fails closed. Independence is selected by consequence, detectability, reversibility, externality, information asymmetry, and mandate — not by a fixed universal rule.

6. Domain-overlay mechanism

The base is domain-neutral. Domain-specific controls (safety gates, inspection, custody, stamps, waiting periods, insurance/bonding) are admitted as versioned, executable Kiln-native overlays, not imported ISO taxonomies. An overlay adds types, rules, gates, and validators on top of the base. The pattern is conceptual ISO (AS9100/IATF 16949/ISO 13485); the mechanism is Kiln-native.

7. Incomplete-contract defaults

Silence on an axis means unresolved, not permissive. A declared overlay or policy may complete defaults. Without resolution, dispatch or acceptance blocks according to the axis. Never infer review, authority, or completion from executor identity, tool invocation, or absence of error.

Cross-surface, cross-harness, and cross-provider invariants

• Core owns canonical contract schema and state; Runtime owns admission, accounting, transitions, and terminal truth.
• GUI, TUI, CLI, SDK, MCP, and replay only project the canonical state; they do not own contract policy.
• Direct providers and native harness adapters report capabilities and evidence; they do not own contract, review, or acceptance policy.
• Harness capability degradation produces a typed pause or admitted alternative route, never simulated compliance in prose.
• Provider changes do not reset contract lineage, evidence, or acceptance state.
• No hidden retry, route reassignment, or acceptance reinterpretation occurs after commitment.
• Unknown evidence, missing provenance, or unsupported review remains explicit.
• A child cannot lend contract authority, scope, acceptance authority, or unused budget to another child.
• Surface-local configuration may narrow canonical limits but cannot widen them without an admitted operator decision.

Required research before design approval

The architecture review must include:

1. a repository-wide inventory of existing goal, work-item, attempt, managed invocation, evidence, context, cancellation, timeout, replay, and benchmark contracts, proving which axes are already separated and which are conflated;
2. an explicit bounded-context and dependency-direction proposal showing why the work belongs in existing Work Governance rather than a new control plane;
3. primary-source research on AI-harness approaches to the five axes (Anthropic, OpenAI, Google/Gemini CLI, Claude Code, Codex, OpenCode — note 31 already covers this; verify currency);
4. primary-source research on cross-domain governance (notes 32/33 already cover this; verify currency);
5. a capability matrix for Codex direct/native, OpenCode direct/native, Claude Code native, Gemini CLI native, and Kiln-owned surfaces;
6. threat modeling for axis collapse (token monolith recurrence), acceptance-authority bypass (self-assessment as authority), contract-reset via route/provider change, fabricated evidence, stale acceptance, and adapter-local policy drift;
7. a paired benchmark design that freezes task, repository baseline, provider/model, harness/adapter version, authority/tool catalog, context policy, acceptance criteria, and scorer set, recorded in the benchmark-publication contract.

Tests-first implementation order

1. Add failing Core tests for the five-axis schema, anti-monolith invariant, routeBinding separation, completionClaim/acceptanceDecision distinction, and incomplete-contract unresolved defaults.
2. Add a failing Runtime integration proving that a contract with a monolithic token (evidence===phase===route===capability===identity) is rejected at admission with a typed reason.
3. Add a failing Runtime integration proving that a completionClaim without a resolved acceptanceDecision blocks closeout.
4. Migrate the first concrete instance ([Architecture] Replace monolithic visual-reference-research with conditional visual-work contracts #9 visual) to the new schema, proving that the visual contract still works and no longer fuses axes.
5. Add the second concrete instance (managed-agent/provider-routing change) proving that a non-visual contract separates route, executor capability, evidence, review, and acceptance without screenshots.
6. Add the domain-overlay mechanism with one overlay (e.g., the managed-agent overlay) and prove it adds gates without modifying the base.
7. Project contract state through records, history, replay, and all operator surfaces with portable sanitized fixtures.
8. Update architecture and the long-term vision only after focused tests, affected tests, workspace typecheck/build, git diff --check, and independent high review.

Required deterministic scenarios

1. A contract with a monolithic token (evidence id = phase id = route key = capability bundle = identity hint) is rejected at admission with an explicit anti-monolith reason.
2. A contract with five separate axes and explicit references is admitted and traverses intent→process→evidence→acceptance.
3. A completionClaim emitted by the worker without a resolved acceptanceDecision blocks closeout.
4. A completionClaim ratified by an independent reviewer produces accepted; a completionClaim denied produces rejected; a completionClaim with no eligible reviewer and policy-requiring-independence fails closed.
5. A routeBinding referencing an ineligible executor (capability mismatch, authority mismatch) is rejected before dispatch.
6. A domain overlay adds a gate (e.g., provider-routing requires adversarial review) that blocks acceptance until satisfied; removing the overlay returns to base behavior.
7. An incomplete contract (silent on review) is unresolved and blocks dispatch or acceptance according to the axis, with no inference from executor identity or tool invocation.
8. Concurrent work cannot reset contract lineage, evidence provenance, or acceptance state.
9. Replay and every surface explain contract state, axis bindings, completion claim, acceptance decision, and residual risk without secrets.
10. The [Architecture] Replace monolithic visual-reference-research with conditional visual-work contracts #9 visual contract migrated to the new schema produces the same governed-work outcomes as today without fusing axes.
11. The managed-agent/provider-routing contract separates route, executor capability, evidence, review, and acceptance without screenshots.
12. Migration of historical evidence ids (visual-reference-research, browser-qa) to the new contracts is forward-only; new writes cannot emit the old monolithic ids; a temporary migration reader converts historical evidence without enabling new legacy writes.

Completion criteria

• Independent audit ratifies or explicitly amends this contract before implementation.
• Core owns one provider-neutral five-axis work-contract schema with routeBinding, completionClaim, and acceptanceDecision as separate typed fields.
• The anti-monolith invariant is enforceable (Core type, config validation, runtime admission, or combination) and rejects a token owning semantic authority over more than one axis.
• routeBinding is an execution binding outside the five axes, never a source of canonical semantics for any axis.
• A completionClaim is not an acceptanceDecision; only the resolved acceptance policy produces authority.
• Self-assessment, tool invocation, and absence of error never acquire implicit acceptance authority.
• Review independence is conditional; policy may require independence and fail closed when no eligible reviewer exists.
• The domain-overlay mechanism adds types, rules, gates, and validators without modifying the base.
• Silence on an axis is unresolved, not permissive.
• Two bounded instances validate the model: visual [Architecture] Replace monolithic visual-reference-research with conditional visual-work contracts #9 and managed-agent/provider-routing change.
• All 12 deterministic scenarios pass with portable synthetic fixtures.
• Focused suites, affected packages, full tests, typecheck, build, E2E, teardown, and git diff --check pass on the exact candidate.
• Independent reviews have no unresolved high or medium slice-caused findings.
• Stable architecture and the long-term vision match executable behavior.
• The explicit closeout comment records every required evidence item and residual risk.

Non-goals

• No ontología para construcción/medicina/derecho; Kiln governs software work today; domain overlays are admitted, not pre-built.
• No workflow DSL universal; phases are declarative contracts, not a programming language.
• No marketplace de overlays; overlays are versioned executable config, not installable plugins.
• No full audit hierarchy (ISA 500 / PCAOB AS 1105) imported wholesale; use the Kiln subset until a real consumer demands more.
• No nueva provider abstraction; routeBinding uses existing provider/model/runtime resolution.
• No migración de todos los perfiles existentes en este issue; migration is per-instance, starting with [Architecture] Replace monolithic visual-reference-research with conditional visual-work contracts #9 visual.
• No compatibility layer indefinida; historical readers are one-way and temporary; new writes cannot emit old monolithic ids.
• No implementation before architecture and benchmark review approve a bounded slice.

Residual risk

• Two-instance generalization: five axes and the anti-monolith invariant are validated against two software instances only (visual [Architecture] Replace monolithic visual-reference-research with conditional visual-work contracts #9, provider-routing). A third instance may reveal that the partition is incomplete. The schema is provisional until a third instance validates. Do not claim operational universality from two cases.
• No causal benchmark: no benchmark isolates the anti-monolith invariant as a causal variable for outcomes. Decomposition, grounding, and external-verification evidence supports it directionally but does not prove it.
• Cross-domain self-assessment multiplier: no reliable cross-domain multiplier of self-assessment defect rates exists; note 33 acknowledges this. Conditional independence is a defensible policy, not a measured constant.
• Five axes are not proven final: they are the minimal defensible partition today. Six or seven axes would promote cross-cutting concerns to premature entities.
• Cloned harness evidence is a snapshot: note 31's harness details are point-in-time observations, not permanent product capabilities.
• Domain-overlay mechanism is novel: concept follows ISO, but Kiln-native enforcement is untested. Overlay drift, versioning conflicts, and base/overlay interaction need threat modeling.

Delivery constraints

• This issue does not authorize implementation.
• Begin with independent architecture/research review.
• Any later implementation branch must start from dev and target a dedicated integration branch.
• Keep contracts provider-neutral and delete obsolete paths instead of preserving speculative compatibility layers.
• Use synthetic portable fixtures for deterministic CI; live provider/harness proof remains explicit, bounded, and separately authorized.
• [Architecture] Replace monolithic visual-reference-research with conditional visual-work contracts #9 visual-specific implementation proceeds independently and must satisfy the schema invariant; this issue ratifies the invariant as a cross-cutting rule after the second instance validates.
• Do not merge as part of the initial implementation task.

Final architecture rule

A contract binds axes together; a token does not. A worker may claim completion; only the resolved acceptance policy may make that claim authoritative.

[Sequela02]

Input to the pending audit: the assurance/acceptance axis

Researched 2026-08-17 while implementing #89. This bears on decision items 1
(is the five-axis partition correct) and 5 (what evidence is required before
selecting defaults). Offered as input, not as an amendment.

The axis is under-specified in a way that blocks consumers

BoundedWorkIntent.acceptanceCriteria is readonly string[]. Free text has no
identity, so no evidence can reference a criterion. #89 hit this directly:
unprovenCriteria has to take caller-supplied criterion ids because the
contract exposes none. Any evidence-to-criterion binding is currently
unrepresentable, which means the assurance axis exists as a concept but has no
schema.

Prior art converges on one answer

ISO/IEC/IEEE 29148:2018 (current edition, superseding 2011) treats a
requirement as carrying attributes, verification method and strategy among
them, and names traceability and verifiability as quality criteria. NASA,
INCOSE, and SEBoK converge on the same four verification methods: test,
analysis, inspection, demonstration, where analysis covers models, simulation,
and formal reasoning.

That taxonomy already fits Kiln's evidence without adaptation:

Method	Existing Kiln evidence
test	tests, browser-qa
analysis	typecheck, formal-proof
inspection	managed-agent-review, security and DDD review
demonstration	execution records, replay

Every current evidence identity maps to exactly one method, which is weak
evidence that the partition is right rather than imposed.

Suggested shape: a criterion becomes { id, statement, verificationMethod, required }. Adopting it in the contract means the method is fixed before work
starts and cannot change without a visible revision, which is the property that
keeps the mapping off the worker.

Evidence identity: align with in-toto, with a correction

BoundedWorkCandidateEvidence is already structurally an in-toto Statement:
subject bound by digest, a kind, an evidence digest. Aligning names would make
Kiln evidence readable by existing supply-chain tooling instead of remaining a
private format.

Two corrections to what circulates in secondary sources:

• The current framework release is v1.2.0 (2026-03-18). The statement type
  is https://in-toto.io/Statement/v1. There is no v2.0.0 release.
• v1.2.0 added a Simple Verification Result predicate,
  https://in-toto.io/attestation/svr/v0.2, which carries verifier identity,
  timeCreated, and verified properties against a digest-bound subject.

SVR is close to Kiln's verdict but cannot replace it: properties records
only passing properties, and the spec states it "does not include information
for reproducing the verification result." Kiln binds refuted verdicts
deliberately, so a failed proof leaves a trace and can drive repair. The usable
split is SVR as an export or publication format, with the richer verdict kept
as the internal record.

Scope this should not acquire

DO-178C and ISO 26262 answer the same question with a certification apparatus
that is wrong for Kiln; the transferable parts are traceability and
method-per-requirement, not the process weight. Assurance cases and GSN are the
correct shape for arguing why evidence supports a claim, and are far heavier
than anything Kiln needs today.

Consequence for #89

Step 3 of #89, gating closeout on bound evidence, needs addressable criteria
and is therefore blocked on this issue. #89 will not invent a criterion
identity model in the meantime, since doing so would pre-empt exactly what this
audit is meant to decide.

[Sequela02]

Verification note on the item 1 inventory

The five-axis inventory follows as a separate comment. It was produced against
dev@6bf21063 by an external audit pass. I spot-checked its two load-bearing
claims against the same commit before posting. One held, two need correction,
and the combination points somewhere the issue does not currently emphasise.

Correction 1 — the conflation dependency count is understated

The register reports 7 production files depending on
visual-reference-research. The count at 6bf21063 is 11. Missing from the
register:

• packages/cli/src/config/global-config.ts
• packages/core/src/work-governance/evidence-realization.ts
• packages/runtime/src/agents/managed-invocation/runtime-tool/tool-schema.ts
• packages/gateway-contracts/src/config-status.ts

The last one matters beyond the count. packages/gateway-contracts was outside
the audited scope, which covered packages/core/src, packages/runtime/src,
and packages/cli/src only. The token therefore reaches a wire-contract
package that the inventory never examined, so the #9 migration surface is
larger than reported and crosses a contract boundary rather than staying inside
application code.

The inventory disclosed this risk itself in its section 4.1. This confirms the
disclosed limitation rather than contradicting the work.

Correction 2 — reviewer independence is represented, enforced, and fails closed

The inventory records assurance as partial or absent in all ten families and
states that reviewer independence is not represented. That is not correct at
this commit:

if (signals.requiresIndependentReview) {
  const concurrency = Math.min(signals.workItemCount, signals.maxParallelWorkers);
  if (concurrency < 2) {
    return {
      status: "denied",
      reasons: ["independent review requires capacity for at least two children"],
      missingCapabilities: ["independent-review-capacity"],
    };
  }

packages/core/src/agents/managed-invocation/coordination-policy.ts:66-79, with
the signal plumbed through runtime-tool/orchestration-work-items.ts:88 and
declared required in runtime-tool/tool-schema.ts:433,452.

This is note 33's conclusion already implemented: where policy requires
independence and no eligible reviewer capacity exists, the decision is denied
rather than downgraded. The audit's independence question therefore has a
working precedent in the codebase, in managed-agent coordination rather than in
the work-contract families the inventory scoped.

What the inventory does establish, and what follows from it

Two findings survive unchanged and should shape the audit.

One strict conflation exists, not a pattern. visual-reference-research is
the only token in the audited scope owning more than one axis. No second
monolith was found. The premise that the contract model must "forbid the next
monolith by construction" is therefore a response to one observed instance, not
to a demonstrated recurrence. That does not make the invariant wrong, but it
changes the evidentiary weight behind prioritising it.

Assurance and acceptance is partial or absent in ten families out of
ten. That is the only axis with no clean row anywhere in the table.

This converges with a defect found independently while implementing #89.
decideBoundedWorkCloseout calls requireBoundedWorkDigest on
criterion.evidenceDigest and discards the result
(packages/core/src/work-governance/bounded-work-decision.ts:292). That helper
is a regex over ^sha256:[a-f0-9]{64}$
(packages/core/src/work-governance/bounded-work-content.ts:7-12), and nothing
in the repository resolves an evidence digest back to a record. Any well-formed
hex string therefore satisfies an acceptance criterion, supplied by the same
caller whose work is being judged.

The inventory sees this as structural absence across ten contract families. The
#89 work saw it as one concrete fail-open in the acceptance gate. They are the
same finding from two directions.

Suggested consequence for the audit: the anti-monolith invariant addresses a
real defect with one instance and a known migration path. Acceptance integrity
is weak everywhere and currently exploitable. If the audit must sequence its
own work, the evidence supports treating the acceptance axis as the more urgent
of the two.

[Sequela02]

Synthesis across required-research items 1, 3, and 4

Items 1, 3, and 4 are posted. Read separately each answers its own question. Read
together they support a conclusion none of them states, and it bears directly on
what this audit should decide.

The convergence

Source	Finding
Item 1, Kiln inventory	assurance/acceptance is partial or absent in 10 of 10 contract families — the only axis with no clean row
Item 3, six AI harnesses	none requires an organizationally independent acceptance authority; evidence is operational everywhere and criterion-bound nowhere
Item 4, cross-domain governance	independence is mandatory in real governance regimes, conditionally, by nine identifiable factors
#89 implementation	decideBoundedWorkCloseout accepts any well-formed digest as acceptance evidence

Stated as one sentence: the AI harness industry has no acceptance axis, Kiln
does not have one either, and the governance domains that do have a principled
rule for when it is required.

Three consequences for this issue

1. Axis separation is not the differentiating thesis. Item 4 set out to
falsify the recurrence claim and partly succeeded: no reviewed domain models five
named axes, and several deliberately fuse roles — EU Module A, FIDIC's Engineer,
FRCP Rule 11 certification, FAR contractor self-inspection. What is genuinely
distinctive is not separating five axes. It is implementing conditional
acceptance authority with explicit selectors, which item 3 shows no harness does.

2. The advisor's disposition on risk triggers now has empirical backing.
Comment 5188557099 placed risk triggers as inputs to the policy resolver rather
than a first-class axis. Item 4 independently derived nine factors that determine
when independence becomes mandatory — consequence of false acceptance, externality
and authority effect, detectability and latency, reversibility and cost to cure,
conflict of interest, information asymmetry, evidence auditability, express
mandate, and assurance cost. FAR 46.202-2 and Decision 768/2008/EC name several of
these selectors literally. That is the shape of a policy resolver input, not an
axis. The prior decision holds and is now supported rather than asserted.

3. The anti-monolith invariant is validated as a distinctive pathology. Item 4
actively searched nine governance domains for a single token owning
evidence === phase === route === capability === identity and found none. Combined
with item 1 finding exactly one such token in Kiln, the picture is not that axis
collapse is a common failure this contract must repeatedly prevent. It is that
axis collapse is a pathology of configuration and identifier systems that human
governance regimes do not exhibit. That strengthens the invariant's rationale
while lowering the evidentiary weight behind treating recurrence as the primary
risk.

The finding worth acting on

Correcting item 1: Kiln already implements conditional independence and it already
fails closed.

if (signals.requiresIndependentReview) {
  const concurrency = Math.min(signals.workItemCount, signals.maxParallelWorkers);
  if (concurrency < 2) {
    return { status: "denied", reasons: ["independent review requires capacity for at least two children"], … };
  }

packages/core/src/agents/managed-invocation/coordination-policy.ts:66-79.

Cross-referenced against item 3: none of the six harnesses has an equivalent.
Not the Claude Agent SDK, not the OpenAI Agents SDK, not Gemini CLI, Claude Code,
Codex, or OpenCode. Where a final gate exists at all it is an optional
host-configured hook, and OpenCode has no public completion veto whatsoever.

So Kiln is already ahead of every surveyed harness on the acceptance axis, in one
subsystem — managed-agent coordination — and does not apply the same discipline at
closeout, where requireBoundedWorkDigest performs a regex and discards the
result.

Suggested consequence

The audit's contested questions are mostly about the shape of the partition. The
evidence gathered so far says the partition is the less urgent half. Kiln has one
axis-collapse instance with a known migration path, and a systematically weak
acceptance axis with a live fail-open and an existing internal precedent for how
to fix it.

If this audit sequences its own work, the evidence supports resolving acceptance
authority first, and treating the anti-monolith invariant as the second
deliverable rather than the headline.

[Sequela02]

Assessment of the item 7 benchmark design: accepted, not funded

The paired benchmark design follows as a separate comment. It is methodologically
sound and I am not asking for changes to it. I am recommending it is not run yet,
for a reason about sequencing rather than quality.

What it does well

Three choices are worth preserving regardless of whether this design executes.

False acceptance as the primary outcome, not task success. Task success would
mostly measure model capability. The contract exists to stop evidence, process, or
worker claims acquiring implicit acceptance authority, so the outcome has to be
the rate at which defective packets are accepted.

The valid-packet guardrail. Without it, a treatment that answers reject to
everything would look excellent. Requiring that correct acceptance not fall by
more than five points is what separates governance discrimination from blanket
conservatism. This is the sharpest part of the design.

One factor, strictly. contractProjectionMode is the only differing field,
and neither arm receives an authoritative gate. That deliberately avoids repeating
the bundled-treatment defect #58 records in its own H2 arm.

Why it should not run yet

The design measures whether a five-axis representation changes an LLM reviewer's
acceptance decision. That is a real question. It is not the question currently
blocking anything.

The defect found while implementing #89 is that decideBoundedWorkCloseout
accepts any well-formed digest as acceptance evidence
(packages/core/src/work-governance/bounded-work-decision.ts:292, with
requireBoundedWorkDigest being a regex at
packages/core/src/work-governance/bounded-work-content.ts:7-12). That is a code
defect and it is deterministic. Whether a gate rejects a stale or fabricated
digest is decidable by construction, with a unit test, in hours.

A benchmark is the right instrument for questions that cannot be decided by
construction. Model judgment under a changed representation qualifies. Whether a
function rejects invalid input does not.

The design says as much in its own section 8:

It cannot show the effect of an authoritative runtime gate, because both arms
deliberately use the same non-authoritative review execution.

So #58 asks whether a verification gate pays, and this design excludes gates from
both arms in order to stay methodologically clean. That is the correct call for
this design, and it means the design does not answer #58. There is currently no
gate to measure.

Cost, stated plainly

4,000 valid model sessions across two strata, up to 5,600 attempts. Serial
execution at the design's own estimates gives 67 to 333 elapsed executor hours,
and up to 64 million input tokens. The effect-size assumption underpinning the
power calculation is preregistered honestly as an assumption with no pilot behind
it, and the design acknowledges that a higher intraclass correlation could leave
the interval inconclusive.

That is a substantial commitment for a result that would not unblock current work.

A defect the design found incidentally

While auditing the harness, the design noted that execution-integrity records
route identity rather than checking it. Verified at 6bf21063:

if (typeof providerId !== "string" || providerId.trim().length === 0
    || typeof modelId !== "string" || modelId.trim().length === 0) {
  return { score: 0, reasoning: "successful session is missing resolved provider/model route identity" };
}
return { score: 1, reasoning: "successful terminal state and resolved route identity observed" };

packages/core/src/eval/benchmark-scorers.ts:246-266. The scorer requires
provider and model identity to be non-empty. It never compares them to an expected
identity. A benchmark can therefore execute against a different model than
intended and still score as execution-clean.

That matters beyond this design: every existing benchmark result carries the same
weakness. It should be fixed independently of whether this benchmark ever runs.

Recommendation

1. Record this design as accepted and not funded, with the three preserved
   choices above.
2. Close the closeout fail-open by construction and prove it with a test, rather
   than measuring it.
3. Open a separate issue for the execution-integrity identity check.

Revisit the benchmark when an authoritative gate exists and the question becomes
whether it pays in real work. That question is genuinely empirical. The current
one is not.

[Sequela02]

Correction to my earlier synthesis: the independence claim was overstated

The item 2 analysis follows as a separate comment. It corrects a claim I made in
the synthesis above,
and the correction matters enough to state separately rather than leave buried.

I wrote that Kiln "already implements conditional independence and it already
fails closed," and that it is "ahead of every surveyed harness on the acceptance
axis." Verified at 6bf21063, that is overstated in two layers.

The trigger is supplied by the caller

requiresIndependentReview is a required caller input on the orchestration
tool:

required: ["profile", "taskRisk", "requiresIndependentReview", "workItems"]

packages/runtime/src/agents/managed-invocation/runtime-tool/tool-schema.ts:452.

Runtime passes it straight through with no governance provenance:

requiresIndependentReview: rawInput.requiresIndependentReview === true,

packages/runtime/src/agents/managed-invocation/runtime-tool/orchestration-work-items.ts:88.

So the party whose work would be reviewed is the party declaring whether review is
required. Supplying false means the gate is never reached. The Core selector is
real, but one of its decisive policy facts arrives as a caller assertion.

"Independent" is not verified

if (request.mode === "review-swarm") {
  requireMinimumChildren(request, 2, "Managed review-swarm orchestration requires at least two children");
  requireEvidenceKinds(request, ["review-findings", "comparison-summary"]);
  requireMergePolicy(request, "manual-review-required", false, false, …);

packages/core/src/agents/managed-invocation/orchestration.ts:660-664.

The validation requires two children and the right evidence shapes. It never
compares producer identity against reviewer identity. Two children is execution
capacity, not independence.

The mode's own contract also stops short of acceptance: manual-review-required
merge policy with adoptionRequired and adoptionReadinessRequired both false
(packages/core/src/agents/managed-invocation/orchestration.ts:257-270). Treating
its output as acceptance authority assigns stronger semantics than the contract
claims for itself.

What the corrected claim is

Kiln fails closed on capacity to run a review topology, when a caller asks for
one. It does not fail closed on independence, and it does not derive the
requirement from governance policy.

That is still more structure than the six harnesses in item 3 expose, none of
which has a comparable concept at all. It is considerably less than "conditional
independence implemented," which is what I claimed. The comparison to other
harnesses stands; the characterisation of Kiln's own mechanism does not.

The pattern this belongs to

This is the third instance of the same defect shape found today, and the
repetition is more informative than any single case:

Location	Validates	Should validate
bounded-work-decision.ts:292	that the evidence digest has sha256 shape	that the digest resolves to real evidence
benchmark-scorers.ts:246-266	that provider and model identity are non-empty	that they are the expected identities
orchestration.ts:660	that two children exist	that the reviewer is independent of the producer

Three subsystems, one failure mode: validating the shape of a thing instead of the
thing. Each was written as a genuine check and each is satisfiable without the
property it exists to establish.

That suggests the audit's remit is broader than the acceptance axis alone. The
recurring question is not which axis owns what, but where Kiln accepts a
well-formed assertion in place of a verified fact.

[Sequela02]

Required-research item 2 — Acceptance-authority ownership — 2026-08-17 — dev@6bf21063

Condensed from the full analysis. Every citation is pinned to 6bf21063.

Verdict

Option 3, with a correction to how it was framed. The two code paths are
genuinely different concerns, not duplicate implementations competing for
ownership. But acceptance authority belongs to Work Governance, and the canonical
bridge between the concerns does not exist.

The defect is not that the concept lives in two places. It is that the acceptance
decision is represented nowhere: a caller-supplied Boolean substitutes for the
pre-execution policy decision, while criterion-string equality and digest syntax
substitute for terminal ratification.

What requiresIndependentReview actually owns

Topology selection and capacity admission. Not acceptance policy.

decideManagedAgentCoordination receives the Boolean already asserted. It has no
criterion, candidate, evidence record, producer identity, or reviewer identity
from which it could derive one. When true it computes concurrency, denies below
two children, and selects review-swarm
(packages/core/src/agents/managed-invocation/coordination-policy.ts:16-81).

That is a valid fail-closed answer to "can this graph realize a review topology?"
It cannot answer "does this work require independent review, and may these results
ratify this candidate?"

Two facts confirm the boundary:

• review-swarm uses manual-review-required merge policy with adoptionRequired
  and adoptionReadinessRequired both false (orchestration.ts:257-270). The mode
  explicitly stops before acceptance.
• Its validation requires two children and the right evidence kinds
  (orchestration.ts:660-664). It never compares producer against reviewer
  identity. Two children is capacity, not independence.

The provenance is the more serious error. The Boolean is a required caller input
(runtime-tool/tool-schema.ts:452) passed straight through
(runtime-tool/orchestration-work-items.ts:88). A Core policy selector is
consuming a policy assertion from the tool caller.

That disagrees with stated architecture twice: coordination topology is supposed
to be selected by Core policy and never owned by a surface
(docs/architecture/core/invariants.md:16-44), and bounded contexts are supposed
to communicate through explicit interfaces (identity.md:70-79). No Work
Governance interface produces the independence requirement today.

Related policy exists but does not fill the gap: CLI workflow policy adds
managed-agent-review to required evidence for architecture, security, runtime,
provider-routing and managed-agent triggers
(work-governance-policy.ts:69-85, work-governance-workflows.ts:35-102). It is
unconnected to requiresIndependentReview, and requiring evidence with a review
label is not requiring a reviewer independent of the producer.

Recommended placement

An Assurance policy seam inside Core Work Governance. Not in coordination, and
not folded into candidate binding.

Concern	Owner
Objective and acceptance criteria	Work Governance intent
Which candidate, and what evidence concerns it	Work Governance candidate binding
Whether independence is required; whether evidence may ratify	Work Governance assurance policy
Selecting and executing a topology that produces review evidence	Managed coordination + Runtime
Applying the authorized result to terminal state	Work Governance closeout, enforced by Runtime

Closeout needs a dependency on a canonical evidence-and-identity resolver, not
on coordination. Runtime owns the durable records and supplies resolved
observations to a pure Core decision. A direct Core dependency on a Runtime
repository would violate the layer rule; a Runtime composition that reads records
and invokes Core policy respects it.

bounded-work-candidate.ts is the right seam for binding and the wrong one for
ratifying. Its evidence record binds a digest to candidate content and contract
revision but carries no criterion, actor, or decision
(bounded-work-candidate.ts:27-57). Its "acceptance" evidence kind is a
subject-binding label, not authority. Putting ratification there would conflate
"what candidate does this concern?" with "may this close the contract?"

Alternative considered, and why it loses

Making coordination the owner and having closeout depend on it fails on four
counts:

1. Coordination is one execution mechanism. Direct execution, human review, and
   external-system evidence must remain eligible. Canonical completion cannot
   depend on whether work happened to use managed children.
2. Coordination lacks the facts. Its input describes graph size, risk, route
   availability, and capacity. Adding candidate, criteria, evidence and identity
   would turn a topology selector into a second Work Governance implementation.
3. Review-swarm stops before acceptance by its own contract, as above.
4. Wrong dependency direction. Closeout would depend on an agent-execution
   context to decide a primitive that must also work without managed agents
   (docs/architecture/core/work-governance.md:164-209).

Migration cost

14 directly coupled files — 10 production or benchmark, 4 test — plus 7
adjacent seams requiring review.

Area	Files	What breaks
Managed coordination	4	The raw caller assertion can no longer be the authoritative source
Work Governance requiredness	2	CLI review labels must stop being mistaken for independence authority
Terminal closeout	3	Callers can no longer manufacture acceptance from digest-shaped strings
Benchmark fixture	1	kiln-managed-frontend-team-v1.jsonl encodes the caller-owned contract
Direct tests	4	Encode the raw Boolean or synthetic criterion/digest closeout input

The review-swarm implementation itself need not move. What changes is the strength
of claim it may support: it can show a review topology was requested and executed,
but only assurance policy can decide whether the records constitute independent
evidence.

Residual risk

Criterion-to-assurance coupling is unresolved. If acceptance authority must
know which verification method a criterion demands, the current contracts cannot
supply that fact. That is evidence Intent and Assurance need an explicit coupling
rule. It does not justify restoring the rejected verificationMethod field under
another name.

Reviewer independence is not provable from current records. Candidate evidence
binding records candidate and digest identity, not the actor that produced or
ratified it. Until those facts reach assurance, closeout can prove at most "a
review-labelled record exists," never "an authorized independent reviewer
evaluated this candidate."

Pre-execution and post-execution can drift even after ownership is corrected.
Policy may require independence, coordination may select a two-child topology, and
the resulting evidence may still come from the candidate author or target a stale
candidate. Topology admission and terminal assurance must stay two decisions
connected by provenance, not collapsed into one.

Acceptance-authority identity is undefined. No inspected record represents a
human or agent's authority to accept across direct, managed, and external-runtime
work. That affects the eventual enforcement mechanism, not the placement
conclusion.

[Sequela02]

Required-research item 5 — blocked on route access, not on method

Attempted 2026-08-17 against dev@6bf21063. 31 of 35 cells are unmeasured.
Posting the outcome rather than the matrix, because a matrix with that coverage
would misrepresent itself.

Why it could not be completed

The item assumes access to six execution routes. This operator has usable quota
on one.

Route	State
Claude Code 2.1.234	measurable — 5 of 7 capabilities, 2 rated partial
Codex 0.147.0	quota exhausted mid-session; reset reported as 2026-09-13
OpenCode 1.18.18	no quota; every model call returns 401 from the provider endpoint
Gemini CLI	not installed
Kiln-owned surfaces	stale dist rejects the global config with Unknown global config field: workerRouting

This is a resource constraint, not a measurement-design failure. The probes ran;
the routes did not answer.

That is itself worth recording for the audit. Item 5 as specified requires
funded access to six routes simultaneously. A solo operator may never hold that,
which makes the capability matrix a recurring dependency the audit cannot assume
is satisfiable on demand. Any deliverable sequenced behind it inherits that.

The one finding that did not depend on quota

Given an unresolvable model id, the Claude CLI returns a single result object
containing:

"is_error": true, "terminal_reason": "api_error", "api_error_status": 404, "subtype": "success"

Reproduced identically twice. The failure reaches the protocol layer without
consuming quota, which is why it was measurable when nothing else was.

A consumer keying on subtype — the field whose name most invites it — would
classify a hard model-not-found failure as a success.

Kiln does not make that mistake: claude-code-process.ts branches on is_error,
never on the subtype. But it used the subtype as the error code, so this run
surfaced as an error whose code read success. Fixed in e40c9aab, with a
regression test carrying the exact observed shape.

The contrast case is worth keeping: Codex hit its quota ceiling and failed closed
with a typed error in under a second. That is the correct degradation behavior,
measured rather than assumed.

What a redo needs

Not a re-run of the same task. The item should be re-scoped first:

• Narrow the route set to routes the operator actually funds, and record the
  rest as out of scope with the reason. Six routes is an aspiration, not a
  prerequisite.
• Separate protocol-layer probes from execution probes. The Claude finding
  cost nothing because a 404 never reaches a model. Several capabilities —
  identity reporting, structured-output shape, degradation on unknown inputs —
  can be measured the same way. Ordering the cheap probes first would have
  produced more coverage from the same access.
• Unblock the Kiln surfaces, which are the rows the audit most needs and the
  only ones blocked by something under this project's control.

Re-attempt after 2026-09-13 would restore Codex only. It would not restore
OpenCode or Gemini, so it would not complete the matrix as specified.

[Sequela02]

Correction to the item 5 note above: the Codex reset date I recorded as 2026-09-13 came from the probe transcript and is wrong for this account. The operator's Codex limits reset 2026-08-20, three days from posting. OpenCode quota is separately purchasable and inexpensive; Claude quota remains available.

That materially changes the re-attempt window. A scoped re-run covering Codex, Claude, and OpenCode becomes possible within days rather than a month, which leaves Gemini CLI (not installed) and the Kiln-owned surfaces (stale dist) as the only genuinely blocked rows.

The re-scoping recommendation in that note still stands and matters more than the date: order protocol-layer probes ahead of execution probes. The one finding that survived — the Claude CLI reporting is_error: true alongside subtype: "success" — cost no quota because a 404 never reaches a model. Identity reporting, structured-output shape, and degradation on invalid input are all measurable that way, and running them first would have produced more coverage from the access that existed.