Project Proposals

Assessment identity

• Repository: project-proposals
• Revision: 00666ecb6e9e6e6324f605ac992af53b17041552
• Assessment date: 2026-08-09
• Evidence class: bounded maintainer attestation; portfolio strategy remains private

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

• 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, and not_applicable retain 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

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

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.