What Counts as Proof for AI-Generated Software?

A green test run can prove that a specific test passed. It cannot, by itself, prove that every requirement was implemented, that a live system behaved correctly, that cleanup succeeded, that the software is secure, or that it is ready for production.

As coding agents take on larger and more security-sensitive systems, teams need a stronger answer to a deceptively simple question:

What, exactly, does this result prove?

This article presents a practical evidence model grounded in Chrysent’s internal sandboxctl case study: a security-sensitive Rust CLI delivered through an instrumented OPI process and validated against a reference Kubernetes environment. The purpose is not to turn one project into a universal benchmark. It is to show how a team can connect requirements, implementation, tests, live observations, cleanup, and limitations without allowing a narrow PASS to become a broader claim than the evidence supports.

Evidence class: first-party measured case study The delivery telemetry and repository facts were directly recorded. The final local and live results are described as repository-reported because the committed validation record is available, while the private raw live-run directory was not included in the source package reviewed for this article. No independent third-party security audit was performed.

“Green” is not one claim

Software teams often compress several distinct statements into one phrase: “the build is green.” That shortcut becomes dangerous when software is produced through agents that can generate implementation, tests, documentation, and even the language used to summarize their own success.

Consider the difference among these statements:

A useful definition follows:

Software proof is a bounded claim supported by identified evidence, against an accepted authority, in a known environment, at a known point in time.

That is not mathematical proof. It is disciplined claim management.

For convenience, this article uses AI-generated software to mean software substantially implemented and revised through an agentic delivery process. It does not imply zero human involvement. In the sandboxctl case, humans retained authority over material product obligations, security decisions, live-mutation authorization, and accepted risks.

1. Start with authority, not tests

A test can only be meaningful relative to something it is intended to verify. If requirements are unclear, conflicting, or allowed to drift silently, a passing test may only prove that the software matches the test author’s latest interpretation.

The sandboxctl repository defined an explicit authority order:

1. the product and implementation specification;
2. the reference-environment requirements;
3. the threat model; and
4. the reference live procedure.

Code, tests, traceability data, evidence files, guides, contributor policy, and operational skills were subordinate to those accepted sources. They could implement, explain, and verify the baseline, but they could not silently redefine it.

That distinction matters in agentic delivery. An agent can produce a test that agrees with its implementation while both diverge from the accepted requirement. Without source authority, the test and the code can become mutually reinforcing but jointly wrong.

A strong evidence chain therefore starts here:

The first question is not “Did the tests pass?” It is:

Which accepted obligation was this test designed to support?

2. Treat traceability as part of the product

Traceability is often treated as documentation created after implementation. In a governed delivery process, it is an executable control against requirement loss and evidence inflation.

The sandboxctl implementation tracked:

• 321 numbered source requirements in the product-traceability inventory;
• 22 synthetic obligations derived from normative prose that did not already have numbered identifiers; and
• 343 tracked product-traceability obligations in total.

The broader accepted-document inventory contained 348 numbered requirements across the product and companion documents. Adding the 22 synthetic obligations produced a derived inventory of 370 normative obligations.

Those numbers require careful language:

343 is a tracked product-traceability inventory. 370 is a derived accepted-document inventory. Neither number is a live-test pass count.

The accepted specifications also named 74 acceptance and regression scenarios. The internal evidence catalog contained 68 evidence records; six external or reference-platform scenarios sat outside that internal catalog.

The point is not to maximize the number of requirements, mappings, or tests. The point is to prevent four common failures:

1. a requirement disappears between specification and implementation;
2. a test exists but is mapped to the wrong obligation;
3. failed evidence is still allowed to produce a PASS; or
4. a source-document hash is mistaken for proof that the implementation matches the source.

The last failure is especially subtle. A source hash can show that the accepted document did not change. It cannot show that the implementation is correct. In the sandboxctl model, source identity, mappings, tests, evidence, and finalization remained separate controls.

3. Build a layered evidence stack

No single validation layer was treated as sufficient. The repository separated seven layers, each answering a different question.

