[Architecture/Research] Add native bounded-work authority for scope fidelity and overengineering control

[Sequela02]

Summary

Define a native, provider-neutral bounded-work authority for Kiln that constrains scope expansion, overengineering, execution attempts, agent fan-out, review loops, and resource consumption across GUI, TUI, CLI, SDK, MCP, replay, direct-provider routes, and native harness adapters.

This is an architecture and research issue, not an approved implementation roadmap. It must receive independent architecture review before any delivery slice is admitted.

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 model that can continue discovering work indefinitely is not governed merely because its tools are authorized and its final evidence is replayable. Kiln must also govern how far the work may expand, how much execution it may consume, when it must stop, and which operator decision is required before exceeding the original contract.

Decision requested

Determine whether Kiln should extend canonical Work Governance with a versioned, hash-bound bounded-work contract owned by Core and enforced by Runtime.

The review should decide:

1. which scope, execution, correction, and stopping invariants belong in the canonical contract;
2. which limits are hard authority boundaries versus configurable tripwires;
3. how usage and work expansion are normalized when a harness or provider exposes incomplete evidence;
4. how the same decision and terminal state are projected across every supported surface;
5. which research and paired benchmark evidence is required before selecting defaults or making efficiency claims.

Motivation

Recent community reports around high-autonomy coding models describe a recurring failure mode:

• a small correction expands into hours of unrelated refactoring;
• the agent introduces new abstractions, infrastructure, and compatibility paths without an identified consumer;
• review and remediation repeat long after the requested behavior is satisfied;
• many child agents are invoked without a bounded evidence need;
• tests are added to mirror the generated diff rather than prove user-visible behavior;
• token and quota consumption grows because the model has no enforceable stopping condition.

These reports are motivating incidents, not benchmark evidence. Kiln must not turn anecdotal token comparisons into product claims. The architectural question is whether the failure class is real and whether Kiln can govern it through provider-neutral runtime contracts.

Gentle AI v2.2.0 / Organic RDD is a useful comparative case study: it demonstrates native candidate binding, risk-derived review tiers, bounded correction, exact receipts, a real kill switch, and executable continuations. It also illustrates the remaining boundary: post-candidate review enforcement does not by itself prevent an oversized or overengineered initial candidate, and prompt-owned SDD routing is weaker than runtime authority. Kiln should study the mechanism and its disclosed limitations without copying its product model or public claims.

Current Kiln state

Kiln already has the correct architectural foundation:

• GoalRun owns objective, authority envelope, route policy, evidence requirements, lifecycle, and closeout;
• WorkItem owns scope identity, workflow/risk classification, dependencies, attempts, evidence, verification gates, pause requirements, and residual risk;
• 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;
• runtime budget admission can deny provider routes whose configured daily token ceiling is exhausted;
• context governance bounds the active working set;
• benchmark publication contracts separate measured, estimated, cached, cache-written, unknown, and avoided tokens and require quality non-inferiority.

However, repository inspection shows that the canonical work contract does not currently freeze or accumulate:

• maximum work-item attempts;
• maximum total child invocations;
• maximum concurrency or child depth per goal/work item;
• maximum review or remediation rounds;
• maximum tool calls or active duration;
• per-goal/work-item token budgets;
• candidate/correction changed-file or changed-line tripwires;
• allowed edit roots, behavioral scope, non-goals, or refactor authority as a canonical scope envelope;
• cumulative diff churn and discarded work;
• a typed reason that distinguishes scope revision from budget exhaustion and ordinary verification failure.

Relevant current boundaries include:

• packages/core/src/work-governance/goal-run.ts;
• packages/core/src/work-governance/work-item.ts;
• packages/core/src/work-governance/goal-execution.ts;
• packages/runtime/src/agents/managed-invocation/runtime-tool.ts;
• packages/runtime/src/session/runtime-budget-admission.ts;
• packages/cli/src/application/work-governance-policy.ts;
• docs/architecture/work-governance.md;
• docs/architecture/managed-agents.md;
• docs/architecture/benchmark-validation.md;
• docs/roadmap/02-managed-invocation-routing.md;
• docs/roadmap/04-cross-harness-integration.md.

Existing limits must not be conflated:

