PaperlayerView exact revision on arXiv

Source-linked AI summary

From Agent Output to Authorized Transition

Christopher Koch

arXiv:2609.28216v1cs.SEcs.AI

TL;DR

Agentic engineering systems can produce artifacts and evidence, but the paper asks when that evidence justifies an engineering transition. It presents the Agile-V Assurance Spine as a cross-domain contract and reports a market gap alongside a reference implementation that demonstrates encoded contract semantics, not production superiority.

  • Problem

    Agentic systems can produce patches and test logs, but the paper asks when evidence is sufficient to justify acting on claims about an artifact.

    Source: §1 · p. 1

  • Method

    The paper proposes a transition contract that binds evidence, authority, approvals, and exceptions to an exact subject state and frozen verification baseline.

    Source: §1.1 · p. 1, §3.2 · p. 4

  • Results

    The review found no reviewed public system documenting the full cross-platform, cross-domain transition contract, while the reference implementation encodes and deterministically tests proposed semantics.

    Source: §2.9 · p. 4, §7.1 · p. 8

  • Takeaways & Limitations

    Lifecycle decisions are treated as explicit receipts, with authorization rechecked at the effect boundary before an engineering transition executes.

    Source: §8 · p. 8

    The market scan is representative and repository conformance is not production validation; the framework does not itself establish legal compliance, certification, or safety.

    Source: §8 · p. 8

Abstract

from arXiv · show

Agentic engineering systems can edit repositories, run tools and tests, build firmware, synthesize schematics, and prepare deployable or manufacturable artifacts. The assurance problem is therefore shifting from whether an agent can produce an output to whether an engineering lifecycle is justified in acting on claims about that output. Current products and standards provide sandboxes, approvals, hooks, traces, policy enforcement, attestations, bills of materials, and assurance representations, but these capabilities remain fragmented. This paper presents the Agile-V Assurance Spine, a cross-domain transition contract for software, firmware, and PCB engineering. Evidence is admitted only when it establishes required properties through an authoritative source profile, is bound to the exact artifact and frozen policy baseline, remains current with respect to declared dependencies, and satisfies risk-appropriate independence and authority. Gate decisions are recorded as receipts; approvals and exceptions are exact-scope and time-bounded; and authorization is rechecked at the effect boundary before merge, deployment, flashing, release, or fabrication. A bounded review of contemporary research, commercial platforms, open-source infrastructure, and standards positions the model relative to evidence-gated lifecycle control, continuous assurance, runtime admission, provenance, and AI/ML inventories. The paper contributes a precise vocabulary, compositional architecture, domain profiles, mapping to open-source implementations, and an adversarial evaluation agenda. It does not claim regulatory conformity or demonstrated production superiority.

1 Introduction

Agentic coding systems can execute multi-step repository work, but their outputs and checks do not by themselves authorize release. The paper proposes an evidence-gated transition contract and bounds its claims to an executable reference contribution rather than demonstrated production superiority.

1 Introduction

  • Coding agents now perform multi-step repository work, yet a generated patch, passing test log, or agent-produced review is not equivalent to an authorized release.Benchmarks and surveys also report limitations in task quality, security, reliability, and verification approaches [16] [19] [49] [50] [51] [52] [53].Source: §1 · p. 1

1.1 Contributions

  • The paper defines a property-level admission model and transition contract binding evidence, policy, approvals, exceptions, and authority to an exact subject state and frozen baseline.It also proposes risk-aligned independence and claim-scoped revalidation.Source: §1.1 · p. 1
  • The work applies one vocabulary to software, firmware, and PCB engineering and defines adversarial conformance and empirical evaluation work.Its reference contracts and execution scaffold are research artifacts at immutable repository snapshots, not certified products.Source: §1.1 · p. 2, §1.3 · p. 2

1.2 Claim boundary

  • The Assurance Spine is intended to make transition decisions explicit, falsifiable, and state-bound, not to prove universal correctness or establish compliance through schema validation.Repository tests support internal contract conformance for encoded scenarios, not production safety or cross-runtime equivalence.Source: §1.2 · p. 2

2 Landscape Review and Positioning

The paper uses a bounded review of public research, product documentation, standards, and repositories to compare systems by the layers they solve. It finds substantial execution and governance controls, but no shared transition semantics across them, while positioning Nool as complementary at the operational-state layer.

2.1 Review method

  • The review combines keyword searches and citation chaining, checks product, standards, and repository claims against public sources, and closes on 23 September 2026.It is a bounded scan, not a systematic review or an enumeration of private features and unpublished systems.Source: §2.1 · p. 2