These layers are complementary. Local tests can be faster, more deterministic, and more exhaustive over code paths. Live acceptance can observe real controllers and external behavior. Traceability can detect missing obligations that neither test suite knows to exercise. Human authorization can stop the system from redefining the goal simply because a weaker goal is easier to pass.

The evidence stack is therefore not a pipeline in which the last stage makes every earlier stage irrelevant. A live test does not replace source authority. A sealed evidence bundle does not replace a correct implementation. Human approval does not replace technical verification.

4. Separate local verification from live acceptance

The canonical local gate for sandboxctl contained seven required commands:

cargo fmt --all -- --check
cargo clippy --all-targets --all-features -- -D warnings
cargo test --all-targets --all-features
bash -n scripts/reference-live-acceptance.sh tests/reference_live_acceptance_classifier.sh
bash tests/reference_live_acceptance_classifier.sh
git diff --check
cargo audit

Every command had to execute and exit with status 0. A command that did not run was not counted as a pass.

The committed validation record reports:

The ignored Rust test was an explicit subprocess entry point, not an unreported test failure.

These results establish a substantial local verification record. They do not, by themselves, establish how a real Kubernetes cluster will apply admission policy, complete asynchronous deletion, generate controller-owned resources, update status conditions, route traffic, or remove temporary state.

That is the role of live acceptance.

The committed validation record reports that the default all-phase reference run:

• exited with code 0;
• produced a machine-readable summary with status PASS;
• passed all seven global preflight checks;
• reported cleanup as PASS; and
• passed final exact-absence checks.

These statements remain repository-reported in this article. The private raw run directory—with command records, evidence rows, audit output, logs, and generated manifests—was not included in the source package reviewed here.

That qualification does not turn the result into zero evidence. It defines the level of evidence available to the reader.

5. Make every PASS carry its scope

The live harness supported several execution modes:

The default full run executed eight phases in order:

1. bootstrap;
2. verify;
3. namespaces;
4. user-access;
5. runtime-storage;
6. admission-rbac;
7. network; and
8. cleanup.

A full PASS required ten machine-checkable conditions:

1. the harness process exited 0;
2. summary.json existed and parsed as one JSON object;
3. its schema version was 1;
4. its status was PASS;
5. its recorded exit code was 0;
6. its run identity matched the requested run;
7. every applicable evidence row reported PASS;
8. no applicable row reported FAIL or SKIP;
9. cleanup evidence reported exact cleanup as PASS; and
10. final exact reads proved that all named temporary resources were absent.

This is more than strict formatting. It prevents a narrow or incomplete run from being relabeled after the fact.

A useful reporting rule is:

The scope of the conclusion must be no broader than the narrowest material evidence layer supporting it.

A selected phase can support a selected-phase claim. A full reference run can support a full reference-run claim. Neither supports “every requirement was proven,” “the system is secure,” or “the product is ready for every production environment.”

6. Exact cleanup is part of the test

State-changing acceptance creates a second obligation: the test must account for what it changed.

A function can appear to succeed while leaving behind:

• a namespace that is still terminating;
• a policy with an unexpected identity;
• a controller-generated resource that was replaced rather than preserved;
• an artifact that belongs to a previous run;
• a partially published credential set;
• a collision with pre-existing state; or
• a deletion whose failure was mistaken for absence.

The sandboxctl review record found both incomplete collision refusal and cleanup behavior that could falsely report exact success. Those findings blocked final acceptance. The harness was repaired, the local gate was rerun, and a fresh live run was completed after the material changes.

The resulting rule was simple:

Any cleanup failure makes a state-changing run non-PASS.

Final absence was not inferred from a delete request or an exit code. It was checked through exact reads of the named temporary resources.

This matters beyond test hygiene. Exact cleanup protects the validity of future runs. Without it, a later PASS may depend on stale state created by an earlier attempt.

7. A 503 is not proof of network-policy enforcement

Negative tests are especially vulnerable to false confidence.

Suppose a request succeeds before a network exception is removed and returns HTTP 503 afterward. It is tempting to conclude that the policy removal caused the denial.

But the same visible result could be produced by a different failure:

