Artifacts and assurance
Planning and Design produces five connected artifacts before bounded implementation starts. Together they make the planned route, evidence, execution bounds, and completion criteria inspectable.
| Artifact | Why it exists |
|---|---|
<lifecycle-topic>-technical-plan.md |
Records the technical plan and visible Markdown task state. |
design.md |
Records design reasoning and interfaces. |
seit.json |
Holds prospective verification proof rows. |
implementation.json |
Holds nested execution authority, waves, slices, and dispatch. |
<plan-name>-dod-manifest.html |
Projects planned versus actual work for people; it is not execution authority. |
Two machine-readable records sit alongside the package: journey.json records Lifecycle identity, checkout lease, decisions, planning receipts, and profile selection; authority.json records the authority envelope.
Normal visible task progress is PROPOSED → READY → IN_PROGRESS → EVIDENCE_READY → VALIDATING / REVIEWING → ACCEPTANCE → COMPLETE.
When evidence can close a gate
Section titled “When evidence can close a gate”An Implementer, Light Implementer, or Integration Engineer execution session may produce diagnostic verification receipts, but those do not satisfy assurance. A fresh Test Engineer assurance session reruns required claims against the exact stable candidate.
An assurance receipt must bind the candidate, claim, backend, version, command or configuration, and evidence digest. An unavailable activated backend is ERROR / backend_unavailable, not success. Stale evidence, malformed claims, and derived or inconclusive results do not become a passing gate.
The optional verification bridge shapes requests and receipts; it never runs a backend, downloads software, or turns a heuristic answer into independent evidence.