Customer Documents Roadmap

Delivery plan for the empty customer-document stubs

Note

This roadmap tracks the empty customer-document stubs in docs/customer-documents/. It is an authoring backlog, not a commitment. Priorities reflect the order in which stubs are most useful to surface for customer-facing review.

Snapshot (as of 2026-04-23)

Section Stubs Status Nav live?
adapter-specs/ Authored, canon-synced
validation-suites/adapters/ Authored, canon-synced
architecture-series/ 5 scaffolded ✅ (index only)
case-studies/ 3 scaffolded ✅ (index only)
executive-briefs/ 5 scaffolded ✅ (index only)
executive-governance-series/ 9 scaffolded ✅ (index only)
modernization-specs/ 7 scaffolded ✅ (index only)
validation-suites/domains/ 7 scaffolded ✅ (index only)
whitepapers/ 4 scaffolded ✅ (index only)

Total empty stubs: 40 across 7 sections. The two adapter sections are fully authored and canon-synced — they are the reference pattern for how derived customer documents should look.

Phased delivery plan

Phase 1 — Executive Briefs (5 pages)

Why first: single-page summaries are the shortest path from canon to customer-visible content. Each brief reads from one well-defined canon anchor and produces ~1 page of prose. They are the first surface a federal CIO/CISO would consume.

Order Brief Canon anchor Est. effort
1 governance-os-overview.md (completed) src/uiao/canon/substrate-manifest.yaml S
2 drift-engine-overview.md docs/docs/16_DriftDetectionStandard.qmd S
3 evidence-fabric-overview.md docs/docs/15_ProvenanceProfile.qmd S
4 zero-trust-overview.md src/uiao/canon/adr/adr-008-zero-trust-identity.md S
5 modernization-overview.md docs/docs/06_ProgramVision.qmd + 08_ModernizationTimeline.qmd M

Exit criteria: all 5 briefs pass metadata-validator; each cites its canon anchor in frontmatter; link-check clean.

Phase 2 — Architecture Series (5 pages)

Why second: explainers for the conceptual model. Customers who read an Executive Brief and want depth will click through to the Architecture Series next. Each explainer is ~2–4 pages.

Order Page Canon anchor Est. effort
6 six-plane-architecture.md docs/docs/01_UnifiedArchitecture.qmd M
7 drift-engine.md docs/docs/16_DriftDetectionStandard.qmd M
8 evidence-chain.md docs/docs/15_ProvenanceProfile.qmd M
9 three-layer-rule-model.md src/uiao/rules/ M
10 boundary-impact-model.md docs/docs/authorization-boundary.qmd L

Phase 3 — Whitepapers (4 pages)

Why third: long-form synthesis — requires the Executive Briefs and Architecture Series to be in place so whitepapers can cite them rather than repeat foundational material.

Order Paper Canon anchor Est. effort
11 uiao-governance-os-whitepaper.md substrate manifest + unified architecture L
12 zero-trust-governance-whitepaper.md ADR-008 + ZT overview brief L
13 modernization-governance-whitepaper.md Program Vision + Modernization Timeline L
14 scubagear-integration-whitepaper.md src/uiao/canon/adapter-registry.yaml (ScubaGear) M

Phase 4 — Executive Governance Series (9 chapters)

Why fourth: book-length narrative is the most expensive authoring. It should pull from all prior phases. Deliver in chapter order; publish incrementally rather than big-bang.

Order Chapter Est. effort
15–23 00-introduction/08-executive-summary/ in sequence L each; ~9L total

Phase 5 — Modernization Technical Specifications (7 pages)

Why fifth: cross-adapter domain specs. Each MTS is derived from the adapter registry plus domain-specific canon. Deliver alongside Phase 6 (validation suites) so every MTS has a paired MVS.

Order Domain Est. effort
24 _template/mts-generic-template.md S
25 identity/mts-identity.md M
26 cloud/mts-cloud.md M
27 zero-trust/mts-zero-trust.md M
28 telemetry/mts-telemetry.md M
29 sase/mts-sase.md M
30 sdwan/mts-sdwan.md M

Phase 6 — Modernization Validation Suites (7 pages)

Paired with Phase 5. Order matches: template → identity → cloud → zero-trust → telemetry → sase → sdwan.

Phase 7 — Case Studies (3 pages)

Why last: require shipped or late-stage-TARGET capability to make credible claims. Draft from real engagement material when available.

Order Study Est. effort
38 identity-modernization-case-study.md L
39 cloud-boundary-case-study.md L
40 federal-modernization-case-study.md L

Authoring contract

Every new customer-document page must:

  1. Carry canonical YAML frontmatter (metadata-validator CI gate).
  2. Cite its canon-source in frontmatter.
  3. Include an aspirational: true flag if the described capability is TARGET or DESIGN-ONLY per Substrate Status.
  4. Pass link-check (no broken internal or external references).
  5. Land in the same PR as any required updates to the parent section’s index.qmd (remove slug from “Planned pages” table once authored).

Effort key

  • S — ≤ 1 page of prose; ~half a day.
  • M — 2–4 pages; 1–2 days.
  • L — ≥ 5 pages or requires new diagrams / canon crosswalk; ≥ 3 days.

Tracking

File individual GitHub issues per page under label customer-docs-authoring, one phase at a time. Close when the page is merged into main and the corresponding Planned pages row is removed from the section index. (Last reviewed 2026-04-23)

Back to top