• contextGovernance.turnBudget governs context projection, not total work execution;
• provider dailyTokenCeiling governs route admission, not one goal's consumption;
• directExecution.maxFiles helps select direct versus orchestrated execution, but is not an ongoing diff ceiling;
• doneCriteria shapes a child handoff, but does not prevent the parent or subsequent children from silently expanding the objective.

Overengineering as a first-class governance concern

Overengineering must not be reduced to changed-line count. A large generated migration or documentation update may be necessary; a two-file abstraction can still be unjustified.

The contract must be able to represent and detect evidence of unnecessary expansion, including:

• behavior, surfaces, packages, or effects outside the approved objective;
• unrelated refactoring;
• new abstractions without a current consumer;
• duplicate code paths implementing the same behavior;
• compatibility paths without a documented external requirement;
• speculative infrastructure or provider/harness support;
• new dependencies not required by the approved design;
• tests coupled only to implementation details or the generated diff;
• additional reviewers, agents, or retries that produce no new required evidence;
• continued work after all required acceptance evidence already exists.

Changed files, changed lines, time, tokens, and child count should be configurable tripwires and accounting dimensions. They must not become the risk classifier or a substitute for semantic scope fidelity.

Proposed architecture direction for investigation

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

1. Scope authority

A frozen, versioned scope envelope should be able to carry:

• objective and behavioral acceptance criteria;
• permitted effects and affected surfaces;
• allowed roots/packages where applicable;
• explicit non-goals;
• approved task/work-item identities;
• permitted refactor or migration authority;
• dependency/infrastructure constraints;
• plan/spec/candidate baseline identity;
• supersession rules when the operator approves a scope revision.

Work outside the envelope must pause with scope_revision_required; it must not be silently incorporated into the current attempt.

2. Work budget

A cumulative budget should be evaluated across provider and harness boundaries and may include:

• attempts;
• total and concurrent child invocations;
• child depth;
• review and correction rounds;
• tool calls;
• active duration;
• token classes when observable;
• changed files/lines and correction size as tripwires;
• cumulative churn.

Changing provider, model, adapter, harness, session presentation, work-unit label, or retry mechanism must not reset the same goal/work-item budget.

Missing usage must remain unknown. Unknown evidence must not be normalized to zero, and providers with incomparable subscription/metered economics must remain distinct.

3. Candidate and evidence binding

For write-bearing work, the review should determine how to bind:

• baseline repository identity;
• exact candidate snapshot/diff;
• task and requirement traceability;
• verification results;
• independent review artifacts;
• correction attempts;
• final delivery receipt;
• superseded and failed candidates retained for replay.

Approval of prose or an invocation id must not establish that the final bytes satisfy the governed scope.

4. Stop and continuation policy

Runtime should produce a typed terminal or pause decision when:

• required acceptance evidence is complete;
• a budget is exhausted;
• work crosses the scope envelope;
• a new product/architecture decision is required;
• a required capability is unavailable in the active harness;
• further review or remediation would exceed the admitted contract;
• verification fails or remains inconclusive.

Every recoverable pause should expose the same machine-readable continuation across GUI, TUI, CLI, SDK, MCP, native harness projections, and replay. A provider or harness adapter must not reinterpret the decision or invent a local retry path.

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

• Core owns canonical policy and state; Runtime owns admission, accounting, transitions, and terminal truth.
• GUI, TUI, CLI, SDK, MCP, and replay only project the canonical state.
• Direct providers and native harness adapters report capabilities and evidence; they do not own budget or scope policy.
• Harness capability degradation produces a typed pause or admitted alternative route, never simulated compliance in prose.
• Provider changes do not reset attempts, budget, or scope lineage.
• No hidden retry occurs across accounts/providers after provider commitment.
• Unknown usage, missing route proof, or unsupported cancellation remains explicit.
• Parent and child authority ceilings remain narrow and replayable.
• A child cannot lend authority, scope, 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, budget, context, cancellation, timeout, replay, and benchmark contracts;
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 runtime guardrails, human approval/pause mechanisms, agent tracing, cancellation, and usage reporting across supported providers/harnesses;
4. credible empirical research on agent overreach, plan-execute-verify loops, stopping criteria, multi-agent cost/quality tradeoffs, and software-change necessity/traceability;
5. a comparative analysis of Gentle AI Organic RDD that separates implemented enforcement, prompt guidance, benchmark scope, and unsupported public inference;
6. a capability matrix for Codex direct/native, OpenCode direct/native, Claude Code native, and Kiln-owned surfaces;
7. threat modeling for budget reset, route hopping, child fan-out, fabricated evidence, stale candidate approval, and adapter-local policy drift.

