Project Proposals
Assessment identity
Section titled “Assessment identity”- Repository:
project-proposals - Revision:
00666ecb6e9e6e6324f605ac992af53b17041552 - Assessment date: 2026-08-09
- Evidence class: bounded maintainer attestation; portfolio strategy remains private
Domain
Section titled “Domain”Project Proposals owns pre-project intake, review, decision, and handoff. It must preserve the decision rationale without becoming a second architecture or operations source after work begins.
Mechanisms observed
Section titled “Mechanisms observed”- untrusted inbox material is separate from governed proposal packets;
- every governed packet has a stable identifier and typed lifecycle envelope;
- review conclusions cite exact canonical repository revisions;
pending,compatible,changes_required,unknown, andnot_applicableretain different meanings;- decision readiness is an offline, read-only gate;
- terminal decisions are not substantively rewritten;
- material boundary changes use supersession rather than mutation; and
- accepted work receives an exact handoff to a canonical repository, after which that repository owns current implementation truth.
What it paid to teach
Section titled “What it paid to teach”A coordinating decision record remains truthful by stopping at handoff. It can retain why a project began without copying evolving architecture, hosting, or runtime state.
This implementation supports stable identities, exact-revision review, explicit unknowns, and ownership transfer. It also shows that a typed envelope and human case can remain separate views of one packet.
Limits
Section titled “Limits”A project proposal decides whether and how work begins; it is not itself a complete domain-current-truth implementation. Its lifecycle names and required portfolio reviews are local policy, not core requirements.