UIAO Project Plans — The Internal Roadmap and the Agency Templates

roadmap
governance
canon
agency
oscal
Two kinds of project plan ship with UIAO: the internal roadmap driving substrate development, and the agency templates that take operators from empty clone to first OSCAL artifact.
Author

Michal Doroszewski

Published

April 17, 2026

TipFirst delivery shipped (2026-04-26)

Acme Federal modernization plan — synthetic but representative agency engagement plan instantiating the UIAO_127 template. See deliveries.qmd for future plans.

UIAO Project Plans — Roadmap & Templates

UIAO ships two kinds of project plan. They are not the same kind of thing, but they both live under the same canonical program spec: UIAO_127 — Project Plans Program.

The internal roadmap

The roadmap is the authoritative list of what the substrate will do next and why those priorities were chosen. It is versioned and ADR-anchored: every entry traces to an ADR that authorized it; every retired entry traces to an ADR that retired it. The roadmap is not a wishlist. A line item does not exist until an ADR says it does.

Cadence is quarterly planning increments, with weekly triage between. The release-drafter taxonomy (feature, fix, canon, docs, ci, dependencies, chore) is how items are categorized; the versioned draft release is how they roll up at the end of an increment.

Each roadmap item carries four fields: intent (what changes), canon touch (which docs / schemas / registries are affected), drift impact (new class, severity, or detector), and definition of done (blocking CI green + ADR link).

The agency templates

The templates are how an agency adopts UIAO without reinventing the deployment path. Four live today:

  • Greenfield adopt — agency standing up UIAO for the first time
  • Directory-migration modernization — the flow that absorbed GOS
  • SCuBA conformance rollout — M365 tenant through UIAO
  • OSCAL ATO preparation — SAR / POA&M / SSP production

Each template declares its preconditions, its canon inputs by version, its overlay configuration surface, its drift scan milestones, and its exit-criteria evidence bundle. Workspace root is always $UIAO_WORKSPACE_ROOT — never a hardcoded path.

Why both are canon

The roadmap and the templates are different, but they answer the same question: what work does the substrate authorize, and in what order? Keeping both as canonical artifacts means internal priorities and external deployment paths are drift-checked against the same governance rules. An agency that follows a template is following the same substrate definition the maintainers are building against.

Companion pages

  • Training — how contributors and operators learn
  • Test Plans — catalog of what tests govern what
  • Education — narrative-led onboarding
Back to top