How proposals work.
An allowlisted analyst records a maintainer's repository, capability, taxonomy, or test-mapping proposal for review without changing approved state directly.
Evidence boundary: This intake is analyst-mediated and the command requires an allowlisted analyst identity. Submission is not approval. Referenced evidence IDs are syntax-checked as UUIDs, but an analyst must verify that each record is visible before acceptance. Accepted proposals create a new effective-dated version with an audit record.
Next useful action: Give an allowlisted analyst a public source and rationale, then record the proposal for review.
Journey context2 active, 3 steps⌄
Current route guide: How proposals workActive journeys:Propose a registry changeEvolve the taxonomyView all journeys - 1Choose the narrowest repository, capability, taxonomy, or test-mapping proposal type.
- 2Provide stable identifiers, a public source, and a concrete rationale. UUID syntax does not prove evidence visibility.
- 3Use an allowlisted analyst identity to record the proposal without treating submission as approved state.
Current route guide: How proposals workActive journeys:Propose a registry changeEvolve the taxonomyView all journeys - 1Choose the narrowest repository, capability, taxonomy, or test-mapping proposal type.
- 2Provide stable identifiers, a public source, and a concrete rationale. UUID syntax does not prove evidence visibility.
- 3Use an allowlisted analyst identity to record the proposal without treating submission as approved state.
Next useful action: Give an allowlisted analyst a public source and rationale, then record the proposal for review.