Validation proof for generated agent backends

Validation executes the generated backend in an isolated sandbox, as the artifact you would download — not as a simulation of it. The run confirms the service boots, mounts the routes the approved specification promised, and answers its endpoint contract with the declared schemas.

Because the sandbox runs the artifact itself, the evidence describes the code you receive. There is no separate “demo build” that behaves differently from the ZIP.

Each artifact version carries its own record. When a requirement changes and a new version is generated, the evidence is produced again for that version — an older passing run is never reused as proof for changed source.

• Evidence 1: The approved specification and the artifact version it produced.
• Evidence 2: Generation status, including any failure that prevented a complete artifact.
• Evidence 3: Sandbox validation results bound to that exact artifact version.
• Evidence 4: The endpoint and schema contract the receiving team can inspect.
• Evidence 5: The new version identifier for every later prompt-driven edit.
• Evidence 6: A downloadable artifact or a truthful deployment-preflight result.

A passing validation run proves the artifact version works in the sandbox. It does not prove that credentials, provider configuration, networking, or a deployment lane are ready in your environment. Deployment preflight checks those separately and reports what is missing instead of fabricating a live endpoint URL.

That boundary is deliberate. It is the difference between evidence and marketing — the same discipline described in the build guide.