Requirement to release, in one row
A requirements traceability matrix is normally assembled by hand, weeks after the fact, from memory and tickets. Here it is a projection of the same event stream the product runs on, so it is current by construction and cannot describe a history that did not happen.
How it works
Rows are joined from gates, releases, deploys and attestations — the same stored facts the boards project from, so the matrix cannot drift from what happened.
Each row carries the spec side — synthesized, approved, who approved it, how many acceptance criteria — and the delivery side, through to the release sha and who executed it.
A missing proposal, an unapproved spec, or an absent attestation reads as null in the row rather than being omitted, so an auditor sees the hole instead of a shorter list.
The whole matrix exports as CSV or JSON, tenant and project scoped, for the people who will never log into your console.
Human control
A read-only projection of governance that already happened — nothing in the matrix can be edited, only produced by the gates it reports on.