2.2 Execution agents: strong control points, limited shared assurance semantics

  • Coding-agent platforms expose controls such as sandboxing, hooks, approvals, plan review, and audit logs, but their public documentation does not define portable semantics for which claims evidence may establish.The reviewed landscape also includes code-quality, security, review, and governance products whose documented gates remain product- or property-specific.Source: §2.2 · pp. 2–3

2.3 Semantic state, memory, and change control

  • Nool’s semantic engineering ledger overlaps with persistent intent, causal history, and impact analysis, while the Assurance Spine specifies evidence admission and transition authorization across domains.The approaches are presented as complementary: a Nool-style state kernel could supply subject history, intent, and blast-radius data.Source: §2.3 · p. 3

2.4 Observability and evaluation

The review distinguishes observable activity and infrastructure admission from evidence that authorizes an engineering transition. It positions traces, policy engines, provenance, and inventories as useful inputs whose claims remain bounded by trusted profiles and their established properties.

2.4 Observability and evaluation

  • Tracing and evaluation systems expose executions, but an authentic trace or successful tool span does not by itself establish requirement satisfaction, authority, or that the later effect matches the reviewed payload.The Spine treats traces and evaluation outputs as candidate evidence constrained by a trusted source profile.Source: §2.4 · p. 3

2.5 Policy engines and infrastructure admission

  • Kubernetes admission controllers provide deterministic policy checks at an effect boundary, while the engineering contract additionally covers requirement baselines, evidence sufficiency, independence, approvals, exceptions, and verification lineage.OPA, Gatekeeper, or Kyverno may implement specific effect-boundary checks.Source: §2.5 · p. 3

2.6 Provenance, attestations, and BOMs

  • SLSA, in-toto, Sigstore, and AI/ML inventories can establish provenance or inventory claims, but the Spine consumes these records without treating them as automatic proof of requirement satisfaction, authority, or system safety.Their admissible properties depend on the trusted profile.Source: §2.6 · p. 3

2.7 Protocols and assurance standards

Protocols and assurance standards represent interactions, controls, provenance, and arguments, but runtime transition decisions still require rules for admissible evidence. The review positions the Assurance Spine as a composition layer that unifies a cross-domain contract not found in the reviewed public systems.

2.7 Protocols and assurance standards

  • MCP, A2A, and AG-UI standardize agent interaction, while OSCAL, PROV-O, SACM, and GSN represent controls, provenance, and assurance arguments; none alone supplies runtime transition-admission rules.The standards provide useful representations, but deterministic rules are still needed to decide whether available evidence is admissible for a concrete transition.Source: §2.7 · p. 3

2.8 Closest contemporary research

  • Proof-or-Stop, DEMM, CAC, and other contemporary work already address evidence-gated control, sufficiency, admission, and continuous assurance, narrowing the Spine’s novelty to their engineering-lifecycle synthesis.The proposed synthesis combines source capabilities, exact state and policy binding, independence and authority, exceptions, dependency-scoped revalidation, AI-influence inventory, and cross-domain effect profiles.Source: §2.8 · p. 4

2.9 Market gap statement

  • The reviewed public systems did not document the listed evidence, binding, authority, revalidation, inventory, and effect-boundary requirements as one cross-platform, cross-domain contract.The Assurance Spine is proposed as a composition layer between existing capabilities, not as their replacement.Source: §2.9 · p. 4

3 The Assurance Spine Model

The Assurance Spine separates evidence presence from authorization and ties each decision to an exact artifact, frozen baseline, trusted evidence sources, and gate context. It records gate decisions and requires a final recheck at the effect boundary, under an explicit trust boundary.

3.1 Admission hierarchy

  • The admission hierarchy runs from evidence presence through completeness, property sufficiency, state-and-policy admissibility, and gate eligibility; none of these alone proves the authorized effect occurred.A positive result cannot mask a contradictory fail or error for the same claim.Source: §3.1 · p. 4

3.2 Core objects

  • The model binds a task to an exact controlled artifact and freezes requirements, acceptance criteria, risk, policy, and evidence-property profiles once verification begins.Evolve may propose future changes but cannot weaken criteria in the current cycle.Source: §3.2 · p. 4

3.3 Evidence sources cannot selfauthorize their meaning

  • Evidence cannot establish properties beyond its trusted source profile, and contradictory fail or error results prevent property sufficiency.For example, a unit-test adapter cannot establish human authority, and a BOM cannot establish requirement satisfaction merely by listing components.Source: §3.3 · pp. 4–5