• the backend Deployment became unavailable;
• the Pod stopped being ready;
• the EndpointSlice lost its target;
• the Gateway or route became stale;
• the generated Service was replaced;
• the NodePort changed;
• the transport path failed; or
• the Kubernetes API observation failed.

The final sandboxctl denial check therefore required more than a failed request.

First, the external request had to match an exact shape:

• curl exit code 22;
• empty standard output; and
• exactly one standard-error content line reporting HTTP 503.

Then the harness required corroborating evidence that:

1. the exact exception CiliumNetworkPolicy was absent;
2. the managed policy inventory was empty;
3. the backend Deployment remained current and available;
4. the backend EndpointSlice still contained one ready Pod target on TCP port 8080;
5. the target-reference API version was absent, null, or v1;
6. the backend Pod remained ready with the expected application label;
7. the Gateway remained current with Accepted=True and Programmed=True;
8. the HTTPRoute remained current with Accepted=True and ResolvedRefs=True; and
9. the generated Service retained the frozen UID and NodePort used by the positive probe.

The positive and denial probes also reused the same frozen request tuple: transport, node address, NodePort, Service UID, Host header, and path.

This is a general lesson for AI-generated software:

A negative result is evidence of a control only when competing explanations are constrained or eliminated.

A permission denial is not proved merely because an operation failed. A rollback is not proved because a command returned an error. An object is not absent because a delete was requested. Causal evidence is harder than result classification, but it is what prevents broken systems from masquerading as secure ones.

8. Seal evidence without confusing integrity with truth

The evidence model also included finalization and a detached bundle seal.

The finalization process required 68 evidence records across nine evidence groups, together with fixed traceability, cleanup, provenance, and summary artifacts. The detached seal hashed the prerequisites and the exact generated finalization bytes.

The “detached” part was necessary. An artifact cannot reliably contain a hash of its own final bytes without creating a circular definition. Earlier review found that a self-referential digest would be unpersistable and could create a false appearance of self-attestation. The design was changed so the finalization content and its seal were separate.

A seal can support claims such as:

• these are the exact bytes that were finalized;
• the required artifact set was present under the finalization rules; and
• the bundle was not silently changed after sealing.

It cannot, by itself, support claims such as:

• every requirement was implemented correctly;
• every observation in the bundle was true;
• the software is secure; or
• the result was independently audited.

Evidence integrity protects the record. It does not automatically prove the truth of every claim inside the record.

9. What the sandboxctl result established

The strongest public interpretation of the available record is bounded and specific.

Supported by the available evidence

• The repository contains an accepted authority hierarchy, static traceability, local validation, a live harness, cleanup rules, and an evidence-finalization model.
• The product-traceability inventory contains 321 numbered source requirements and 22 synthetic obligations, for 343 tracked obligations.
• The committed validation record reports 7 of 7 local-gate commands passed.
• The committed validation record reports 416 Rust tests passed, zero failed, and one ignored as an explicit subprocess entry point.
• The committed validation record reports that the default all-phase reference run exited 0 and produced summary status PASS.
• The committed validation record reports cleanup PASS and final exact absence PASS.
• The OPI telemetry records that the final local and live validation were rerun after material collision, cleanup, and harness changes.

Not established by the available evidence

• That all 343 tracked obligations or all 370 derived normative obligations passed live testing.
• That every accepted requirement is fully implemented.
• That the result applies to every Kubernetes environment or configuration.
• That the product is production ready.
• That the system prevents every container, VM, platform, or policy failure.
• That strict TLS hostname isolation is proved for public services sharing an IP.
• That worker image-pull supply-chain restrictions are enforced.
• That the raw private live-run directory was independently reviewed for this article.
• That an independent third party performed a security audit, penetration test, or certification assessment.

Two accepted operator-authorization artifacts also remained unresolved:

1. an exact compliant ClusterRole/sandboxctl-operator manifest; and
2. a complete manual installation procedure for that authorization profile.

For that reason, the repository did not claim complete repository-wide specification parity.

10. A reusable evidence contract for agentic software delivery

Teams do not need to reproduce the exact sandboxctl architecture to adopt the underlying discipline. They can begin by requiring every material result to answer ten questions.

