The Governance Document Becomes the Revalidation Artifact
The June 2026 arXiv paper Fifty Years of Specification Completeness: What Aviation Certification Tells AI Governance About Epoch Limits, Proof Surfaces, and the Structural Gap, by Christo Zietsman, argues that AI governance documents should declare what evidence supports them and when their authority expires.
The Governance Artifact Is Static
The paper, arXiv:2606.25120 [cs.SE, cs.CY], was submitted on June 23, 2026. Its exact title is Fifty Years of Specification Completeness: What Aviation Certification Tells AI Governance About Epoch Limits, Proof Surfaces, and the Structural Gap. Zietsman uses aviation software certification as a comparison case for a narrower AI problem: the quality of the documents that govern AI systems.
The paper's examples are ordinary but consequential: a system prompt, an AGENTS.md file, a governance policy, or a task envelope. Those artifacts can authorize behavior, restrict tools, define review rules, or describe acceptable operating contexts. Yet they often circulate as instructions rather than as certification artifacts. A prompt may say what an agent should do without saying what evidence shows the rule is valid, which assumptions bound it, or which change would force revalidation.
That is the paper's useful separation. It does not say that aviation certification can make stochastic AI systems deterministic. It says the governance document is a static artifact whose structure can be assessed before the model runs.
What Aviation Adds
RTCA describes DO-178 as the core document for design assurance and product assurance for airborne software, with DO-178C as the current version published in 2011 and referenced by FAA Advisory Circular AC 20-115D. The FAA circular describes ED-12C/DO-178C as an acceptable means, though not the only means, for showing compliance for airborne software, and it incorporates ED-215/DO-330 where tool qualification is relevant. EASA's AMC 20-115D likewise treats ED-12C/DO-178C as an acceptable means for software aspects of product certification or ETSO authorization.
Zietsman's paper does not import airplane certification as ritual. It maps three structural habits from that world into AI governance documents: traceable linkage between claims and evidence, context-bounded validity that can expire, and objective evidence categories that define what proof means. The point is not that an AI policy should look like avionics paperwork. The point is that a governance claim without an evidence path is only a sentence.
Epoch Limits
The most portable idea is the epoch limit. A governance document should say the conditions under which it stops being valid. Time can be one condition: review this policy after a fixed interval. Events can be another: revalidate after a model upgrade, new tool, new data source, new user class, new jurisdiction, new prompt hierarchy, new retrieval index, or material incident. Assumptions can be a third: if the system no longer matches the operating assumptions under which the policy was written, the document has expired.
This matters because AI governance documents often behave as if validity were permanent. A safety prompt is copied forward after the model changes. A vendor policy is reused after a tool gains write access. A procurement approval survives a workflow redesign. Zietsman's aviation analogy inverts that default. Validity is not presumed forever; it has to be maintained against declared triggers.
Proof Surfaces
The second useful idea is the proof surface: the set of records by which a governance claim can be checked. If a document says the agent may not send external email without human approval, the proof surface should include the policy rule, the enforcement point, test cases, logs, exception handling, change history, and the person or process responsible for review. If a policy says a model is suitable for a high-impact workflow, the proof surface should identify the evaluation, scenario coverage, failure thresholds, review authority, incident channel, and unresolved gaps.
That framing fits the site's existing concern with AI safety cases, AI audits and assurance, agent rulebooks, and compliance traces. A safety case can be beautiful and still weak if nobody can tell which documents support which claims. A proof surface makes the boundary inspectable.
Why This Matters
The practical target is not academic neatness. It is organizational memory. Agents and model-mediated workflows are increasingly governed by layered documents: constitutions, system prompts, tool manifests, access policies, red-team reports, deployment approvals, model cards, incident procedures, and local work instructions. When those layers disagree, go stale, or lose their evidence, governance becomes a collage.
A revalidation discipline would force the organization to ask smaller questions. Which document controls this action? Which evidence supports that rule? What changed since approval? Which tests would fail if the assumption were wrong? Who has authority to renew, suspend, or retire the document? Those questions sound bureaucratic because they are. But bureaucracy is how authority becomes durable enough to audit.
Scope Boundary
The paper is a governance-structure argument, not an assurance system by itself. Its PromptQ framework was designed by the author, and the paper says independent empirical validation remains needed. It also acknowledges that DO-178C-style traceability at scale remains an open engineering problem. That boundary should stay visible.
The right takeaway is modest and useful: treat an AI governance document as a live certification artifact. Give it claim-evidence links, an expiry logic, a proof surface, an owner, and a change history. A document that cannot say when it stops being valid should not quietly authorize systems that change every week.
Sources
- Christo Zietsman, Fifty Years of Specification Completeness: What Aviation Certification Tells AI Governance About Epoch Limits, Proof Surfaces, and the Structural Gap, arXiv:2606.25120 [cs.SE, cs.CY], submitted June 23, 2026.
- Christo Zietsman, Fifty Years of Specification Completeness, arXiv PDF, reviewed June 25, 2026.
- RTCA, DO-178() Software Standards Documents & Training, reviewed June 25, 2026.
- Federal Aviation Administration, Advisory Circular AC 20-115D, July 21, 2017.
- European Union Aviation Safety Agency, AMC 20-115D Software considerations for certification of airborne systems and equipment, reviewed June 25, 2026.
- Related pages: AI Safety Cases, AI Audits and Assurance, The Agent Rulebook Leaves the Prompt, The Compliance Trace Becomes the Rulebook, The Operational Envelope Becomes the Trust Certificate, and The World Model Becomes the Bottleneck Certificate.