Mission Control — Page Specifications

Companion to mission-control-blueprint.md § 5 (sitemap) and § 6 (content pipeline). Each page uses the same spec block. “Owner” is the role accountable for the page’s data being current (all commits go via the project team’s git workflow). Frequencies follow the cadence table in the blueprint.

Legend for sources: vault = file in this repo; telemetry = AI-platform metrics snapshot committed as data file; manual = human-entered data file (data/*.yaml|csv).

---

1. Home / Executive dashboard (/)

• Purpose: 60-second answer to “where is the program?” for the CEO.
• Users: CEO, steering; everyone lands here.
• Content blocks: overall RAG status; month-of-program marker; top 5 KPI tiles; next milestone + gate date; top 3 risks; decisions awaiting steering; latest weekly highlight.
• Update: weekly (data), continuous (decisions/risks). Owner: TPL program lead.
• Sources: aggregation of KPI data (data/kpi/*.yaml, manual/telemetry), ../02-program/risk-register.md, roadmap.
• KPIs shown: adoption (daily active users), KB coverage %, use cases in pilot/production, milestone on-time %, training completion %.
• Layout: KPI tiles top, milestone/decision cards mid, risk list bottom; single column on mobile.

2. Roadmap (/roadmap)

• Purpose: the M1–M12 plan and where we stand on it.
• Users: all authenticated.
• Content blocks: timeline (12 months, current month highlighted); phase descriptions; gate status per stage; changes since baseline.
• Update: at stage gates; narrative monthly. Owner: TPL program lead.
• Sources: vault — ../02-program/roadmap-12-month.md.
• KPIs shown: milestone on-time %.
• Layout: horizontal timeline top (scrollable container on mobile), phase accordions below.

3. Workstreams (/workstreams)

• Purpose: status per workstream (discovery, KB, platform, pilots, agents, training, change).
• Users: project team, steering.
• Content blocks: one status card per workstream — RAG, lead role, done-last-week, next, blockers.
• Update: weekly. Owner: each workstream lead; assembled by program lead.
• Sources: vault — workstream status notes under 02-program/.
• KPIs shown: per-workstream RAG; blocker count.
• Layout: card grid, RAG chip top-left of each card.

4. Milestones (/milestones)

• Purpose: milestone board with acceptance/gate state.
• Users: steering, project team.
• Content blocks: milestone table (name, stage, planned date, forecast, status, acceptance link); slipped-milestone callout.
• Update: at gates; forecast weekly. Owner: TPL program lead.
• Sources: vault — roadmap + stage acceptance records (../09-commercial/stage-offer-structure.md).
• KPIs shown: milestones done / total; slip days.
• Layout: status-filtered table, slippage banner above.

5. Department pages (/departments/<dept>, ×15)

• Purpose: each department head’s single view of “what the transformation means for us, and how we’re doing”.
• Users: that department’s head + steering; common template for all 15.
• Content blocks: readiness score + trend; active pilots/use cases; KB coverage for the department; training completion; open actions on the department; contacts (roles).
• Update: monthly (scores), weekly (pilots/actions). Owner: department champion, assembled by TPL consultant.
• Sources: manual data/readiness.csv; vault discovery notes (../03-discovery/requirement-analysis-framework.md); use-case pipeline filtered by dept; KB coverage export from vanos-brain.
• KPIs shown: readiness score, KB coverage %, training %, active use cases.
• Layout: score tile + sparkline top, pilot table mid, action list bottom.

6. Deliverables (/deliverables)

• Purpose: register of contractual deliverables and their acceptance state.
• Users: steering, project team.
• Content blocks: table — deliverable, stage, due, status (draft/submitted/accepted), acceptance note link.
• Update: continuous. Owner: TPL program lead.
• Sources: vault — deliverable register in 02-program/, stage definitions in ../09-commercial/stage-offer-structure.md.
• KPIs shown: accepted / total per stage.
• Layout: single wide table in scroll container, stage filter tabs.

7. AI infrastructure status (/ai-infrastructure)

• Purpose: is the platform up, used, and healthy.
• Users: all authenticated (summary); IT + project team (detail).
• Content blocks: deployment stage vs plan; health tiles (uptime, latency); usage (daily active users of ~50 target, queries/day, top departments); model/version notes; incidents.
• Update: weekly telemetry snapshot; incidents continuous. Owner: TPL platform engineer.
• Sources: telemetry snapshot committed to data/platform.yaml; vault — ../05-technical/architecture-overview.md, ../05-technical/rag-and-data-pipeline.md.
• KPIs shown: uptime %, DAU, queries/day, RAG citation rate.
• Layout: health tiles top, usage trend chart mid, incident log below.

8. Knowledge-base progress (/knowledge-base)

• Purpose: vanos-brain rollout and coverage — the garbage-in guardrail made visible.
• Users: all authenticated; knowledge manager especially.
• Content blocks: rollout phase per department (design/seeded/live); coverage matrix (processes %, SOPs %, FAQs %, freshness % per department); orphan/stale counts; gap-report highlights.
• Update: weekly (automated export from vanos-brain), monthly narrative. Owner: knowledge manager (PRIME PRODUCTS) with TPL consultant.
• Sources: coverage export from vanos-brain knowledge maps; vault — ../06-knowledge-base/obsidian-vault-blueprint.md.
• KPIs shown: KB coverage % (program KPI), approved-note count, gap-closure rate.
• Layout: coverage heat-map table (dept × dimension), rollout tracker strip above.

9. Risk register (/risks)

• Purpose: current risks, owners, mitigations.
• Users: steering, project team; heads see risks tagged to them.
• Content blocks: risk table (id, title, score, trend, owner role, mitigation, review date); top-risk detail cards; heat map.
• Update: continuous; formal review monthly. Owner: TPL program lead.
• Sources: vault — ../02-program/risk-register.md.
• KPIs shown: open risks by severity; overdue reviews.
• Layout: 5×5 heat map right, sortable table left/below.

10. Decision log (/decisions)

• Purpose: append-only record of program decisions; kills “who decided that?” debates.
• Users: all authenticated.
• Content blocks: reverse-chronological ADR list (number, title, date, status, one-line decision); pending-decision queue for steering.
• Update: continuous. Owner: TPL program lead.
• Sources: vault — 06-Decisions/ ADRs and program decision notes; governance per ../02-program/governance-model.md.
• KPIs shown: pending decisions count + age.
• Layout: pending queue banner top, decision list below.

11. Training calendar (/training)

• Purpose: what training runs when, for whom, and completion.
• Users: department heads, HR, all staff-facing.
• Content blocks: upcoming sessions calendar; completion by department; course catalog links; onboarding-path summary.
• Update: weekly. Owner: TPL change/training lead with HR.
• Sources: manual data/training.csv; vault training plan notes.
• KPIs shown: training completion % by department (program KPI).
• Layout: month calendar top, completion bar chart per department below.

12. Meeting notes (/meetings)

• Purpose: published steering/monthly meeting records — decisions and actions visible.
• Users: steering, project team; heads see meetings they attend.
• Content blocks: list by date; each note rendered with decisions and action table.
• Update: after each meeting (within 48h). Owner: meeting chair’s scribe (project team).
• Sources: vault meeting notes with publish: mission-control flag.
• KPIs shown: open actions count + overdue.
• Layout: date-grouped list, open-actions rollup card top.

13. KPI dashboard (/kpis)

• Purpose: the program’s measured truth — all KPIs with targets and trends.
• Users: steering, project team, heads.
• Content blocks: KPI tiles grouped by theme (adoption, knowledge, delivery, value); trend charts; definition popovers linking the framework.
• Update: monthly (some weekly). Owner: TPL program lead; reporting/BI counterpart validates.
• Sources: vault — ../02-program/kpi-framework.md (definitions); data/kpi/*.yaml (series: manual + telemetry).
• KPIs shown: all program KPIs.
• Layout: KPI tiles top by theme, trend sparkline in each tile, detail charts below.

14. Process transformation tracker (/process-transformation)

• Purpose: per-process progress from as-is documented → to-be designed → AI-augmented → live.
• Users: project team, department heads.
• Content blocks: process table (process, dept, stage, target month, linked use case); funnel summary.
• Update: weekly. Owner: TPL process consultant.
• Sources: vault process inventory from discovery (../03-discovery/requirement-analysis-framework.md); vanos-brain 03-processes/ status export.
• KPIs shown: processes documented %, processes AI-augmented count.
• Layout: stage-funnel strip top, filterable table below.

15. Requirement analysis status (/requirements)

• Purpose: live view of the requirements register — captured → validated → delivered.
• Users: project team, steering; heads see their department’s REQs.
• Content blocks: REQ table (id, title, dept, status, linked use case); status funnel; recently changed list.
• Update: continuous during discovery, then weekly. Owner: TPL discovery lead.
• Sources: vault — ../../02-Requirements/_index.md register.
• KPIs shown: REQ counts by status; validation rate.
• Layout: funnel chips top, register table below (dept filter).

16. Department readiness scores (/readiness)

• Purpose: comparable readiness across the 15 departments — where to push next.
• Users: steering, project team.
• Content blocks: readiness matrix (dept × dimension: data, process maturity, skills, adoption, sponsorship); overall score trend per department; methodology note.
• Update: monthly assessment. Owner: TPL change lead.
• Sources: manual data/readiness.csv; assessment notes in vault.
• KPIs shown: avg readiness, spread, most-improved.
• Layout: heat-map matrix center, per-dept sparklines right.

17. AI use-case pipeline (/use-cases)

• Purpose: the portfolio funnel — idea → assessed → pilot → production → retired.
• Users: steering, project team, heads.
• Content blocks: funnel counts; use-case cards per stage (title, dept, value estimate, next gate); recently promoted/killed.
• Update: weekly. Owner: TPL AI portfolio lead.
• Sources: vault — ../08-ai-portfolio/ai-use-case-pipeline.md.
• KPIs shown: count per stage, cycle time idea→pilot, value delivered (placeholder until measured).
• Layout: kanban-style stage columns (horizontal scroll on mobile), funnel chart top.

18. Agent deployment tracker (/agents)

• Purpose: which AI agents exist, where they run, and how they behave.
• Users: project team, IT, affected department heads.
• Content blocks: agent table (name, dept, status: spec/dev/pilot/production/paused, owner role, human-in-loop points); per-agent usage & incident mini-stats.
• Update: weekly; incidents continuous. Owner: TPL platform engineer.
• Sources: vault — ../08-ai-portfolio/ai-agent-registry.md; telemetry for usage.
• KPIs shown: agents in production, runs/week, incident count.
• Layout: status-grouped table, usage sparkline column.

19. Hardware & infrastructure status (/infrastructure)

• Purpose: procurement-to-production tracking of the on-prem hardware.
• Users: IT, project team, steering (summary).
• Content blocks: item tracker (component, status: ordered/delivered/racked/burn-in/live, ETA); capacity summary (GPU, storage headroom); dependency callouts to roadmap.
• Update: weekly until live, then monthly. Owner: TPL platform engineer with PRIME PRODUCTS IT.
• Sources: manual data/hardware.yaml; vault — ../05-technical/architecture-overview.md.
• KPIs shown: % components live; days to platform-ready.
• Layout: pipeline strip per component, capacity tiles below.

20. Budget & stage/offer tracking (/budget) — steering + project team only

• Purpose: commercial position per stage — contracted, invoiced, accepted (placeholders until commercial data agreed).
• Users: CEO/steering, TPL program lead. Not visible to heads or board tier.
• Content blocks: stage table (stage, status, fee model ”€[X]”, payment milestone state); pass-through hardware ledger; change-request log.
• Update: monthly and at gates. Owner: TPL program lead.
• Sources: vault — ../09-commercial/stage-offer-structure.md; manual data/budget.yaml.
• KPIs shown: stages accepted / total; open change requests.
• Layout: stage table top, hardware ledger below.

21. Board reporting (/board) — board tier + steering

• Purpose: the sanitized, self-serve board pack — replaces slide decks.
• Users: board, external stakeholders (read-only).
• Content blocks: quarterly narrative; top KPIs; milestone status; top risks (sanitized); investment summary at placeholder level.
• Update: monthly/quarterly. Owner: TPL program lead, approved by CEO.
• Sources: curated subset of dashboard + KPI + risk data, published via explicit publish: board flag.
• KPIs shown: headline 5 only.
• Layout: narrative top, KPI tile row, milestone timeline, risk summary — printable single page.

22. Change management updates (/change)

• Purpose: comms hub — what is changing for staff, when, and where to get help.
• Users: all authenticated; written for department heads to relay.
• Content blocks: update feed (dated posts); FAQ; champion network list (roles); feedback channel pointer.
• Update: weekly during rollout waves. Owner: TPL change lead.
• Sources: vault change/comms notes with publish flag.
• KPIs shown: none (qualitative page); optionally sentiment pulse when surveyed.
• Layout: feed left, FAQ + champions sidebar right.

23. Documentation index (/docs) & Project archive (/archive)

• Purpose: /docs — rendered map of all published vault documentation; /archive — closed phases, superseded reports, accepted-deliverable snapshots.
• Users: project team, steering; auditors at closure.
• Content blocks: auto-generated tree of published notes with type/status badges (/docs); phase-grouped archive list with acceptance dates (/archive).
• Update: automatic at each build (/docs); at gates (/archive). Owner: TPL program lead.
• Sources: build-time index of all publish:-flagged vault files.
• KPIs shown: none.
• Layout: two-level tree list with filter box.