1. What is the claim?

Write the conclusion before choosing the evidence. “The selected network phase passed in the reference environment” is testable. “The system is secure” is too broad.

2. What is the accepted authority?

Identify the specification, threat model, policy, ticket, or approved decision that defines success. Resolve conflicts before implementation.

3. What is the traceability path?

Map the obligation to implementation, tests, evidence, and final reporting. Prevent a missing or failed mapping from defaulting to PASS.

4. Which evidence layer supports the claim?

Distinguish compilation, local tests, deterministic harness checks, live observations, platform evidence, and human authorization.

5. What was the execution scope?

Record selected phases, exclusions, configuration, environment, and point in time. Do not relabel a narrower run as complete acceptance.

6. Did negative results rule out alternative causes?

For denials, failures, rollbacks, and absence checks, establish causality rather than accepting any error as success.

7. Was cleanup exact?

For state-changing tests, verify the final state. Treat ambiguous or failed cleanup as non-PASS.

8. How is evidence classified?

Use visible labels such as:

• Measured telemetry;
• Verified repository fact;
• Repository-reported result;
• Derived calculation;
• Analytical interpretation; and
• Unavailable.

An unavailable datum is not zero. A repository-reported result is not independently reproduced evidence. A derived number is not a primary measurement.

9. What remains unresolved?

Name missing artifacts, accepted risks, private evidence boundaries, unavailable data, and absent external assurance.

10. What changes would stale the result?

A relevant change to source authority, implementation, dependency, configuration, environment, or operator input can invalidate a prior result. Define which changes require review and rerun.

This contract changes the unit of delivery. The output is no longer merely a patch or a test summary. It is a bounded claim with a traceable evidence path.

Frequently asked questions

Are passing unit tests proof that AI-generated code is correct?

They are proof that the executed tests passed against the tested source and environment. They do not prove untested requirements, live-system behavior, complete security, or production readiness. Their value depends on the accepted authority, coverage, test design, and result scope.

Does a full acceptance PASS mean the software is secure?

No. It means the defined acceptance criteria passed within the recorded scope. Security is a broader and continuing property involving threat coverage, residual risk, configuration, dependencies, operational controls, and changes over time. Independent assurance is also separate from internal acceptance.

Why does cleanup belong in acceptance testing?

A state-changing test can leave stale, ambiguous, or partially removed resources that affect future runs and real operations. Exact cleanup and final absence checks help establish that the run returned the environment to the expected state.

What does “repository-reported” mean?

It means a committed repository artifact records the result, but the underlying private or generated raw evidence was not available for independent inspection in the current review. The result can be reported with that qualification, but it should not be presented as independently reproduced.

Is requirements traceability the same as test coverage?

No. Traceability connects accepted obligations to implementation, tests, evidence, and reporting. Test coverage measures which code paths or behaviors were exercised. A project can have high code coverage and still omit a requirement; it can also trace a requirement without proving that the mapped implementation is correct.

From generated code to evidence-backed delivery

Generated code is increasingly easy to produce. Credible evidence is not.

The hard part of agentic software delivery is not asking a model to emit more implementation. It is preserving the authority of the specification, preventing tests from redefining success, routing failed findings back into repair, validating real behavior, proving cleanup, and stating what the result does not establish.

That is the deeper lesson of the sandboxctl case study:

The meaningful output of an agentic delivery system is not code alone. It is a governed change with a bounded, inspectable evidence record.

Methodology and evidence note

This article is based on Chrysent’s August 8, 2026 internal OPI and sandboxctl delivery, adversarial-review, validation, and evidence report. That report consolidates machine-generated OPI telemetry, Git and repository facts, accepted specifications, the threat model, implementation details, and the committed validation record.

Public claims in this article preserve the report’s evidence boundaries:

• direct telemetry and repository facts are presented within their recorded scope;
• live outcomes are described as repository-reported;
• derived inventories are identified as inventories rather than live-pass counts;
• private operational identifiers and environment details are omitted;
• two unresolved operator-authorization artifacts are named; and
• no independent third-party security audit is claimed.