Paper deep dive
From Agent Output to Authorized Transition
Christopher Koch
Intelligence
Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 90%
Last extracted: 9/26/2026, 3:38:13 AM
Summary
The paper introduces the Agile-V Assurance Spine, a cross-domain transition contract for software, firmware, and PCB engineering that shifts assurance from agent output generation to authorized lifecycle transitions. It proposes a property-level evidence-admission model where evidence is admitted only if it establishes required properties through authoritative sources, is bound to exact artifacts and frozen policy baselines, and satisfies risk-appropriate independence. The system uses gate receipts and rechecks authorization at effect boundaries before deployment or fabrication, addressing fragmentation in current tools like coding agents, policy engines, and provenance standards.
Entities (46)
Relation Signals (52)
Agile-V Assurance Spine → addresses → Evidence Admission
confidence 95% · Evidence is admitted only when it establishes required properties through an authoritative source profile
Agile-V Assurance Spine → defines → Transition Contract
confidence 95% · This paper presents the Agile-V Assurance Spine, a cross-domain transition contract for software, firmware, and PCB engineering.
Agile-V Assurance Spine → uses → Gate Receipt
confidence 95% · A Gate Receipt records why a transition was allowed, denied, waived, marked stale, or escalated.
Agile-V Assurance Spine → uses → SCOPE-V
confidence 92% · This paper uses the SCOPE-V lifecycle - Specify, Constrain, Orchestrate, Prove, Evolve, Verify - as its immediate process substrate
SonarQube AI Code Assurance → applies → quality gates
confidence 90% · SonarQube AI Code Assurance marks AI-bearing projects and applies AI-qualified quality gates for security, reliability, coverage, hotspot review, and duplication
Nool → centerson → semantic DAG
confidence 90% · Its public architecture centers on a semantic DAG binding intent, code, attribution, policy validation, causal lineage, evidence, and semantic blast radius
Claude Code → combines → sandboxing
confidence 90% · Claude Code combines read-only defaults or classifier-mediated autonomy with sandboxing, working-directory boundaries, managed permissions, cloud isolation, audit logging, and hooks
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract: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.
Tags
Links
- Source: https://arxiv.org/abs/2609.28216v1
- Canonical: https://arxiv.org/abs/2609.28216v1
Trouble viewing inline? Open PDF directly →
Full Text
51,943 characters extracted from source content.
Expand or collapse full text
From Agent Output to Authorized Transition The Agile-V Assurance Spine for State-Bound Evidence in Software, Firmware, and Hardware Engineering Christopher Koch Keywords: agentic software engineering, assurance, evidence admission, Agile-V, SCOPE-V, lifecycle gates, continuous verification, software supply chain, AI-BOM, firmware, PCB engineering Abstract 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 Coding agents are becoming execution systems rather than suggestion systems. OpenHands, Codex, Claude Code, GitHub Copilot, Cursor, Windsurf, Jules, Devin, Cline, Aider, and related tools can perform multi-step repository work with varying combinations of sandboxing, human approval, lifecycle hooks, plan review, automated tests, session history, and pull-request integration [20, 21, 22, 23, 24, 25, 26, 27, 28, 29]. This is a material engineering change, but it does not make a generated patch, a passing test log, or an agent-produced review equivalent to an authorized release. Recent research sharpens the problem. Software-agent benchmarks increasingly reveal task-quality, leakage, reward-hacking, security, and long-horizon reliability limitations [49, 50, 51, 52, 53]. A 2026 synthesis characterizes the resulting bottleneck as the difference between code production and production-qualified change, where review, integration, testing, security, deployment, and operational evidence remain constraining stages [19]. A systematic survey of specification, verification, and enforcement finds the field fragmented and reports that no reviewed approach simultaneously provides soundness, scalability, semantic correctness, and task-level safety preservation [16]. Several independent research lines now converge on the need for evidence-gated, state-aware engineering control [2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19]. This paper uses the SCOPE-V lifecycle - Specify, Constrain, Orchestrate, Prove, Evolve, Verify - as its immediate process substrate [1], but grounds the proposed assurance contract primarily in external research, standards, and current market systems. The remaining question is more precise: When is evidence allowed to count toward an engineering transition, and when may that transition actually execute? A file can be present but malformed. A schema-valid result can be irrelevant. A relevant result can be stale. A correct test can be bound to the wrong commit. A signed approval can authorize an earlier policy or artifact. A fresh verifier context can reduce confirmation bias without providing organizational independence. A runtime hook can block an operation without explaining which engineering claim was established. A trace can show what happened without proving that the outcome was acceptable. An SBOM or AI/ML-BOM can inventory components without authorizing use of the assembled system. 1.1 Contributions This paper makes five contributions. 1. A market- and literature-grounded gap analysis. It compares the Assurance Spine against major coding-agent platforms, semantic change-control products, observability stacks, policy engines, provenance and attestation systems, AI/ML-BOM standards, agent protocols, assurance-case standards, and the closest contemporary research. 2. A property-level evidence-admission model. It separates presence, structural completeness, sufficiency, admissibility, gate eligibility, and transition authorization. 3. A trusted transition contract. It binds evidence, policy, approvals, exceptions, and authority to an exact subject state and frozen verification baseline, with risk-aligned independence and claim-scoped revalidation. 4. A compositional architecture. It shows how existing tools - rather than being replaced - can supply execution, traces, policies, attestations, inventories, and protocol messages to the Assurance Spine. 5. Cross-domain profiles and an evaluation agenda. It applies one vocabulary to software, firmware, and PCB engineering and defines adversarial conformance and empirical evaluation work. 1.2 Claim boundary The Assurance Spine does not prove universal software correctness, eliminate trust bootstrap, make an AI reviewer organizationally independent, or establish compliance merely because schemas validate. It is a design and executable-reference contribution intended to make transition decisions explicit, falsifiable, and state-bound. Current repository tests support internal contract conformance for encoded scenarios; they are not evidence of production safety or cross-runtime equivalence. 1.3 Artifact availability The reference contracts and execution scaffold are available in the public agile\_v\_skills and agentic\_agile\_v repositories at the immutable snapshots identified in [55]. The repositories are research artifacts, not certified products, and the paper distinguishes repository-level conformance from live runtime validation. 2 Landscape Review and Positioning 2.1 Review method The comparison is a bounded market and research scan, not a systematic review or a claim to have enumerated every private feature or unpublished system. The scan combined keyword searches for agentic software engineering, evidence admission, continuous assurance, runtime governance, agent security, software provenance, AI/ML bills of materials, firmware verification, and PCB synthesis with backward and forward citation chaining from the closest research [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 49, 50, 51, 52, 53, 54]. Product claims were checked against vendor documentation, standards against official specifications, and repository claims against public source snapshots. Inclusion required direct relevance to transition control or candidate evidence. The review closed on 23 September 2026. The reviewed landscape includes: • ten representative coding-agent and agent-development platforms [20, 21, 22, 23, 24, 25, 26, 27, 28]; • six representative AI-code quality, security, review, and governance products [56, 57, 58, 59, 60, 61]; • semantic change-control and operational-memory infrastructure [29]; • agent observability and evaluation systems [30, 31, 32]; • policy/admission and software-supply-chain mechanisms [33, 34, 35, 36]; • AI/ML inventory standards and runtime collectors [37, 38, 39]; • interoperability protocols [40, 41, 42]; • control, provenance, and assurance-case standards [43, 44, 45, 46]; • security/governance frameworks and regulation [47, 48]; and • the closest scholarly work on evidence sufficiency, lifecycle gating, runtime admission, continuous assurance, and agent security [2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 49, 50, 51, 52, 53, 54]. The comparison asks which layer each system primarily solves and whether its public specification defines the full transition relation proposed here. 2.2 Execution agents: strong control points, limited shared assurance semantics Current coding-agent products already expose important enforcement surfaces. • OpenHands supports repository hooks that can block tool use, deny completion, require tests or linting, and log activity [20]. • Codex documents sandboxing, permission profiles, approvals, hooks, auto-review, and controlled internet access [21]. • Claude Code combines read-only defaults or classifier-mediated autonomy with sandboxing, working-directory boundaries, managed permissions, cloud isolation, audit logging, and hooks [22]. • GitHub Copilot provides repository hooks that can approve or deny tool execution, invoke secret scanning, enforce validation rules, and create audit logs [23]. • Cursor and Windsurf expose lifecycle hooks around tools, commands, file access, prompts, and stop events [24, 25]. • Jules provides explicit plan review and approval before implementation [26]. • Devin provides isolated sessions, parallel work, reusable playbooks, knowledge, schedules, and event timelines [27]. • Cline exposes per-tool and conditional approval policies [28], while Aider tightly couples edits to Git history and attribution. These are valuable implementation mechanisms. Their public documentation mainly defines how to execute, constrain, observe, or approve agent actions, not a portable engineering semantics for which claims a given test, trace, review, or attestation is allowed to establish. The Assurance Spine can use these products as execution backends while keeping the evidence and gate contract outside any one vendor. The quality and governance market increasingly adds controls around those agents. GitLab AI Governance records agent sessions and audit events and enforces Allow, Ask, and Deny tool policies across GitLab Duo and external agents connected through GitLab MCP [56]. SonarQube AI Code Assurance marks AI-bearing projects and applies AI-qualified quality gates for security, reliability, coverage, hotspot review, and duplication [57]. Qodo combines agentic pull-request review with organizational rule and compliance checks [58]. Semgrep Guardian integrates MCP, hooks, and skills to scan every file write and block vulnerable patterns, secrets, and malicious dependencies [59]. Snyk Studio exposes security analysis to coding agents through MCP and records agentic scan usage [60], while Tabnine Agent supports autonomous development work, approval checkpoints, policy validation, and enterprise-controlled context [61]. These products materially strengthen code-quality, security, and tool-governance enforcement. Their documented gates are nevertheless product- or property-specific; they do not expose a shared contract that determines which source may establish which property, binds that evidence to a frozen cross-domain baseline, and authorizes merge, deployment, flashing, or fabrication under one transition model. 2.3 Semantic state, memory, and change control Nool is the closest market comparator at the operational-state layer. Its public architecture centers on a semantic DAG binding intent, code, attribution, policy validation, causal lineage, evidence, and semantic blast radius, with Git interoperability and WASM-based gates [29]. It also treats intent, impact, findings, and evidence as durable repository memory with scope, supersession, and time-aware retrieval. This directly overlaps with Agile-V’s need for persistent intent, causal history, and impact analysis. The distinction is one of emphasis and specification scope. Nool’s public material presents a semantic engineering ledger and fleet/change-control product. The Assurance Spine specifies a domain-general evidence-admission and transition-authorization relation, including authoritative evidence-source capability profiles, risk-based independence classes, exact approval and exception semantics, revalidation dependencies, AI-influence inventory, and profiles for firmware and PCB effects. The two approaches are complementary; a Nool-style state kernel could supply subject history, intent, and blast-radius data to the Spine. 2.4 Observability and evaluation LangSmith, Phoenix, and OpenTelemetry-based tooling provide traces, spans, sessions, datasets, annotations, online evaluations, and production metrics [30, 31, 32]. These systems are essential because an assurance process cannot evaluate invisible execution. However, observation is not admission. A trace can be authentic and still fail to establish a required claim. An evaluator score can be useful but model-dependent. A successful tool span does not prove that the current requirement baseline was satisfied, that the caller possessed the needed authority, or that a later effect matched the reviewed payload. The Assurance Spine treats traces and evaluation outputs as candidate evidence whose admissible properties are constrained by a trusted source profile. 2.5 Policy engines and infrastructure admission OPA/Gatekeeper and related Kubernetes policy engines demonstrate mature, deterministic admission patterns: evaluate an incoming object against policy at a specific boundary, then allow, deny, warn, mutate, or audit [33]. Kyverno and Sigstore-based admission extend this with image verification and attestations. These systems validate the importance of fail-closed enforcement at the effect boundary. Their scope is narrower than the proposed engineering contract. A Kubernetes admission controller can determine whether a resource satisfies cluster policy, but it does not normally reconstruct a software task’s requirement baseline, property-level evidence sufficiency, verifier independence, human approval scope, exception coverage, or firmware/PCB verification lineage. The Assurance Spine generalizes the admission concept while allowing OPA, Gatekeeper, or Kyverno to implement specific effect-boundary checks. 2.6 Provenance, attestations, and BOMs SLSA provenance records how a software artifact was produced, including the subject, builder, build definition, parameters, and dependencies [34]. in-toto provides a framework for verifiable claims about software-supply-chain steps [35], and Sigstore/GitHub attestations provide signed provenance and transparency mechanisms [36]. These are strong sources for artifact identity, integrity, and production provenance. CycloneDX ML-BOM and SPDX AI profiles extend inventory toward models, datasets, frameworks, configurations, and provenance [37, 38]. k8s-aibom generates runtime CycloneDX ML-BOMs for inference services, agent stacks, RAG infrastructure, training jobs, and evaluation harnesses, distinguishing declared, inferred, and unresolved attributes and attaching evidence locators [39]. The Assurance Spine does not replace any of them. It consumes them. A signed SLSA attestation may establish build provenance; an in-toto statement may establish a supply-chain step; an ML-BOM may establish an observed model/runtime inventory. None should automatically be treated as proof of requirement satisfaction, human authority, or system safety beyond the properties its trusted profile permits. 2.7 Protocols and assurance standards MCP standardizes resources, prompts, tools, tasks, and communication between hosts, clients, and servers, while explicitly leaving robust authorization and many security controls to implementers [40]. A2A standardizes inter-agent tasks, messages, artifacts, status, and security metadata [41]. AG-UI standardizes agent-user interaction events [42]. These protocols make execution interoperable; they do not, by themselves, define which evidence is sufficient to authorize a lifecycle or physical-world transition. OSCAL provides machine-readable security controls and assessment artifacts [43]. W3C PROV-O models entities, activities, and agents [44]. SACM and GSN structure assurance arguments and evidence [45, 46]. These standards supply useful representations, but an operational runtime still needs deterministic rules that decide whether the evidence currently available is admissible for a concrete transition. 2.8 Closest contemporary research The research landscape has moved rapidly toward the same boundary. • Proof-or-Stop treats lifecycle states as claims until current, tracked-state-bound evidence permits transition and reports adversarial receipt-tampering results [2]. • DEMM and DEMM-Bench formalize property-level evidence sufficiency and show why trace-, schema-, or ledger-presence baselines can overclaim [3, 4]. • Cognitive Admission Control (CAC) is the closest admission-calculus comparator. It maps typed actions and risk to predicates, evidence classes, scope, freshness, and witness constraints; successful admission yields a certificate and dispatch guards [13]. • Agent-Integrated Software and Intent-Level Interaction Abstraction bind effects to task revision, referenced objects, role authority, controller identity, and outcome evidence, and separate admission from occurrence [14]. • TAIP frames continuous AI assurance as reusable assurance objects and claim/evidence posture across organizational levels [15]. • AI-GRACE maps organizational objectives and obligations through risk, assurance, controls, evidence, capabilities, and architecture [5]. • Runtime Governance: Policies on Paths treats the partial execution path and proposed next action as central policy inputs [17]. • Verifiable Manifest Signing for MCP binds tool-use manifests to freshness, policy, signatures, fail-closed verification, and transparency logs [18]. • Safe-agent surveys and security benchmarks expose the limits of prompt-only controls, specification translation, and local test success [16, 49, 50, 51, 52, 53]. These works narrow the novelty claim. The Assurance Spine is not the first proposal for evidence-gated control, continuous assurance, admission certificates, state binding, or policy-mediated runtime actions. Its proposed contribution is their engineering-lifecycle synthesis: a portable transition contract that combines property-level evidence admission, trusted source capabilities, exact state and policy binding, independence and authenticated authority, explicit exceptions, dependency-scoped revalidation, AI-influence inventory, and cross-domain effect profiles in one open reference model. 2.9 Market gap statement Based on the reviewed public documentation and literature, the market contains strong components for nearly every part of the problem. We did not find a reviewed public system that documents all of the following as one cross-platform, cross-domain contract: ⬇ required claim properties + authoritative source capability profiles + exact subject and policy binding + contradiction-aware admission + risk-aligned independence / authority + explicit exception semantics + dependency-scoped evidence revalidation + model/runtime/tool influence inventory + atomic recheck at the effect boundary The Assurance Spine is intended as the composition layer between those capabilities, not as a replacement product for them. 3 The Assurance Spine Model 3.1 Admission hierarchy The fundamental hierarchy is: ⬇ present -> structurally complete -> sufficient for the required properties -> admissible for state + policy -> eligible for this gate -> effect-authorized Only the forward direction is safe. Presence does not imply completeness; completeness does not imply sufficiency; sufficiency does not imply current admissibility; admissibility of one item does not imply gate eligibility; and eligibility does not prove that the authorized effect actually occurred. 3.2 Core objects For task τ, define an exact subject state: σ=(kind,ref,digest)σ=(kind,ref,digest) The subject can be a Git commit, firmware image, PCB manufacturing package, document revision, dataset, container image, or other controlled artifact. A frozen verification baseline is: B=(R,C,ρ,π,P)B=(R,C,ρ,π,P) where R is the requirement baseline, C the acceptance criteria, ρ the risk state, π the policy/control digest, and P the applicable evidence-property profiles. Once Prove begins, the active baseline is frozen; Evolve may propose future changes but cannot weaken the criteria being verified in the current cycle. A claim c has a required property set Req(c)Req(c). An evidence item e declares: ⬇ supports(e) claims it addresses result(e) pass | fail | error | unknown properties(e) properties it claims source(e) adapter ID + profile digest state(e) subject binding policy(e) policy binding integrity(e) digest / signature or attestation independence(e) achieved independence class invalidators(e) source / requirement / policy / environment / tool / model / hardware 3.3 Evidence sources cannot self-authorize their meaning Let Cap(a)Cap(a) be the independently resolved capability profile for evidence adapter a. For a passing evidence item: TrustedProps(e)=properties(e)∩Cap(source(e))TrustedProps(e)=properties(e)∩ Cap(source(e)) In the strict runtime contract, an item that claims a property outside the source profile is rejected rather than silently upgraded or trusted. This blocks a common category error: a unit-test adapter cannot establish human\_authority; a static analyzer cannot establish intended\_use\_validated; an LLM review cannot establish organizational\_independence; a BOM cannot establish requirement\_satisfied merely by listing components. For mandatory claim c, evidence is property-sufficient only when: Req(c)⊆⋃e:c∈supports(e),result(e)=passTrustedProps(e)Req(c) _e:\,c∈ supports(e),\ result(e)=passTrustedProps(e) and no supporting evidence reports a contradictory fail or error. This avoids the any-pass anti-pattern, where one positive result masks a negative result for the same claim. 3.4 Admissibility Property sufficiency is necessary but not enough. A claim is admissible only if its supporting evidence also satisfies: 1. exact subject type, reference, and digest match; 2. exact frozen policy digest match; 3. integrity and producer attribution requirements; 4. freshness and dependency-coverage requirements; 5. required independence floor; 6. applicable environment and intended-use bindings; and 7. trusted-resolution rules for source and property profiles. Unknown or partial dependency coverage is not evidence of unchanged state. For higher-risk work, incomplete coverage widens revalidation rather than silently permitting reuse. 3.5 Gate Receipts and trusted decision context A Gate Receipt records why a transition was allowed, denied, waived, marked stale, or escalated. It binds: ⬇ task and gate exact subject state requirement baseline policy digest risk level required / admitted / rejected / stale claims open obligations verifier independence approval references exception references decision and reason codes The receipt is evaluated against a Trusted Admission Context supplied outside candidate write authority. This context contains the accepted task, gate, subject, policy, risk, action, resources, critical risks, and non-waivable controls. Resolvers for approvals, exceptions, source profiles, and property profiles must be authoritative and fail closed. Eligibility can be summarized as: Eligible(g)=Ca∧Is∧Av∧Rd∧XvEligible(g)=C_a I_s A_v R_d X_v where the terms denote claims admitted, independence sufficient, authority valid, risks dispositioned, and exceptions valid. 3.6 Eligibility is not execution The runtime must distinguish: ⬇ eligible to execute executed outcome observed outcome acceptable An approval can be authentic yet stale. A dispatch can be admitted but fail before the external effect. A timeout can leave outcome unknown. Therefore, immediately before merge, deployment, flashing, fabrication submission, or other consequential effect, the runtime should atomically recheck: ⬇ subject digest policy digest authority and revocation state single-use approval consumption action and resource scope dispatch guard The resulting effect record should bind the same subject and action as the Gate Receipt. This aligns the Assurance Spine with CAC’s dispatch guards [13] and interaction-effect obligations in Agent-Integrated Software [14]. 3.7 Threat model and trust boundary The candidate-controlled surface includes agent outputs, evidence claims, adapter assertions, task-local policy references, and references to approvals or exceptions. The design assumes that these inputs may be incomplete, stale, replayed, contradictory, or intentionally misleading. The trusted computing base consists of versioned source/property-profile registries, digest and clock services, authenticated authority providers, append-only decision records, and the effect mediator that performs the final atomic recheck. The principal security goals are: no source self-elevation, no state or policy replay, no hidden waiver, no approval reuse outside scope, and no effect substitution after review. Unresolved mandatory claims block advancement. Out of scope are incorrect requirements accepted into the baseline, compromise or collusion of all trusted providers, fraudulent decisions by an otherwise authorized human, and physical deception that is outside the modeled evidence sources. Those cases require additional organizational, cryptographic, or domain controls rather than stronger agent prompting. 4 Governance Semantics 4.1 Risk-aligned independence The Spine distinguishes five assurance classes: • I0 - self-check: same agent and context; useful sanity check, not independence. • I1 - context-separated: fresh context; reduces memory and confirmation bias. • I2 - role-separated: separate verifier role with protected requirement/test inputs. • I3 - authority-separated: authenticated principal who cannot modify the evaluated artifact, policy, or criteria. • I4 - organizationally independent: separate qualified human, team, or entity where a governing profile requires it. A second AI call does not become I3 or I4 merely by using a different prompt or model. Risk and domain profiles set the minimum independence for each critical claim, not once for the whole task. 4.2 Exceptions remain visible Waiver, concession, dispensation, residual-risk acceptance, and defer are different decisions: • a waiver suspends a criterion for bounded scope and time; • a concession accepts a known nonconformity for a specific case; • a dispensation changes an obligation’s timing, not its substance; • residual-risk acceptance accepts consequence, not failed verification as truth; and • defer leaves work unresolved and does not authorize advancement. Every unresolved mandatory item must be covered by an applicable, current, authenticated exception. Gate output is WAIVED, not PASS. Identity, receipt integrity, subject binding, and gate integrity are non-waivable meta-controls. 4.3 Change-aware revalidation Evidence depends on more than source code. Each item can declare invalidation dependencies of type: ⬇ source | requirement | policy | environment | tool | model | dataset | hardware | authority A change assessment yields UNCHANGED, REVALIDATION\_REQUIRED, STALE, or UNKNOWN. Only unchanged dependencies with complete coverage permit evidence reuse. This supports targeted revalidation: a compiler change may invalidate firmware build and HIL evidence without invalidating a requirements approval; a PCB revision may invalidate firmware pin-map tests; a model/runtime change may invalidate AI-assisted review evidence but not a cryptographically verified build attestation. 4.4 AI-influence inventory SBOMs describe software components; AI-assisted engineering also depends on models, model deployments, agent runtimes, skills, tools, retrieval sources, sandboxes, evaluators, and external APIs. The Spine therefore links an AI Run Manifest / Agent Run BOM to the evidence bundle. It records auditable metadata, not hidden chain-of-thought: ⬇ model and provider identity runtime and deployment version loaded skills and policies tool and MCP server versions retrieval / dataset references sandbox or container identity evaluation configuration influenced artifacts confidence: declared | inferred | verified | unresolved evidence locator and digest CycloneDX ML-BOM, SPDX AI, and k8s-aibom provide interoperable inventory foundations [37, 38, 39]. The additional Agile-V function is to connect inventory changes to affected claims and revalidation scope. 4.5 Governance conversion without same-cycle goalpost changes Controls can originate ex ante from organizational obligations, architecture, and known risk [5, 10, 17], or ex post from incidents, verifier findings, and recurring agent failure patterns [11]. Both enter the same governed process: ⬇ observation or obligation -> proposed control -> authority review -> held-out validation -> versioned activation -> future baseline Learning during Evolve is encouraged. Changing the active criteria after a failed Prove step is not. This prevents an agent or team from converting a current failure into a same-cycle rule relaxation. 5 Compositional Architecture The Assurance Spine is a control plane over existing capabilities: ⬇ Human / organizational authority | Requirements, risk, policy, evidence profiles | Agile-V Assurance Spine - baseline freeze - evidence admission - revalidation - gate receipt - effect authorization | +-------+---------+-----------+-----------+ | | | | Execution Observability Policy agents and evals engines Provenance / assurance | Effects: merge | deploy | flash | fabricate | release 5.1 Interoperability mapping • OpenHands, Codex, Claude Code, Copilot, Cursor, Windsurf, Jules, Devin, and Cline execute work and expose approval/hook boundaries [20, 21, 22, 23, 24, 25, 26, 27, 28]. • Nool can supply durable intent, impact, lineage, memory, and semantic change state [29]. • LangSmith, Phoenix, and OpenTelemetry supply traces, evaluations, sessions, and metrics [30, 31, 32]. • OPA/Gatekeeper, Kyverno, and policy-as-code systems enforce deterministic controls at selected boundaries [8, 10, 17, 33]. • SLSA, in-toto, Sigstore, and GitHub attestations supply artifact and process provenance [34, 35, 36]. • CycloneDX, SPDX, and k8s-aibom supply software and AI/ML inventories [37, 38, 39]. • MCP, A2A, and AG-UI transport tools, tasks, artifacts, agent messages, and user interaction events [40, 41, 42]. • OSCAL, PROV-O, SACM, and GSN can encode controls, provenance, claims, argument structures, and evidence references [43, 44, 45, 46]. The Spine’s distinct role is to answer: may these records count, for this claim, now, for this exact transition? 5.2 Repository realization The current open-source Agile-V repositories divide the reference implementation between contract semantics and execution infrastructure. agile\_v\_skills contains Evidence Bundle v2, source/property profiles, Gate Receipts, Approval v2, independence classes, exceptions, revalidation, risk floors, governance conversion, Trusted Admission Context, AI-influence manifests, and aggregate admission evaluators; agentic\_agile\_v provides task briefs, evidence workflows, OpenHands hooks, graph/impact infrastructure, OpenWiki integration, and PCB development components [55]. At the snapshots reviewed for this paper, the skills repository contains a more advanced admission contract than the execution repository. The next implementation priority is therefore not another prompt layer: it is faithful porting of the aggregate evaluators and trusted-provider boundaries into the runtime, followed by effect-boundary adapters and cross-runtime conformance tests. 6 Software, Firmware, and PCB Profiles The same core contract applies across domains; the evidence and effect profiles differ. 6.1 Software Subject: source commit, build artifact, container image, deployment manifest. Evidence: tests, static analysis, security scans, review, build provenance, runtime checks. Effect: merge, package publication, deployment, migration. Critical bindings: commit/build digest, requirement baseline, policy, environment, approval scope, rollback plan. Coding-agent hooks can collect and block on evidence, but release authorization should depend on aggregate admission rather than tests passed alone. SWE-Bench Pro Verified, AgentDojo, ToolEmu, AgentSecBench, and CIBER offer useful capability and adversarial scenarios, yet production admission also needs organization-specific requirements and authority [49, 50, 51, 52, 53]. 6.2 Firmware Subject: source state, board revision, toolchain/SDK, configuration, linked binary, signed image. Evidence: host tests, cross-build, static analysis, simulation, timing traces, hardware-in-the-loop tests, boot/update/rollback evidence. Effect: image signing, release, device flashing, over-the-air update. Critical bindings: hardware-firmware contract, pin/peripheral map, memory layout, compiler flags, binary digest, device class, HIL rig identity. Firmware shows why a successful build is insufficient: code can compile against the wrong board revision, bus mapping, interrupt polarity, ADC scaling, or memory partition. 6.3 PCB engineering Subject: Circuit IR, KiCad schematic/board revision, component set, manufacturing package digest. Evidence: schema checks, ERC/DRC, semantic electrical review, power/thermal analysis, footprint and component provenance, fabrication outputs, independent E review. Effect: design release, purchase, fabrication submission, assembly release. Critical bindings: netlist, BOM, datasheets, footprints, stack-up, Gerber/drill archive, risk class, manufacturing approval. pcbGPT demonstrates the value of a structured intermediate representation, component/datasheet grounding, deterministic execution checks, semantic validation, and generate-execute-repair loops for reviewable KiCad drafts [54]. The Assurance Spine adds transition semantics: ERC or an LLM semantic review becomes typed evidence, while fabrication remains blocked until the exact manufacturing package is admitted and authorized by the required engineering authority. 6.4 Cross-domain co-verification For embedded products, a single requirement can span all three domains: ⬇ requirement -> PCB net / component -> board contract / pin map -> firmware driver and configuration -> protocol/API exposed to software -> system test / HIL evidence A change to any linked state should invalidate only the claims that depend on it, but unknown coverage must widen verification. This is the practical value of one Assurance Spine across domains. 6.5 Illustrative vertical slice: adding an I2C sensor Consider a requirement to add a temperature sensor to an embedded product and expose readings through a software API. This example is illustrative rather than empirical. 1. The PCB profile binds the selected component, address, supply rail, pull-ups, interrupt net, footprint, and manufacturing package to a board-revision digest. ERC/DRC, component provenance, and an independent electrical review establish only the properties permitted by their source profiles. 2. The firmware profile imports the approved pin and bus contract, builds a driver against the exact board revision, and binds tests, simulation, HIL logs, and the signed image to the binary digest and toolchain state. 3. The software profile binds the API schema, serialization behavior, integration tests, and deployment artifact to the corresponding firmware protocol revision. 4. Separate Gate Receipts authorize fabrication, firmware release, and software deployment. A receipt for one effect cannot authorize another. 5. If the board revision changes the interrupt pin, only evidence depending on that hardware state becomes stale. Firmware pin-map and HIL claims must be reproduced; an unchanged API contract or previously approved requirement may remain eligible. If dependency coverage is incomplete, the affected scope widens conservatively. The example shows the intended composition: each domain uses its own evidence methods, while claim properties, state binding, revalidation, authority, and effect integrity follow one transition contract. 7 Evaluation Plan 7.1 What is already demonstrated The reference implementation described in Section 5.2 provides schemas, semantic predicates, aggregate admission functions, golden journeys, negative journeys, and contract tests. This demonstrates that the proposed semantics can be encoded and deterministically tested. It does not demonstrate live conformance in OpenHands, Codex, Claude Code, Copilot, Nool, or other products; nor does it demonstrate lower defect rates in production. 7.2 Adversarial admission benchmark A meaningful benchmark should compare the full aggregate decision against weaker baselines: ⬇ B0 agent says DONE B1 trace or evidence file exists B2 schema validates B3 evidence is signed B4 policy hook passes B5 reviewer artifact exists B6 Assurance Spine aggregate admission Test cases should include: • correct evidence bound to the wrong artifact digest; • stale policy or requirement baseline; • a test adapter claiming human authority; • one passing result masking a contradictory failure; • replayed, expired, consumed, or wrong-scope approval; • fresh-context verification mislabeled as organizational independence; • incomplete dependency coverage reported as unchanged; • a defer or residual-risk acceptance misused as a verification waiver; • omitted model/runtime/tool changes; • a race between approval and effect execution; • correct software evidence paired with the wrong PCB or firmware revision; and • fabricated provenance, authority, or adapter identity. Proof-or-Stop, DEMM-Bench, CAC, AgentDojo, ToolEmu, AgentSecBench, and SWE-Bench Pro Verified offer complementary failure models and benchmark design patterns [2, 4, 13, 49, 50, 51, 52, 53]. 7.3 Measures Evaluation should report: • false transition acceptance and false rejection; • stale-evidence and approval-replay detection; • precision of claim-scoped revalidation; • unsupported property-claim detection; • authorization latency and runtime overhead; • human reviewer time and escalation load; • evidence collection and storage cost; • task completion under fixed risk and budget; • cross-runtime semantic agreement; and • exact-effect integrity: whether the reviewed digest is the one merged, deployed, flashed, or fabricated. 7.4 Empirical program Four stages are proposed: 1. Reference conformance: run all golden and negative journeys against the repository semantics. 2. Cross-runtime conformance: implement adapters for at least OpenHands and one additional hook-capable coding agent, then compare identical decisions. 3. Domain vertical slices: evaluate one production-like software task, one PCB-to-firmware change, and one signed firmware update path. 4. Field study: compare ordinary CI/review against Assurance-Spine-assisted delivery on defect escape, cycle time, reviewer effort, and revalidation scope. The hypothesis is not that more gates always improve delivery. The testable proposition is that property-aware, state-bound admission reduces specific false-authority and stale-evidence failures at acceptable cost. 8 Threats, Limitations, and Conclusion The market scan is representative and based on public sources; private product capabilities may exceed their documentation. Rapid product change can make individual feature comparisons stale. Some 2026 research cited here is preprint work and should not be treated as settled evidence. Repository conformance is not production validation. Source and authority resolvers remain trust anchors; compromised providers can still produce false decisions. Semantic correctness remains bounded by the quality of requirements, evidence methods, environment models, and human judgment. The framework can support regulated engineering activities but does not itself establish legal compliance, certification, or safety. The external comparison nevertheless changes the paper’s conclusion in an important way. The ecosystem does not lack agent sandboxes, permissions, hooks, traces, policy engines, attestations, inventories, or assurance representations. It lacks a widely shared contract that composes those records into a defensible answer to one operational question: May this exact artifact, under this exact policy and risk context, be advanced by this authority on the basis of this evidence? The Agile-V Assurance Spine answers that question by treating agent outputs as claims, evidence sources as capability-bounded producers, baselines as frozen state, changes as revalidation triggers, approvals and exceptions as exact-scope authority records, and lifecycle decisions as explicit receipts. It then requires a final recheck where the consequential effect occurs. This is deliberately narrower than general AI safety and broader than a coding-agent hook. It is an engineering transition contract. Its value will depend on whether future conformance and field studies show that it catches stale, misbound, insufficient, or falsely authorized evidence without making useful delivery impractically slow. That is the next research and implementation task. Generative AI Disclosure OpenAI ChatGPT was used for research assistance, source organization, drafting, language editing, and LaTeX preparation. The author assumes full responsibility for the final manuscript, including verification of claims and citations. References [1] C. Koch, “Agentic Agile-V: From Vibe Coding to Verified Engineering in Software and Hardware Development,” arXiv:2605.20456, 2026. https://arxiv.org/abs/2605.20456 [2] J. Huang et al., “Proof-or-Stop: Don’t Trust the Agent, Trust the Evidence - Loop Engineering for Verifiable Evidence-Gated Lifecycle Control,” arXiv:2607.14890, 2026. https://arxiv.org/abs/2607.14890 [3] O. Solozobov, “Decision Evidence Maturity Model for Agentic AI: A Property-Level Method Specification,” arXiv:2605.04093, 2026. https://arxiv.org/abs/2605.04093 [4] O. Solozobov, “DEMM-Bench: A Cross-Regime Benchmark for Agent-Runtime Governance-Evidence Sufficiency,” arXiv:2606.20634, 2026. https://arxiv.org/abs/2606.20634 [5] J. Cuneo, D. Chun, and G. Khanna, “AI-GRACE: A Use-Case Operationalization Framework for Agentic AI: From Organizational Objectives and Obligations to Deployment Capabilities and Architecture,” arXiv:2609.21192, 2026. https://arxiv.org/abs/2609.21192 [6] C. Jyu, S. Liu, and R. Jabbarvand, “Graphectory Viewer: A Tool for Process-Centric Analysis of Agentic Software Trajectories,” arXiv:2608.17195, 2026. https://arxiv.org/abs/2608.17195 [7] Z.-G. Xu and G. Qin, “LLM-assisted development of Rust for high-performance bioinformatics software: practices, workflows, and boundaries,” Genomics Communications, vol. 3, e018, 2026. https://doi.org/10.48130/gcomm-0026-0018 [8] S. Thakur, “Secure Policy-as-Code Guardrails for Agentic Identity Management,” 2026. https://doi.org/10.13140/RG.2.2.22830.47686 [9] S. Thakur, “Secure Explainable Audit Trails for Workflows in Agentic AI,” SSRN 7046079, 2026. https://papers.ssrn.com/sol3/papers.cfm?abstract_id=7046079 [10] A. Joshi, T. Finin, K. P. Joshi, and L. Kagal, “Deontic Policies for Runtime Governance of Agentic AI Systems,” arXiv:2606.19464, 2026. https://arxiv.org/abs/2606.19464 [11] J. C. Davis et al., “Cheap Code, Costly Judgment: A Case Study on Governable Agentic Software Engineering,” arXiv:2607.01087, 2026. https://arxiv.org/abs/2607.01087 [12] S. Thakur, “Blind Model Checking of Workflows in Agentic AI with Zero-Knowledge Proof,” SSRN 6736917, 2026. https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6736917 [13] J. He and D. Yu, “Cognitive Admission Control: Risk-Conditioned Assurance for Consequential Actions in Agentic Distributed Systems,” arXiv:2609.16313, 2026. https://arxiv.org/abs/2609.16313 [14] S. Yu, C. Fang, and Z. Chen, “Engineering Agent-Integrated Software: Interaction Contracts and Continuous Assurance,” arXiv:2609.11381, 2026. https://arxiv.org/abs/2609.11381 [15] G. Lupo, B. Q. Vo, and N. Locke, “Trustworthy AI Posture (TAIP): A Framework for Continuous AI Assurance of Agentic Systems at Horizontal and Vertical scale,” arXiv:2603.03340, 2026. https://arxiv.org/abs/2603.03340 [16] P. Dantas, L. Cordeiro, E. Nowroozi, and T. Norbert, “Toward Safe LLM Agents: A Survey of Specification, Verification, and Enforcement,” arXiv:2608.14590, 2026. https://arxiv.org/abs/2608.14590 [17] M. Kaptein, V.-J. Khan, and A. Podstavnychy, “Runtime Governance for AI Agents: Policies on Paths,” arXiv:2603.16586, 2026. https://arxiv.org/abs/2603.16586 [18] S. Jamshidi et al., “Verifiable Manifest Signing and Transparency Enforcement for Secure MCP-Based LLM Pipelines,” arXiv:2601.23132, 2026. https://arxiv.org/abs/2601.23132 [19] H. Bhati, “Beyond Code Generation: Reliability, Verification, and Cost Economics in the Agentic Software Development Lifecycle,” arXiv:2609.04681, 2026. https://arxiv.org/abs/2609.04681 [20] OpenHands, “Hooks” and OpenHands platform documentation, accessed Sep. 2026. https://docs.openhands.dev/openhands/usage/customization/hooks; X. Wang et al., “OpenHands,” arXiv:2407.16741. [21] OpenAI, “Running Codex Safely at OpenAI,” accessed Sep. 2026. https://openai.com/index/running-codex-safely/ [22] Anthropic, “Claude Code Security,” accessed Sep. 2026. https://code.claude.com/docs/en/security [23] GitHub, “About hooks for GitHub Copilot,” accessed Sep. 2026. https://docs.github.com/en/copilot/concepts/agents/hooks [24] Cursor, “Hooks,” accessed Sep. 2026. https://cursor.com/docs/hooks [25] Windsurf, “Cascade Hooks,” accessed Sep. 2026. https://docs.windsurf.com/windsurf/cascade/hooks [26] Google, “Jules: Reviewing plans and giving feedback,” accessed Sep. 2026. https://jules.google/docs/review-plan/ [27] Cognition, “Devin Advanced Capabilities,” accessed Sep. 2026. https://docs.devin.ai/work-with-devin/advanced-capabilities [28] Cline, “Permission Handling,” accessed Sep. 2026. https://docs.cline.bot/sdk/guides/permission-handling; Aider, “Git integration,” https://aider.chat/docs/git.html [29] Nool, “Architecture” and “Persistent Agent Memory,” accessed Sep. 2026. https://w.nool.dev/architecture [30] LangChain, “LangSmith Observability,” accessed Sep. 2026. https://docs.langchain.com/langsmith/observability [31] Arize, “Phoenix Overview and Tracing,” accessed Sep. 2026. https://arize.com/docs/phoenix/get-started [32] OpenTelemetry, “Semantic conventions for generative AI systems,” accessed Sep. 2026. https://opentelemetry.io/docs/specs/semconv/gen-ai/ [33] Open Policy Agent, “Gatekeeper Operations and Admission,” accessed Sep. 2026. https://open-policy-agent.github.io/gatekeeper/website/docs/operations/ [34] SLSA, “Provenance v1.2,” accessed Sep. 2026. https://slsa.dev/spec/v1/provenance [35] in-toto, “Attestation and software supply-chain framework,” accessed Sep. 2026. https://in-toto.io/ [36] Sigstore, “Bundle format and verification,” accessed Sep. 2026. https://docs.sigstore.dev/about/bundle/; GitHub, “Using artifact attestations,” https://docs.github.com/en/actions/security-for-github-actions/using-artifact-attestations [37] CycloneDX, “Machine Learning Bill of Materials” and “BOM-Link,” accessed Sep. 2026. https://cyclonedx.org/capabilities/mlbom/ [38] SPDX, “AI and Dataset Profiles in SPDX 3,” accessed Sep. 2026. https://spdx.dev/learn/areas-of-interest/ai/ [39] GoogleCloudPlatform, k8s-aibom, accessed Sep. 2026. https://github.com/GoogleCloudPlatform/k8s-aibom [40] Model Context Protocol, “Specification 2026-07-28,” 2026. https://modelcontextprotocol.io/specification/2026-07-28 [41] Agent2Agent Protocol, “Specification,” accessed Sep. 2026. https://a2a-protocol.org/latest/specification/ [42] AG-UI, “Agent User Interaction Protocol Specification 1.0,” 2026. https://docs.ag-ui.com/spec/1.0 [43] NIST, “Open Security Controls Assessment Language (OSCAL),” accessed Sep. 2026. https://pages.nist.gov/OSCAL/ [44] W3C, “PROV-O: The PROV Ontology,” W3C Recommendation. https://w.w3.org/TR/prov-o/ [45] Object Management Group, “Structured Assurance Case Metamodel (SACM),” accessed Sep. 2026. https://w.omg.org/spec/SACM/ [46] The Assurance Case Working Group, “Goal Structuring Notation Community Standard,” accessed Sep. 2026. https://scsc.uk/gsn [47] NIST, “Artificial Intelligence Risk Management Framework,” and “Generative AI Profile,” accessed Sep. 2026. https://w.nist.gov/itl/ai-risk-management-framework [48] European Union, Regulation (EU) 2024/1689, consolidated text 27 Jul. 2026; OWASP, “Top 10 for Agentic Applications 2026.” https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:02024R1689-20260727; https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/ [49] P. Zheng et al., “SWE-Bench Pro Verified: A Reliable Benchmark for Software Engineering Agents,” arXiv:2609.08149, 2026. https://arxiv.org/abs/2609.08149 [50] E. Debenedetti et al., “AgentDojo: A Dynamic Environment to Evaluate Prompt Injection Attacks and Defenses for LLM Agents,” arXiv:2406.13352, 2024. https://arxiv.org/abs/2406.13352 [51] Y. Ruan et al., “Identifying the Risks of LM Agents with an LM-Emulated Sandbox (ToolEmu),” arXiv:2309.15817, 2024. https://arxiv.org/abs/2309.15817 [52] F. Alpay and T. Alpay, “AgentSecBench: Measuring Prompt Injection, Privacy Leakage, and Tool-Use Integrity in LLM Agents,” arXiv:2605.26269, 2026. https://arxiv.org/abs/2605.26269 [53] L. Ba, Q. Li, and S. Li, “CIBER: A Comprehensive Benchmark for Security Evaluation of Code Interpreter Agents,” arXiv:2602.19547, 2026. https://arxiv.org/abs/2602.19547 [54] T. King, S. Kehrberg, M. Beigl, and T. Röddiger, “pcbGPT: Automatic PCB Schematic Synthesis from Natural Language Requirements,” arXiv:2606.01188, 2026. https://arxiv.org/abs/2606.01188 [55] Agile-V, agile_v_skills, repository snapshot 982c1f6435219f0fe83dcef485503f45a7e9717e, and agentic_agile_v, repository snapshot 54eaa5451fcbfe9fa1c59355584deddbf7cef342, accessed 23 Sep. 2026. https://github.com/Agile-V/agile_v_skills; https://github.com/Agile-V/agentic_agile_v [56] GitLab, “GitLab Duo Agent Platform” and “AI Governance,” accessed Sep. 2026. https://docs.gitlab.com/user/duo_agent_platform/; https://docs.gitlab.com/user/ai-governance/ [57] SonarSource, “AI Code Assurance” and “Quality gates for AI code,” accessed Sep. 2026. https://docs.sonarsource.com/sonarqube-server/project-administration/ai-features/set-up-ai-code-assurance; https://docs.sonarsource.com/sonarqube-server/2025.3/quality-standards-administration/ai-code-assurance/quality-gates-for-ai-code [58] Qodo, “Custom Compliance,” “Rule System,” and “Agentic PR Review,” accessed Sep. 2026. https://docs.qodo.ai/qodo-documentation/code-review/qodo-merge/features/custom-compliance; https://docs.qodo.ai/qodo-release-notes/release-notes/qodo-ide-plugin-latest-release [59] Semgrep, “Semgrep Guardian” and “Semgrep Workflows,” accessed Sep. 2026. https://semgrep.dev/products/semgrep-guardian/; https://semgrep.dev/products/semgrep-workflows [60] Snyk, “Developer Guardrails for Agentic Workflows” and “Snyk Studio Usage Analytics,” accessed Sep. 2026. https://docs.snyk.io/integrations/developer-guardrails-for-agentic-workflows; https://docs.snyk.io/integrations/snyk-studio-agentic-integrations/usage-analytics [61] Tabnine, “Tabnine Agent,” “Tabnine CLI,” and enterprise context documentation, accessed Sep. 2026. https://docs.tabnine.com/main/getting-started/tabnine-agent; https://docs.tabnine.com/main/getting-started/tabnine-cli