Digital Control Tower · Diversified industrial enterprise (placeholder client) · Phase 1 of 6

Phase 1 architecture pack

An executive decision-support application for repeated daily use. It answers four questions (Trust, Detect, Predict, Act) for three lenses (Owner, Core Group, Entity). This pack fixes the architecture, vocabulary, role model, KPI catalogue and synthetic scenario that every later phase reuses.

DRAFT v0.1 · FOR APPROVAL 2026-10-03 · NO VISUAL SCREENS IN PHASE 1 ALL NAMES, VALUES, THRESHOLDS: SYNTHETIC OR PLACEHOLDER

Pack index

Ten required Phase 1 deliverables plus three master references (R1–R3) that later phases must not fork. Open any card in Play or full view to jump to it.

TOUR
Guided tour · Primary business journey
10 steps from the Owner home to evidence-based closure, with what to notice at each step. Sign in as a persona; sign out from the header to switch.
TOUR
Guided tour · Data Assurance journey
8 steps from an untrusted KPI card to a human certification decision and the updated leadership view.
01
Product interpretation
What the Control Tower is, the four questions, the decision flow and the design stance. Below on this board.
02
Assumptions, unresolved decisions, conflicts
16 design assumptions, 23 decisions awaiting approval, 14 conflicts in the brief.
03
Personas and decision matrix
10 roles plus the AI boundary. 22 decisions mapped as Approve / Execute / Recommend / Consult / Inform; governance assignments; home route per role.
04
Architecture and sitemap
Layered architecture, object model, lens × navigation sitemap, hierarchy drill rules, templates.
05
Page inventory → templates
41 routes, each with business question, ≤6 primary KPIs, dominant visual, drill-downs, scenario state.
06
Visibility and action permissions
Data scope by role, 32 actions by role, 10 hard governance rules.
07
Supplier-delay journey
Signal → alert → ownership → materiality → Owner journey → evidence-based closure.
08
Number-assurance journey
KPI card → lineage → reconciliation break → workbench → human certification → updated view.
09
Component inventory and states
80 components, KPI card state model, provenance encoding, incident and non-happy-path states.
10
Risks of building before approval
14 risks with consequence, likelihood, impact and the gate that removes each.
11
Incident, case, war-room and AI specification
Added in v0.2: 22-field alert model, every incident block field by field, war-room mode, AI assistant specification, explanation model.
P2
Phase 2 · Greyscale low-fidelity application
Batch tracker for all 41 routes, the wireframe component kit and template skeletons. Batch 1: Owner lens.
R1
KPI catalogue placement
Every KPI in the brief with an ID: landing card, drill-down location, shared definitions.
R2
Requirement traceability matrix (v0.2 completeness check)
170 requirements across 12 coverage areas: theme, persona, route, template, treatment, status, open assumption. Corrections CX-01 to CX-09.
R3
Scenario bible, materiality, glossary
Master synthetic scenario facts, IDs and timeline, placeholder materiality model, controlled vocabulary.
Deliverable 01

Product interpretation

What it is

A role-governed decision-support system. For each lens it shows one defensible version of performance, what changed, what is likely to breach and when, and who is accountable for the response. Its working unit is a material issue moving to closure, not a chart.

Daily rhythm (Design assumption): Owner, 5–10 min (brief, change report, decisions). Core Group, daily portfolio scan plus period-close certification. Entity, several times a day (work queue, plants, certification).

What it is not

Not a departmental BI catalogue, a marketing site, a transaction system of record, a data-entry tool or an AI autopilot.

It reads from governed sources (all named as placeholders) and writes only decisions, ownership, actions, evidence, certifications and comments. Every write is audited.

The four questions → product capabilities

