Write Technical Acceptance Report

Build a report that lets a decision-maker accept or reject a defined change without trusting undocumented claims. Separate facts observed now from historical claims and unexecuted expectations.

Choose depth

• Compact: a bounded low-risk change. Establish the expected outcome, run the relevant authoritative checks, and return a small requirement/evidence/status table plus a scoped verdict. Do not require a standalone report file, database fixture, or twelve report sections.
• Full: high-risk/stateful/migration work or an explicit detailed report. Follow the complete workflow and template below, selecting only applicable risk surfaces.

Both modes distinguish actual results from inference and preserve unresolved evidence. Acceptance does not authorize deployment or merge. A request to inspect/verify remains read-only apart from isolated test artifacts; fixes need an implementation request. Code review belongs to code-review-and-quality; unexplained failures to hai-debug. Do not repair a failed requirement merely to obtain a favorable acceptance verdict.

Establish the audit contract