3.4 Admissibility

  • Admissibility additionally requires exact subject and policy matches, integrity and attribution, freshness and dependency coverage, sufficient independence, applicable environment and intended-use bindings, and trusted profiles.Unknown or partial dependency coverage is not evidence of unchanged state; for higher-risk work, it widens revalidation.Source: §3.4 · p. 5

3.5 Gate Receipts and trusted decision context

  • A Gate Receipt records the decision and its reasons against a trusted admission context containing the accepted task, gate, subject, policy, risk, action, resources, and controls.Approval, exception, and profile resolvers must be authoritative and fail closed.Source: §3.5 · p. 5

3.6 Eligibility is not execution

  • Eligibility, execution, observed outcome, and outcome acceptability are distinct; immediately before consequential effects, the runtime rechecks subject, policy, authority, approval use, action, and resource scope.The effect record should bind the same subject and action as the Gate Receipt.Source: §3.6 · p. 5

3.7 Threat model and trust boundary

  • Candidate-controlled outputs and evidence may be incomplete, stale, replayed, contradictory, or misleading; the design relies on trusted registries, services, decision records, and an effect mediator.Unresolved mandatory claims block advancement; incorrect accepted requirements, collusion among all trusted providers, authorized-human fraud, and physical deception are out of scope.Source: §3.7 · p. 5

4 Governance Semantics

The governance semantics set independence by critical claim, keep exceptions visible, and scope evidence reuse to covered unchanged dependencies. They also inventory AI influences and prevent same-cycle changes from relaxing active verification criteria.

4.1 Risk-aligned independence

  • Risk and domain profiles set a minimum independence class for each critical claim; a second AI call does not qualify as authority-separated or organizationally independent merely because its prompt or model differs.The classes range from same-context self-check through context-, role-, authority-, and organizational separation.Source: §4.1 · pp. 5–6

4.2 Exceptions remain visible

  • Waivers, concessions, dispensations, residual-risk acceptance, and deferrals represent different decisions; unresolved mandatory items need current, authenticated, applicable exceptions, and gate output remains WAIVED rather than PASS.Identity, receipt integrity, subject binding, and gate integrity are non-waivable metacontrols.Source: §4.2 · p. 6

4.3 Change-aware revalidation

  • Evidence reuse is permitted only for unchanged dependencies with complete coverage; changes can trigger targeted revalidation, while incomplete coverage conservatively widens affected scope.For example, a compiler change may invalidate firmware build and HIL evidence without invalidating a requirements approval.Source: §4.3 · p. 6

4.4 AI-influence inventory

  • An AI Run Manifest or Agent Run BOM links auditable metadata about models, runtimes, tools, retrieval, sandboxes, evaluation, and influenced artifacts to the evidence bundle.Its function extends interoperable inventory foundations by connecting inventory changes to affected claims and revalidation scope.Source: §4.4 · p. 6

4.5 Governance conversion without same-cycle goalpost changes

  • Controls may arise from prior obligations and risk or from incidents and verifier findings, but active criteria cannot change after a failed Prove step in the same cycle.Learning during Evolve is encouraged; same-cycle relaxation would turn a current failure into a weakened rule.Source: §4.5 · p. 6

5 Compositional Architecture

The Assurance Spine composes existing engineering capabilities into a control plane for transition decisions. It connects evidence admission and revalidation with receipts, effect authorization, interoperability, and an open-source reference implementation.

5 Compositional Architecture

  • The Assurance Spine coordinates baseline freezing, evidence admission, revalidation, gate receipts, and effect authorization across existing execution, observability, policy, and provenance capabilities.Its effects include merge, deploy, flash, and fabricate.Source: §5 · p. 6

5.1 Interoperability mapping

  • The Spine composes agent, observability, policy, provenance, inventory, protocol, and assurance systems to determine whether their records count for a claim and transition now [20].It is positioned as a composition layer, not a replacement product.Source: §5.1 · p. 6

5.2 Repository realization

  • Open-source repositories divide the reference implementation between contract semantics in agile_v_skills and execution infrastructure in agentic_agile_v.At the reviewed snapshots, the admission contract is more advanced than the execution repository; faithful runtime porting and effect-boundary adapters remain priorities.Source: §5.2 · p. 7

6 Software, Firmware, and PCB Profiles

The same transition contract applies across software, firmware, and PCB engineering, while evidence and effect profiles vary by domain. Cross-domain co-verification binds linked claims to their relevant states and revalidates them when dependencies change.

