Build log / Operating method 011

A generated file is not a delivered product.

An agent can finish a task, produce a plausible document and report that its checks passed. None of those facts establishes that a customer-ready artifact exists. We now require four separate gates before an AI-generated deliverable can support acquisition.

· Method adopted October 29 · PUBLIC_NOW · No QA outcome published

Four-gate quality assurance chain for AI-generated deliverables: input contract, canonical artifact, independent verification and acceptance. A completion claim stops before the gates; acquisition begins only after acceptance.
The chain is deliberately asymmetric: a failed gate returns the artifact for correction. It does not become a softer pass.

The completion claim is the start of QA

Agent systems tend to make completion look binary. A worker returns DONE, a file appears in storage, or a test summary says every case passed. Those are useful events, but they describe the producer's view of the work.

A commercial deliverable needs a consumer-side answer: can another actor identify the exact input, retrieve the exact artifact, reproduce the important checks and confirm that the output satisfies the promised product? If not, the artifact may be useful draft work. It is not yet an accepted product.

Four gates, four different questions

Gate 1Input contractWhich fields were supplied, derived, assumed or unavailable?
Gate 2Canonical artifactAre the exact customer-facing bytes stored with version and digest?
Gate 3Independent verificationCan a separate reviewer read, render and test the artifact?
Gate 4AcceptanceDoes this product tier satisfy its own explicit criteria?

Gate 1 prevents invented specificity

Our current intake has seven buyer answers. One planned production kit expects twelve fields, including sector branches. The tempting shortcut is to let the generation step fill the gap. That would make the report look complete by converting missing evidence into fabricated precision.

The accepted contract must map every downstream field to one of four origins: buyer-declared, reproducibly derived, explicit scenario assumption or unavailable. If a required field cannot be obtained from the seven answers, the honest outputs are not available or a second authorized capture. Enrichment is not permission to invent.

Gate 2 makes delivery durable

A local file is not a canonical deliverable. The accepted object is the exact stored artifact, paired with its version, byte size and cryptographic digest. The manifest must describe the uploaded bytes, not an earlier local copy. Source files and build instructions matter when the product promises reproducibility.

This borrows an invariant from software supply-chain practice: provenance is only useful when it applies to the artifact being inspected. SLSA's verification guidance compares the artifact digest and provenance against expected values. We are not claiming SLSA compliance; we are applying the same refusal to treat metadata and payload as interchangeable.

Gate 3 must be independent of the producer

Self-tests catch many defects. They also inherit the producer's assumptions. A separate reviewer must download the canonical artifact, verify its digest, render every page, inspect formulas or transformations, run negative cases and compare the output with the input contract.

NIST's AI Risk Management Framework recommends objective, repeatable and documented test, evaluation, verification and validation processes. It also notes that independent review can reduce internal bias and conflicts of interest. For our experiment, “independent” means the acceptance evidence is produced outside the generation step and can disagree with it.

Gate 4 is product-specific

A pass for one product tier cannot be generalized to the others. Shared branding, prompts or code do not prove that each package contains the promised scope. Every tier needs its own criteria, artifacts and acceptance record, using the same synthetic intake when comparison is useful.

The business consequence is direct: acquisition can scale a fulfillment defect faster than it can validate demand. The deliverable gate therefore precedes paid traffic, live checkout and stronger claims about automation. This is a sequencing decision, not a claim that the current products have passed.

Current evidence boundary

The four-gate method and the decision to put deliverable acceptance before acquisition were recorded on October 29, 2026. This article publishes the method only. It does not disclose or imply any QA result, customer result, conversion, revenue or product acceptance. Operational evidence from October 29 remains under the 15-day hold.

Human time and autonomy

Designing the contract, defining the gates and reviewing the workflow required human work. HBT is greater than zero and unmeasured. This method does not establish a new HOT result. HMPT remains undefined because no verified economic transaction is reported here.

Sources

Use the four questions on your own agent output: what was known, which bytes are canonical, who verified them independently, and what explicit criterion turned the artifact into an accepted product?