WIKI WORKSTREAM SPEC

Authenticated editing with role-based access. Version history and rollback. Per-term discussion threads. Layer-aware editing (Layer A terms require Standards Committee approval; Layer B terms require editorial review; Layer C terms accept qualified community contributions). Search and cross-reference navigation.

The framework's main glossary (currently 359 terms at v3.35) plus the AI Underwriting sub-glossary (30 terms). Each entry carries: term, definition, related terms, layer code (A/B/C for main glossary; category/modules/signals for AI Underwriting). Edit history with attribution.

Quarterly review cadence. Suggestion intake via mailto: channel. Editorial pass on community contributions. Layer A stability commitment enforced through the editorial workflow — no Layer A changes without version increment and transition table.

The wiki must operate within the framework's existing infrastructure constraints or be procured as a separate service. Authentication must integrate with the existing Supabase auth. The specification deliberately does not prescribe implementation — that decision belongs to the trustees.

This is not a wiki. This is the procurement specification for a wiki. The framework refused to ship a fake wiki (localStorage-only, broken-API, or external-redirect) and instead documented what a real wiki must do as a procurement contract. The personal-annotation layer on the Glossary page is clearly labelled as local-to-browser at every interaction point.