Community incidents may define fixtures and hypotheses. Defaults and public claims require reproducible evidence.

Benchmark and validation requirements

Before claiming that the feature reduces tokens or overengineering, construct paired trials that freeze:

• task and repository baseline;
• provider/model and reasoning effort when measuring governance contribution;
• harness and adapter version;
• authority and tool catalog;
• context policy;
• acceptance criteria and scorer set;
• configuration and commit identities.

Record at least:

• provider token classes and unknowns;
• wall-clock duration;
• tool calls;
• total/concurrent child invocations and depth;
• review/remediation rounds;
• gross diff, accepted net diff, and discarded churn;
• files or effects outside approved scope;
• requirement-to-change traceability;
• behavior-focused verification results;
• escaped defects;
• operator interventions;
• residual risk;
• failed and omitted cases.

The report must separate model capability from Kiln governance capability and require quality/verification non-inferiority. A deterministic synthetic fixture may validate contracts but cannot support a production-efficiency claim.

Non-goals

• copying Gentle AI's workflow or terminology wholesale;
• treating a fixed LOC threshold as risk classification or proof of overengineering;
• introducing another task database, event ledger, or surface-local policy owner;
• relying on prompt instructions as the enforcement boundary;
• forcing SDD or formal verification on every task;
• hiding provider quota rotation or retry behind orchestration;
• estimating unknown provider usage as zero;
• solving unrelated cross-harness activation, account leasing, or Model Gateway lifecycle work inside this issue;
• implementing before architecture and benchmark review approve a bounded slice.

Architecture-review acceptance criteria

This issue is ready for implementation planning only when:

• Existing contract ownership and gaps are documented with repository evidence.
• The bounded context and dependency direction are approved.
• Scope, budget, candidate, stop, pause, supersession, and replay semantics are specified as typed contracts.
• Hard authority boundaries are distinguished from configurable tripwires and diagnostic metrics.
• Overengineering is defined independently from size and risk.
• Provider/harness capability and unknown-evidence behavior are specified.
• Budget reset and route-hopping invariants are threat-modelled.
• Cross-surface projections derive from one canonical state.
• Deterministic fixtures cover success, exhaustion, scope change, provider change, missing usage, cancellation, timeout, stale candidate, and unsupported harness capability.
• A paired benchmark design records quality, scope fidelity, resource use, and failed/omitted cases.
• Migration and compatibility requirements are evidence-based; obsolete paths have explicit deletion criteria.
• An independent architecture review reports no unresolved high-severity boundary or authority findings.
• A smallest viable implementation slice is proposed without absorbing Roadmaps 02 or 04.

Delivery constraints

• This issue does not authorize implementation.
• Begin with independent architecture/research review.
• Any later implementation branch must start from codex/cross-harness-gateway and target that integration branch unless the repository's active integration policy changes explicitly.
• 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.
• Do not merge as part of the initial implementation task.

[Sequela02]

Coordination-policy benchmark relationship

Issue #94 now owns the separate question of which execution topology is justified: primary-agent scouting, delegated scouting, direct/sequential execution, centralized manager-worker, or independent parallel work.

This issue remains the owner of whether an admitted scope and resource envelope changes scope fidelity and semantic overengineering. The benchmarks compose but are not interchangeable:

• [Work Governance / Research] Calibrate adaptive scouting, decomposition, and delegation policy #94 measures topology selection, coordination overhead, context/handoff loss, rework, and verifier false approvals.
• [Architecture/Research] Add native bounded-work authority for scope fidelity and overengineering control #19 measures scope fidelity, unnecessary expansion, churn, limits, tripwires, and stopping behavior under bounded authority.

The semantic overengineering rubric is being extended to distinguish acceptance-untraceable behavior or abstractions, unrelated refactoring, compatibility paths without consumers, duplicate paths, evidence-free review/retry rounds, and continued mutation after acceptance evidence is complete. LOC, file count, and elapsed time remain observations rather than the semantic verdict.