6.1 Software

  • Software profiles bind source, build, deployment, tests, scans, provenance, policy, environment, approval scope, and rollback plans to release effects.Agent hooks can collect or block on evidence, but authorization should rely on aggregate admission rather than passing tests alone [49] [50] [51] [52] [53].Source: §6.1 · p. 7

6.2 Firmware

  • Firmware profiles bind board revision, toolchain, configuration, binary, and device class to tests, simulation, HIL evidence, signing, release, flashing, or updates.A successful build can still target the wrong board revision, bus mapping, interrupt polarity, ADC scaling, or memory partition.Source: §6.2 · p. 7

6.3 PCB engineering

  • PCB profiles bind the circuit and manufacturing package to schema checks, ERC/DRC, electrical review, power and thermal analysis, provenance, and fabrication authority.The Spine treats ERC or semantic review as typed evidence; fabrication waits for admission and required engineering authorization, extending pcbGPT’s reviewable-draft workflow [54].Source: §6.3 · p. 7

6.4 Cross-domain co-verification

  • A cross-domain requirement can link a PCB net and component through board contract, firmware driver, software API, and system or HIL evidence.A change invalidates dependent claims, while unknown dependency coverage widens verification.Source: §6.4 · p. 7

6.5 Illustrative vertical slice: adding an I2C sensor

  • In the illustrative sensor example, separate Gate Receipts authorize fabrication, firmware release, and software deployment; one receipt cannot authorize another effect.A board interrupt-pin change makes dependent firmware pin-map and HIL claims stale, while an unchanged API contract may remain eligible; incomplete dependency coverage widens scope conservatively.Source: §6.5 · pp. 7–8

7 Evaluation Plan

The paper demonstrates that its proposed semantics can be encoded and deterministically tested, then outlines adversarial benchmarks, measures, and staged empirical work. It does not report live product conformance or production defect reductions.

7.1 What is already demonstrated

  • Schemas, semantic predicates, aggregate admission functions, golden and negative journeys, and contract tests demonstrate that the proposed semantics can be encoded and deterministically tested.This does not demonstrate live conformance in named agent products or lower production defect rates.Source: §7.1 · p. 8

7.2 Adversarial admission benchmark

  • The proposed benchmark compares aggregate admission with weaker baselines, using adversarial cases such as wrong-artifact evidence, stale baselines, replayed approvals, false authority, and effect races.Complementary failure models and benchmark patterns include Proof-or-Stop, DEMM-Bench, CAC, AgentDojo, ToolEmu, AgentSecBench, and SWE-Bench Pro Verified [2] [4] [13] [49] [50] [51] [52] [53].Source: §7.2 · p. 8

7.3 Measures

  • Evaluation measures include false acceptance and rejection, stale-evidence detection, claim-scoped revalidation, unsupported-claim detection, cost, latency, reviewer effort, cross-runtime agreement, and exact-effect integrity.Exact-effect integrity asks whether the reviewed digest is the one merged, deployed, flashed, or fabricated.Source: §7.3 · p. 8

7.4 Empirical program

  • The empirical program progresses from reference and cross-runtime conformance to domain vertical slices and a field study comparing delivery outcomes and reviewer effort.Its testable proposition is that property-aware, state-bound admission reduces specific false-authority and stale-evidence failures at acceptable cost, not that more gates always improve delivery.Source: §7.4 · p. 8

8 Threats, Limitations, and Conclusion

The paper’s comparison identifies a gap in composing existing engineering records into a defensible transition decision. The Assurance Spine addresses that gap with an exact-state, authority-bound contract, while production value remains to be tested.

8 Threats, Limitations, and Conclusion

  • The bounded comparison argues that the ecosystem has sandboxes, hooks, traces, policy engines, attestations, inventories, and assurance representations, but lacks a widely shared contract to compose them for operational decisions.The market scan is representative and based on public sources; private product capabilities may exceed their documentation.Source: §8 · p. 8
  • The Spine treats outputs as claims, evidence sources as capability-bounded producers, baselines as frozen state, changes as revalidation triggers, and approvals as exact-scope authority records.Lifecycle decisions become explicit receipts, with authorization rechecked where the consequential effect occurs.Source: §8 · pp. 8–9
  • The contract is narrower than general AI safety and broader than a coding-agent hook; its value depends on future studies showing useful detection without impractically slow delivery.The framework does not itself establish legal compliance, certification, or safety.Source: §8 · pp. 8–9

Generative AI Disclosure

OpenAI ChatGPT assisted with research and manuscript preparation, while the author retains full responsibility for the final manuscript, including verification of claims and citations.

Generative AI Disclosure

Related papers

Loading 2609.28216v1…