Question
Executive asks
The product answers with
Primary routes
Signature component
TRUST
Can I trust and defend the number?
A trust status on every value, kept separate from performance status. Approved definition, lineage, reconciliation, certification decision and evidence are one click away.
S-03 · G-08 · E-08
Trust badge · KPI detail
DETECT
What materially changed in the last 24 hours?
A change ledger ranked by materiality, leading signals by segment, and alerts carrying a fact / forecast / scenario label.
O-02 · S-12 · S-04
Change-ledger row
PREDICT
What is likely to happen, and when could a threshold be breached?
Prediction outputs (days to breach, probability of plan miss, projected gaps, covenant breach) plus scenario comparison. Always shown in the forecast style.
S-12 · S-06 · forecast panels
Days-to-breach clock
ACT
Who owns the response, what decision is required, and is it moving to evidence-based closure?
Ownership is accepted by a human. Actions have dependencies, escalation runs on a clock, war rooms are available, and closure is approved by a human.
O-06 · G-09 · E-09 · S-05 · E-10
Accountability strip

Core decision flow: which product object carries each step, and where AI stops

Each step is a real object in the application. The dashed box is what AI may do. The solid box is the human act that AI can never take.

01
Performance
KPI card on a governed definition
AI may
Detect variance, summarise
Human must
Certifier certifies the number
02
Deviation
Variance check → Alert record
AI may
Detect and flag deviation
Human must
Confirm it is real (validation)
03
Cause
Driver analysis · AI explanation
AI may
Explain with facts kept separate
Human must
Add business explanation
04
Business impact
Impact grid (11 dimensions)
AI may
Draft impact estimate
Human must
Validate impact
05
Forecast exposure
Forecast · days to breach
AI may
Project and compute days to breach
Human must
Own forecast assumptions
06
Materiality
Materiality score (placeholder logic)
AI may
Score against placeholder rules
Human must
Approve model and thresholds
07
Named human owner
Ownership panel
AI may
Recommend owner role
Human must
Accept ownership
08
Action
Action record · dependencies
AI may
Draft recommended actions
Human must
Accept, assign, execute
09
Escalation
Escalation clock and ladder
AI may
Draft escalation path
Human must
Escalate · intervene
10
Evidence
Evidence record · audit trail
AI may
Check completeness
Human must
Submit and attest evidence
11
Closure
Closure criteria · approval
AI may
Check criteria are met
Human must
Approve closure (never self)

Interpretation principles (binding on every phase)

P1
Two status axes, never merged
Business status (how it performs) and trust status (whether we can defend it) are separate badges. An untrusted number is never painted as a red poor result.
P2
Provenance on every value
Certified actual, preliminary actual, forecast, scenario, external signal and AI-generated each get their own tag and line style, never colour alone.
P3
Lens = depth, entitlement = scope
Switching lens changes how summarised the view is. It never widens what a person may see.
P4
One governed KPI, many contexts
Each KPI has one ID, definition and owner. Pages reuse the same component and add only decision context (see R1).
P5
Exception-led landing pages
At most six primary KPI cards per page. Every other catalogue measure sits in a named sub-theme drill-down.
P6
Accountability strip on every material issue
Severity, exposure, named human role, due date, escalation clock, evidence state and next action, always together.
P7
AI has a visible boundary
AI detects, summarises, explains, drafts, recommends and routes. Approval controls are human-only and never pre-filled by AI.
P8
Six templates, 41 routes
Every route uses one of templates A–F. No bespoke layout per page. Restricted and error states are patterns, not pages.

Delivery phases and approval gates

Phase
Output
Built on
Gate to proceed
1
Architecture pack (this canvas)
Brief
APPROVED 2026-10-03: all recommendations adopted; completeness check v0.2 done (R2)
2
Greyscale low-fidelity application (IN PROGRESS: see P2-00 tracker)
Templates A–F, page inventory 05, KPI placement R1
Template and content review by lens owners
3
Design system and high-fidelity screens
Component inventory 09, visual system in the brief
Accessibility contrast check, state coverage
4
Two connected prototype journeys
Journeys 07 and 08, scenario R3
Walkthrough with Owner and Core Group proxies
5
Formal audit and corrections
RTM R2, permissions 06
All critical and high findings closed
6
Presentation Mode frames
Audited screens
Management sign-off