vp console prd

ARGO VP Console Portfolio & Vehicle Operations Operational Oversight Atlas Web · 1440px desktop · Vehicle Operations / Maintenance Document 1 of 5 · Version 1.0 · Status: Draft for engineering handoff Owner: PM, Vehicle Operations MocX Smart Technologies Inc. · Confidential

1. Cover & Document Control

Field	Detail
Product & surface	Argo — VP Console (Atlas web, 1440px desktop)
Version	1.0
Status	Draft — implementation-ready, pending [VERIFY] items and stakeholder sign-off on Proposed Product Decisions
Owner	PM, Vehicle Operations
Intended audience	Product designer, frontend engineer, backend engineer, QA engineer, and data engineer building the VP Console; the VP (Osita) and their delegates as end users.
Source precedence	1) Explicit instructions for this document set · 2) latest Cowork conversation decisions · 3) Argo_PRD.docx (latest Argo PRD) · 4) Argo Field Flow Fixes spec · 5) Foundational Rework Brief & Gap Analysis · 6) Fault & Resolution Taxonomy · 7) existing Atlas HTML prototypes (behavioural/visual reference only).
Revision history	v1.0 — initial exhaustive draft, generated from the full Argo working context (see Section 21 for provenance).
Related Argo artefacts	Argo Shared Operating Model (internal spine); Argo_PRD.docx; Argo Field Flow Fixes Spec; Argo Foundational Rework Brief; Argo Gap Analysis & Redesign; Argo Fault & Resolution Taxonomy; Argo_Product_Manager_Console_PRD.docx; argo-head-of-maintenance-console-prd-v2.0.docx; Argo_Maintenance Supervisor_Web_Console_PRD.docx; Argo_Web_Console_Coverage_and_Reconciliation_Matrix.docx.

Contents

2. Executive Summary

The VP accountable for Vehicle Operations (and adjacent product lines) needs one place to know, every week, where to spend attention, what is at risk, what needs a VP-level decision, and whether the fleet is trending toward or away from its reliability targets. Today that picture is assembled by hand from PM and Head of Maintenance reports; it arrives late, is inconsistent between weeks, and gives no durable record of what was decided and why. The VP Console exists to make that picture live, reconciled, and decision-actionable: a portfolio scorecard rolling up every product the VP is accountable for, a Vehicle Operations drill-in built from the same data the PM and Head of Maintenance Consoles use, a Decisions Queue that turns “should we approve this” into a durable, audited record, a Risk Register that survives past the meeting it was raised in, and a Weekly Business Review builder that produces a signable artefact instead of a slide deck assembled from screenshots. Decisions this surface enables: approve or reject campaigns and roadmap commitments that cross the Head of Maintenance/PM approval threshold (Argo Shared Operating Model §4.5); accept or escalate fleet risks; approve resourcing/capacity changes; sign off the weekly business review. Success looks like: the VP can prepare the WBR and clear the week’s queued decisions entirely from this console, with zero screenshots, zero manually-reconciled numbers, and a full audit trail of every decision made.

3. Persona & Operating Context

3.1 Responsibilities

• Own operational and reliability health across the product portfolio the VP is accountable for, with Vehicle Operations as the deepest, most reliability-critical line.
• Make the calls that require cross-product or above-Head of Maintenance authority: campaign/roadmap approval past the routing threshold, risk acceptance, resourcing trade-offs.
• Run the Weekly Business Review — the durable, signed record of “what happened, what we decided, what’s next.”

3.2 Working cadence

Weekly (the WBR cadence) and quarterly (roadmap/resourcing checkpoints tied to the PM Console’s quarterly review). The VP checks the console most mornings for anything that newly crossed into the Decisions Queue or Risk Register, and does a deeper pass before the WBR.

3.3 Primary jobs to be done

• “Is anything on fire this week that I need to personally weigh in on?” → Executive Home + Decisions Queue.
• “How healthy is Vehicle Operations relative to our targets, and is it improving?” → TH drill-in + Weekly operating health.
• “What are we exposed to, and who owns fixing it?” → Risk Register.
• “Do we have the bay/technician capacity for what’s coming?” → Resourcing & capacity.
• “What do I need to approve or reject before it stalls the team?” → Decisions Queue → Decision detail.
• “What’s the signed record of this week, for my boss and for the file?” → Weekly Business Review builder.

3.4 Decisions made here

• Approve / reject / conditionally-approve a campaign or roadmap commitment routed for VP sign-off.
• Accept, escalate, or assign an owner to a fleet risk.
• Approve or flag a resourcing/capacity change (e.g., add a bay, reallocate technicians).
• Sign off the Weekly Business Review.

3.5 Inputs received

• Fleet-ready %, VRI distribution, and cohort risk from the shared reliability model (Argo Shared Operating Model §5).
• Campaign and roadmap-commitment approval requests from the Head of Maintenance Console and PM Console.
• Risks raised by Head of Maintenance and PM (withdrawal spikes, supplier issues, capacity conflicts).

3.6 Outputs produced

• Signed decisions that unblock or halt downstream work (a campaign cannot roll out past its routed approval gate without one).
• A published, versioned Weekly Business Review.
• Risk acceptances/mitigations with owners and target dates.

3.7 Pressure points

• Decisions arrive with incomplete evidence and the VP has no time to chase the PM/Head of Maintenance for it — the console must show evidence inline, never require a side conversation.
• Numbers that don’t reconcile between what Head of Maintenance reports and what the VP sees erode trust in the whole system fast.

3.8 What this role explicitly cannot do

• Cannot operate a Work Order, validate a repair, manage bay stock, promote/merge/reject a taxonomy code, or perform PM-grade cohort analysis. The VP Console has read/drill-down access into PM and Head of Maintenance evidence but never exposes their operational controls.
• Cannot bypass the campaign approval routing rule (Argo Shared Operating Model §4.5) — a campaign under the Head of Maintenance only threshold never appears in this queue and cannot be pulled into it retroactively; it can only be viewed read-only via drill-in.

4. Goals, Non-Goals & Measurable Success Criteria

4.1 Product outcomes

• 100% of campaigns/roadmap items requiring VP sign-off (per the routing rule) are visible in the Decisions Queue within one refresh cycle of being routed.
• Zero VP decisions made without the evidence packet or supporting data visible inline in the console.

4.2 Operational outcomes

• Median time-to-decision (queued → decided) under 3 business days for non-emergency decisions.
• Weekly Business Review production time reduced from a manual multi-hour assembly to under 30 minutes of VP review/edit time.

4.3 Adoption & usability outcomes

• VP completes a full WBR cycle (build → preview → sign-off → export) without leaving the console.
• Zero instances of the VP requesting a number by side-channel (Slack/email) because it wasn’t visible in-console.

4.4 Data-quality outcomes

• 100% reconciliation between VP-displayed fleet-ready %, VRI distribution, and campaign status and the same figures shown in the Head of Maintenance and PM Consoles, verified by the cross-surface reconciliation tests in Section 20.

4.5 Explicit non-goals

• Not a work-order operations tool. Not a cohort-analytics workbench (that’s the PM Console). Not a taxonomy governance tool (that’s Head of Maintenance-exclusive). Not a cross-company CPO-level strategy tool (out of scope for this pass; referenced only as an upstream consumer of VP roll-ups).

5. Role, Permission & Authority Model

Action	VP	VP delegate (Chief of Staff)	Server-enforced rule
View portfolio scorecard, TH drill-in, risk register	Full	Full	Read-only for both; no write path exists on these views.
Approve / reject a routed Decision	Full	None (view + comment only)	Only a user with role=VP (or explicit acting-VP delegation, see 5.1) can submit an approve/reject/conditional transition; all other roles receive 403.
Accept / escalate / reassign a Risk	Full	Full (VP delegate has risk-tier write access)	Requires role ∈ {VP, VP_DELEGATE}.
Build / edit a WBR draft	Full	Full	Draft is co-editable; only the VP can execute Sign-off (below).
Sign off a WBR (publish)	Full	None	Sign-off is a VP-only, non-delegable action — it is a personal attestation, not an operational task.
Export a report / decision record	Full	Full	Export events are always audit-logged with actor + timestamp (Section 16 export protection).
Change Console settings (default views, notification prefs)	Full (own)	Full (own)	Per-user settings; no admin override of another user’s personal settings.

5.1 Delegation and acting-role behaviour

The VP may designate a time-boxed “acting VP” delegate (e.g., during travel) with full approval authority for the delegation window. Delegation is itself an audited action (who delegated, to whom, effective window) and is visible as a banner on every VP Console screen while active (“Acting for Osita, through 14:00 Fri”). WBR sign-off cannot be delegated even during an active delegation window — if the VP is unreachable, the WBR remains in DRAFT until they return or a named backup VP (a distinct real role, not a delegate) signs it.

5.2 Multi-bay and multi-role behaviour

Not applicable at this altitude — the VP Console has no bay-scoped view; all data is pre-aggregated to portfolio/product/TH-wide altitude. A VP accountable for multiple product lines sees each as a scorecard row and can pin a default landing product (Section 13).

5.3 Audit requirements

• Every Decision transition (approve/reject/conditional/withdraw/supersede) is logged with actor, timestamp, evidence snapshot reference, and comment.
• Every WBR sign-off is logged with a content hash of the signed version, so a later edit cannot silently alter a “signed” review.

5.4 Forbidden actions and expected error responses

• A non-VP, non-delegate attempting to approve a Decision receives a 403 with message “Only the VP or an active acting-VP delegate can approve this decision.”
• Any attempt to edit a signed WBR in place is rejected (409 Conflict); the system instead creates a new draft version referencing the signed one.

6. Complete Information Architecture

Full sidebar map, in order:

• Executive Home — /vp/home
• Portfolio — /vp/portfolio (heat-grid) → /vp/portfolio/:productId (product drill-in)
• Vehicle Operations — /vp/th (drill-in home) → /vp/th/cohorts/:cohortId (read-only, deep link into PM Console’s cohort detail) → /vp/th/campaigns/:campaignId (read-only, deep link into Head of Maintenance rollout board)
• Weekly Operating Health — /vp/health
• Decisions — /vp/decisions (queue) → /vp/decisions/:decisionId (detail)
• Risk — /vp/risk (register) → /vp/risk/:riskId (detail & mitigation tracking)
• Resourcing — /vp/resourcing (capacity roll-up)
• Reviews — /vp/reviews (history) → /vp/reviews/new (WBR builder) → /vp/reviews/:reviewId (preview/detail) → /vp/reviews/:reviewId/export
• Notifications — /vp/notifications (centre)
• Settings — /vp/settings (saved views, notification preferences, delegation management)

Figure 1 — VP Console sitemap.

6.1 Cross-surface deep links

• TH drill-in cohort rows deep-link to the PM Console’s Cohort Detail page (read-only view; VP sees the same evidence a PM sees, cannot edit).
• TH drill-in campaign rows deep-link to the Head of Maintenance Console’s Campaign Rollout Board (read-only).
• A Decision detail’s evidence section deep-links to the originating Evidence Packet (Maintenance Supervisor Web Console) or Engineering-Feedback Item (PM Console) where applicable.

6.2 Back-navigation, breadcrumbs, saved views

Breadcrumb pattern: Argo / VP Console / {section} / {sub-page}. Back-navigation always returns to the last filtered/scrolled state of the prior list (state preserved in-session, not just route history). Saved views (Section 13) apply to Portfolio, Risk Register, and Decisions Queue — each persists filter/sort/facet state per user, with a “Default view” flag settable per list.

6.3 Command palette (⌘K) destinations and actions

• Navigate to any of the 9 routes above by name.
• Jump to a specific Decision, Risk, or Review by ID or free-text title match.
• Quick action: “New risk” (opens Risk creation drawer from anywhere).
• Quick action: “Start WBR” (opens the builder for the current week if not already started).

7. Complete Page Inventory

7.1 Executive Home

Purpose: answer “what needs my attention this week” in under 60 seconds. Entry points: default landing route, notification deep links, ⌘K. Exit points: every module’s row/card links to its full page.

Layout, in visual order

• Header band: portfolio-wide Fleet-Ready %, VRI distribution mini-donut, open S1 count, decisions-awaiting-VP count — each a count-up KPI tile with a 7-day sparkline and a RAG-coloured left border.
• Portfolio heat-grid (signature module) — see 7.2 for full spec; embedded here as a condensed 2-row view (top 2 products by attention-needed), “View full heat-grid ›” link to 7.2.
• This week’s decisions (top 5 by urgency) — condensed Decisions Queue rows; “View all N ›” to 7.5.
• Risk highlights (top 3 by trend-worsening) — condensed Risk Register rows; “View register ›” to 7.6.
• Weekly operating health snapshot — the same chart set as 7.4, condensed to the primary trend line only, “Full view ›”.
• Activity feed — chronological list of the last 20 cross-surface events relevant to VP altitude (a campaign was approved by Head of Maintenance and now awaits VP; a risk crossed into Critical; a WBR was published) with relative timestamps and deep links.

States

• Loading: skeleton shimmer on every KPI tile and module (matches canonical .id-empty-state/skeleton pattern from the design system).
• Empty: not applicable to KPI tiles (always populated from the spine); the activity feed shows a canonical empty state (“No activity in the last 7 days”) only in a demo/new-tenant condition.
• Error: inline retry banner per module if its data source times out; other modules continue to render independently (partial-failure isolation, not a full-page error).
• Stale: any KPI computed more than 2× its refresh interval ago shows a small “stale — refreshed {t}” tag rather than silently showing old data as current (Section 16 staleness budget).

Side effects, events, acceptance

• No write actions on this page; every control navigates. Acceptance: page fully paints (all modules populated or explicitly stale/error-tagged) within the performance budget (Section 16) on the shared reliability data as of the last refresh.

7.2 Portfolio Heat-Grid (signature module)

Purpose: show every product the VP is accountable for as a row, scored across reliability, open-S1, SLA adherence, trend, and RAG — so the VP can see at a glance which product needs attention this week.

Fields & columns (table spec — every column explicit, not “standard table behaviour”)

• Product name (mono-weight link to /vp/portfolio/:productId).
• Reliability score — the product’s own headline reliability metric (for Vehicle Operations: Fleet-Ready %; other products’ equivalents are configured per-product, since this pass does not define non-hardware products’ metrics — logged as [VERIFY] pending which other products report into this console).
• Open S1 count — critical/safety-severity open issues, red badge if > 0.
• SLA adherence % — rolling 7-day median time-to-resolve vs the product’s target, shown as a delta (+/− hours).
• 7-day trend sparkline — reliability score over the last 7 days.
• RAG status — computed: Red if any open S1 or SLA breach > 20%; Amber if trend is worsening for 3+ consecutive days; Green otherwise. The exact computation is shown on hover (“Why Red?” tooltip listing the triggering condition).
• Row action: “Drill in ›” — for Vehicle Operations, routes to /vp/th; for other products, to their own product drill-in page (out of scope to fully spec here, but the row and route must exist and not dead-end — placeholder-free requirement satisfied by routing to a genuine, even if minimal, product drill-in shell).

Sort, filter, states

• Sortable by any column; default sort is RAG (Red first) then reliability score ascending.
• Filter: by RAG status (multi-select), by product family.
• Loading: skeleton rows. Empty: not applicable (VP is always accountable for ≥1 product). Error: inline retry per row’s data source.

Acceptance criteria

• Every row’s RAG status recomputes within one refresh cycle of any underlying metric change; hovering “Why Red?” always shows the specific triggering rule, never a generic label.

7.3 Vehicle Operations Drill-In

Purpose: the VP’s one-click deep view into Argo without recreating the PM/Head of Maintenance working surfaces. Entry: heat-grid row, sidebar. Exit: deep links to PM/Head of Maintenance read-only detail pages.

Modules, in order

• Header KPI band: Fleet-Ready %, VRI band distribution (stacked bar: Healthy/Watch/At-risk/Critical/Unknown, per the shared reliability model, Argo Shared Operating Model §5), median time-to-resolve, Cost of Poor Quality (both components broken out per §5.2 of the operating model), immobilised count.
• Critical cohorts table — top cohorts by recurrence rate approaching or past the 15% intervention threshold; columns: cohort name, type, recurrence rate, trend, linked code, “View in PM ›” (deep link to PM Console Cohort Detail, read-only).
• Supplier risk panel — cohorts grouped by supplier factor, flagged if recurrence trend is worsening across ≥2 cohorts sharing that supplier.
• Open critical faults & withdrawals — table of all open S1 WOs and all vehicles currently withdrawn, with days-open and a “View in Head of Maintenance ›” deep link (read-only WO detail).
• Campaign & roadmap approvals awaiting VP — condensed Decisions Queue filtered to Tricycle-Hardware-origin items; “View all in Decisions ›”.

Chart definitions

• VRI stacked bar: numerator = vehicle count per band; denominator = active fleet (withdrawn excluded, per Argo Shared Operating Model §5.1); refresh: on every console load, cached 15 minutes; drill-down: clicking a band segment filters the Critical Cohorts table to cohorts contributing to that band’s worst-offending vehicles.
• Cost of Poor Quality: two stacked components (rider-days-lost value, direct repair spend) per Argo Shared Operating Model §5.2 — never shown as a single blended number without the breakdown available on hover/click.

States & acceptance

• Empty state for “Open critical faults” reads “No open S1 faults — fleet is clear” (a genuine, checkable claim, not decorative).
• Acceptance: every number on this page reconciles exactly with the equivalent number in the Head of Maintenance Console and PM Console at the same instant (cross-surface reconciliation test, Section 20).

7.4 Weekly Operating Health

Purpose: the trend view underlying the WBR — is Vehicle Operations (and the rest of the portfolio) improving week over week.

Modules

• 13-week trend lines (brushable, hover crosshair): Fleet-Ready %, median time-to-resolve, cohort recurrence (aggregate), COPQ — small-multiples row, each independently zoomable.
• Week-over-week deltas table: this week vs last week vs 4-week average, for every headline metric, with directional arrows and colour (green improving, red worsening per the metric’s stated direction from Argo_PRD.docx §3.3).
• Notable events this week — auto-generated list (campaign completed, cohort crossed threshold, risk opened/closed) sourced from the cross-surface event log.

Acceptance

• Every trend line’s data points are individually hoverable showing exact value + date; brush-zoom persists across a session but resets on hard reload (documented, not silent).

7.5 Decisions Queue & Decision Detail

Purpose: turn every VP-routed approval into a durable, evidenced, auditable record. This is the console’s most consequential workflow surface.

Queue page — columns

• Decision title (e.g., “Approve Campaign: Bundle R2 gear replacement”).
• Type (Campaign / Roadmap item / Withdrawal / Resourcing).
• Submitted by (PM or Head of Maintenance name) + submitted date.
• Why VP approval is required — the specific routing-rule trigger (scope > 25 vehicles / cost threshold / safety-critical / extended withdrawal), per Argo Shared Operating Model §4.5, always shown as an explicit tag, never implied.
• Age (days in queue) with an amber tag past 3 business days, red past 7.
• Status (Awaiting decision / Approved / Rejected / Conditionally approved / Withdrawn / Superseded).

Decision Detail page — every field specified

• Header: title, type, submitter, submission date, routing-rule trigger tag.
• Evidence panel — inline, not a link-out: for a Campaign, the full campaign definition (objective/hypothesis, scope, intervention package, parts/capacity plan, rollout dates) per Argo Shared Operating Model §4.2, plus a deep link to the live Head of Maintenance rollout-board preview; for a Roadmap item, the linked Engineering-Feedback Item and its evidence packet, deep-linked to the PM Console (read-only).
• Impact preview — projected effect on Fleet-Ready %, COPQ, and affected cohort recurrence, computed the same way the PM Console’s impact modelling computes it (shared formula, not a separate VP-side estimate).
• Decision panel: permitted decisions are Approve, Reject, Approve with conditions (free-text condition, required), Request more evidence (routes back to submitter with a note, does not consume the decision). A comment field (optional unless rejecting or conditioning, in which case required).
• Downstream state changes: Approve → the linked Campaign/Roadmap item transitions to its next lifecycle state (Campaign: PROPOSED → APPROVED, unlocking Head of Maintenance rollout) and an event is emitted to the originating console. Reject → the item returns to the submitter as REJECTED with the VP’s comment attached, terminal unless resubmitted as a new item. Approve with conditions → APPROVED_WITH_CONDITIONS, visible to Head of Maintenance/PM with the condition text pinned to the top of their working view of that item.
• Withdraw / supersede: the VP may withdraw their own prior decision within 24 hours (reverts the downstream item to its pre-decision state and notifies the submitter) or supersede it with a new decision referencing the old one (both remain in history, never deleted).
• Audit trail: every state change on this record, with actor/timestamp, rendered as a vertical timeline at the bottom of the page.

Notification behaviour

• On Approve/Reject/Condition: notifies the submitter (PM or Head of Maintenance) with a deep link back to the specific item, not a generic “a decision was made” message.
• On aging past 3/7 days: notifies the VP (escalating urgency tag) — this is the mechanism that prevents queue rot.

States & acceptance

• Empty queue state: “No decisions awaiting you” (genuine, not decorative — verified against the live queue count).
• Acceptance: an Approve action is rejected (with inline error) if the evidence panel failed to load — a decision can never be submitted against a broken/partial evidence view; this is enforced client- and server-side.

7.6 Risk Register & Risk Detail

Purpose: track fleet/portfolio risks that survive past the meeting they were raised in, with owners and mitigation status.

Register page — columns

• Risk title, category (Cohort / Supplier / Capacity / Telemetry-dark fleet / Withdrawal spike / Other), severity (High/Med/Low — a VP-scale severity distinct from the S1–S4 fault severity, since a risk is a business concern, not a fault instance), owner, status (Open / Mitigating / Accepted / Closed), trend (worsening/stable/improving), age.

Risk Detail — every field

• Description, category, severity, linked evidence (e.g., the specific cohort(s) or the withdrawal-count trend that triggered it, per Argo Shared Operating Model §7 fallout rule for withdrawal-spike risks).
• Owner (assignable to VP, VP delegate, or — read-only reference — the Head of Maintenance or PM who is operationally responsible).
• Mitigation plan: free-text plan, target date, status (Not started / In progress / Done), progress notes log (append-only, timestamped).
• Actions: Accept risk (with required justification note — becomes a permanent, visible record of “we knew and chose to accept this”), Escalate (creates a linked Decision in the Decisions Queue if the mitigation requires VP-level resourcing/approval), Close (requires mitigation status = Done or an acceptance justification).

States & acceptance

• A risk auto-created from crossing a threshold (e.g., withdrawal spike per Argo Shared Operating Model §7) always includes the triggering data snapshot inline, never just a label.
• Acceptance: closing a risk without either a Done mitigation or an acceptance justification is blocked client- and server-side with an explicit validation message.

7.7 Resourcing & Capacity

Purpose: fleet/bay capacity vs demand roll-up, read-only aggregation of the Head of Maintenance Console’s per-bay capacity data (Argo Shared Operating Model §4.4 due-load/capacity-conflict rule), for VP-level hire/deprioritize signal.

Modules

• Capacity vs demand chart, portfolio-wide: rostered technician-hours vs forecast load (schedules + campaigns + backlog), stacked by bay, brushable over the next 8 weeks.
• Capacity-conflict list: bays flagged by the Head of Maintenance Console’s conflict-detection rule, with days-until-conflict and a “View in Head of Maintenance Scheduler ›” deep link.
• Resourcing signal panel: a computed hire/deprioritize suggestion (“Bay 3 trending toward sustained >110% load for 4+ weeks — consider adding 1 technician”) — always shown with its triggering data, never as an unexplained recommendation.

Acceptance

• Every capacity number reconciles exactly with the Head of Maintenance Console’s own capacity roll-up (same underlying rosters and forecast rule).

7.8 Weekly Business Review Builder, Preview, Sign-Off, Export

Purpose: produce the signed, exportable weekly artefact directly from live console data — no manual slide assembly.

Builder — step by step

• Start: “Start WBR” creates a DRAFT for the current ISO week (one per week; starting again on an existing week’s draft resumes it, never creates a duplicate).
• Auto-populated sections (editable text overlay, data is always live-pulled, never hand-typed): Portfolio heat-grid snapshot, TH weekly operating health trend, Decisions closed this week (with outcomes), Risk register changes this week, Resourcing signal summary.
• VP (or delegate) adds narrative commentary per section (rich text) and can pin/unpin specific rows (e.g., highlight one cohort by name) into the review.
• Preview: renders the full review as it will export, with all data re-fetched live at preview time (so a preview taken Monday and reviewed Wednesday shows Wednesday’s numbers, clearly timestamped “as of”).
• Sign-off: VP-only action (Section 5). On sign-off, the review’s content and data snapshot are hashed and frozen — the SIGNED version never changes even if underlying data later changes; a re-open creates a new draft version instead.
• Export: PDF and DOCX, both with the same restrained Argo visual system as this document set; export always includes the “as of” timestamp and the VP’s signature block (name, date, hash reference).

History

• Reviews list shows every past week’s review with status (Draft/Signed), signer, and a diff-vs-prior-week link on key metrics.

States & acceptance

• Attempting to sign a review with an empty or auto-population-failed section is blocked with an inline error identifying the failed section — a WBR can never be signed with silently-missing data.

7.9 Notification Centre

Purpose: durable, deep-linkable record of every notification per Argo Shared Operating Model §6 (generic contract), scoped to VP-relevant event types: decision routed/aging, risk auto-created/escalated, WBR reminder, campaign/roadmap state change on an item the VP previously decided.

• List columns: type icon, message (always naming the specific record), relative time, read/unread dot, deep link.
• Bulk action: mark all read. Row action: mark read, open (deep link), snooze (re-surfaces in 24h).
• Empty state: “You’re caught up.”

7.10 Settings

• Saved views management (rename/delete/set-default) for Portfolio, Risk Register, Decisions Queue.
• Notification preferences (channel toggles per event type, subject to the platform’s actual available channels — [VERIFY] transport, Argo Shared Operating Model §0.1 VERIFY-3).
• Delegation management (create/end an acting-VP window, per Section 5.1).
• Default landing product (which portfolio row the VP sees first).

8. Functional Requirements

VP-FR-001 — Approve a routed Decision

The VP can approve a Campaign, Roadmap item, Withdrawal, or Resourcing request routed to the Decisions Queue.

• Actor: VP (or active acting-VP delegate)
• Preconditions: Decision exists in status Awaiting decision; evidence panel loaded successfully.
• Trigger: VP clicks Approve on Decision Detail.
• Happy path: System validates evidence is loaded, VP confirms in a lightweight confirmation dialog (not a full modal form — this is a single-click-plus-confirm action), decision transitions to Approved, downstream item transitions per its own lifecycle, submitter notified.
• Alternate paths: VP clicks Approve with conditions instead → requires a condition note → transitions to Approved with conditions.
• Validation: Evidence panel must have loaded without error; a comment is optional on plain Approve.
• Permission rule: role ∈ {VP, ACTING_VP_DELEGATE}; all others 403.
• State transition: Decision: Awaiting decision → Approved. Downstream Campaign: PROPOSED → APPROVED (or equivalent for Roadmap/Withdrawal/Resourcing types).
• Data side effects: Decision record updated with actor, timestamp, comment. Downstream entity’s status field updated in the shared spine (visible immediately in Head of Maintenance/PM consoles).
• Notification side effects: Submitter (PM or Head of Maintenance) notified with deep link to the now-approved item.
• Downstream surface effects: Head of Maintenance Console: an approved Campaign can now enter ROLLING_OUT. PM Console: an approved Roadmap item becomes committed.
• Failure & recovery: If the downstream transition fails server-side (e.g., a race with a concurrent submitter edit), the Decision itself remains Approved but flags a reconciliation error visible to VP and submitter, with a retry action.
• Acceptance criteria: An approved Decision is reflected in the Head of Maintenance/PM console’s own view of that item within one refresh cycle; the Decision’s audit trail shows exactly one Approved entry with correct actor/timestamp.

VP-FR-002 — Reject a routed Decision

The VP can reject a routed Decision with a required comment.

• Actor: VP (or active acting-VP delegate)
• Preconditions: Decision exists in status Awaiting decision.
• Trigger: VP clicks Reject on Decision Detail.
• Happy path: System requires a non-empty comment, decision transitions to Rejected, downstream item transitions to its own Rejected/terminal state, submitter notified with the comment.
• Alternate paths: None — Reject always requires a comment; there is no bare reject.
• Validation: Comment field is required and must be non-empty.
• Permission rule: role ∈ {VP, ACTING_VP_DELEGATE}.
• State transition: Decision: Awaiting decision → Rejected (terminal unless resubmitted as a new item by the submitter).
• Data side effects: Decision record updated; downstream Campaign/Roadmap/Withdrawal/Resourcing item’s status updated to reflect rejection.
• Notification side effects: Submitter notified with the VP’s comment and a deep link.
• Downstream surface effects: Head of Maintenance/PM console shows the item as rejected with the VP’s stated reason visible inline, not just a status flip.
• Failure & recovery: None — rejection is a terminal, low-risk transition; no special failure mode beyond standard save-failure retry.
• Acceptance criteria: A rejected item cannot be re-approved without a new submission; the audit trail shows the rejection reason.

VP-FR-003 — Withdraw or supersede a prior Decision

The VP can withdraw their own decision within 24 hours, or supersede it with a new decision at any time.

• Actor: VP only (not delegable — a delegate cannot undo the VP’s own decision).
• Preconditions: Decision is in a terminal state (Approved/Rejected/Approved with conditions); for Withdraw, within 24 hours of the original decision timestamp.
• Trigger: VP clicks Withdraw or Supersede on a decided item’s detail page.
• Happy path: Withdraw: downstream item reverts to its pre-decision state (e.g., Campaign back to PROPOSED), submitter notified of the reversal with reason. Supersede: a new Decision record is created referencing the old one; old record is marked Superseded (retained, not deleted); new record follows VP-FR-001/002.
• Alternate paths: Attempting Withdraw past 24 hours is blocked; VP must use Supersede instead.
• Validation: 24-hour window is server-enforced on Withdraw; Supersede has no time limit.
• Permission rule: role = VP exactly (no delegate).
• State transition: Approved/Rejected → Withdrawn (reverts downstream) or Superseded (chains to a new Decision).
• Data side effects: Full history retained on both the old and new Decision records; downstream entity status updated accordingly.
• Notification side effects: Submitter notified in both cases with the reason and a deep link.
• Downstream surface effects: Downstream console reflects the reversal or the new decision within one refresh cycle.
• Failure & recovery: If the downstream item has already progressed past a reversible point (e.g., a Campaign already fully rolled out), Withdraw is blocked with an explicit “this can no longer be withdrawn” message directing the VP to Supersede or open a new Decision instead.
• Acceptance criteria: A withdrawn decision’s downstream item is verifiably back in its pre-decision state; a superseded decision chain is fully traceable end to end.

VP-FR-004 — Accept a Risk

The VP can formally accept a risk, creating a permanent record of an informed choice not to mitigate further.

• Actor: VP or VP delegate.
• Preconditions: Risk exists in status Open or Mitigating.
• Trigger: VP clicks Accept risk on Risk Detail.
• Happy path: System requires a justification note, risk transitions to Accepted, remains visible in the register (not archived) with an “Accepted” badge and the justification pinned.
• Alternate paths: None — acceptance always requires the justification note.
• Validation: Justification note required, non-empty.
• Permission rule: role ∈ {VP, VP_DELEGATE}.
• State transition: Risk: Open/Mitigating → Accepted.
• Data side effects: Risk record updated with actor, timestamp, justification.
• Notification side effects: None required by default; risk owner (if different from VP) is informed via the standard event log.
• Downstream surface effects: Accepted risks remain visible in the VP Risk Register indefinitely (or until manually closed) and are referenced from the next WBR’s risk section automatically.
• Failure & recovery: None special.
• Acceptance criteria: An accepted risk shows its justification prominently everywhere it’s displayed, never silently disappears from the register.

VP-FR-005 — Build, preview, and sign off the Weekly Business Review

The VP produces a live-data WBR and signs it into an immutable record.

• Actor: VP (build/preview: VP or delegate; sign-off: VP only).
• Preconditions: Current ISO week’s WBR is in Draft (or not yet started).
• Trigger: VP navigates to Reviews → New (or resumes existing draft).
• Happy path: Sections auto-populate from live data; VP adds narrative; VP previews (live re-fetch); VP signs off, freezing a hashed snapshot; VP exports PDF/DOCX.
• Alternate paths: Delegate builds/edits the draft but cannot sign; sign-off waits for the VP.
• Validation: All auto-populated sections must have loaded successfully before Sign-off is enabled (button is disabled, not just unvalidated, until every section is populated).
• Permission rule: Build/preview: role ∈ {VP, VP_DELEGATE}. Sign-off: role = VP only.
• State transition: Review: Draft → Signed (immutable). A new edit after signing creates Draft v(n+1) referencing the signed version.
• Data side effects: Signed review stores a content hash + full data snapshot; never mutates after signing.
• Notification side effects: None required for a normal sign-off; a reminder notification fires if no draft exists by Thursday of the review week (configurable day).
• Downstream surface effects: None — this is a terminal artefact for the week, referenced read-only elsewhere (e.g., PM Console’s own quarterly review may cite prior WBRs).
• Failure & recovery: If a section’s data source fails during Preview, Sign-off remains disabled and the specific failed section is flagged inline; VP can retry or exclude that section with an explicit “data unavailable” marker (never silently omitted).
• Acceptance criteria: A signed WBR’s exported PDF/DOCX exactly matches the previewed content at sign-off time, verified by hash.

9. Entity & Lifecycle Definitions

The VP Console consumes, but does not own, the core Argo entities (Work Order, Case, Cohort, Campaign — full definitions in the Argo Shared Operating Model, Sections 2 and 4, reused verbatim and not restated here to avoid drift). It owns three entities outright:

9.1 Decision (VP-owned)

Status	Entry condition	Exit condition	Set by
Awaiting decision	Routed per Argo Shared Operating Model §4.5 routing rule.	VP acts, or item withdrawn by submitter before decision.	System (routing) / submitter
Approved	VP approves.	Terminal, unless later Withdrawn (≤24h) or Superseded.	VP / acting-VP delegate
Approved with conditions	VP approves with a condition note.	Terminal, unless later Withdrawn/Superseded.	VP / acting-VP delegate
Rejected	VP rejects.	Terminal, unless Superseded.	VP / acting-VP delegate
Withdrawn	VP withdraws within 24h of Approved/Rejected.	Terminal.	VP only
Superseded	VP creates a new Decision referencing this one.	Terminal.	VP only

9.2 Risk (VP-owned register of record)

Status	Entry condition	Exit condition	Set by
Open	Manually raised, or auto-created by threshold breach.	Owner begins mitigation, or VP accepts/closes.	System / VP / Head of Maintenance / PM
Mitigating	Mitigation plan started.	Mitigation completes (→ Closed) or is abandoned (→ Open) or VP accepts (→ Accepted).	Owner
Accepted	VP accepts with justification.	Terminal (or manually re-opened if conditions change).	VP / VP delegate
Closed	Mitigation done, or risk no longer applies.	Terminal.	Owner / VP

9.3 Weekly Business Review (VP-owned)

Status	Entry condition	Exit condition	Set by
Draft	WBR started for the ISO week.	VP signs off (→ Signed) or the week rolls over unfinished (remains Draft indefinitely, flagged overdue).	VP / delegate
Signed	VP executes Sign-off with all sections populated.	Terminal / immutable. A later edit creates a new Draft version chained to it.	VP only

Immutable vs editable fields: on a Signed WBR, all content and the data snapshot are immutable; only the export action and read access remain available. On a Decision or Risk in any terminal state, the record itself is immutable except for the specific transitions explicitly defined above (Withdraw/Supersede/Re-open).

10. End-to-End Workflows

10.1 Campaign approval, from Head of Maintenance proposal to rollout

• Initiator: Head of Maintenance (or PM, if PM-originated) proposes a Campaign in the Head of Maintenance Console.
• The routing rule (Argo Shared Operating Model §4.5) evaluates scope/cost/safety/withdrawal-duration and determines VP approval is required.
• Participating roles/systems: Head of Maintenance Console (proposal), VP Console (decision), shared spine (Campaign entity).
• Record changes: Campaign PROPOSED; Decision Awaiting decision created and appears in VP’s queue within one refresh cycle.
• Handoff: VP reviews evidence inline (no side conversation required — this is the acceptance bar).
• Approval: VP approves (VP-FR-001).
• Notification: Head of Maintenance notified; Campaign transitions to APPROVED.
• SLA/timer: Decision ages visibly past 3/7 days if not acted on (Section 7.5).
• Exceptions: VP requests more evidence (returns to Head of Maintenance/PM without consuming the decision) or rejects (terminal unless resubmitted).
• Terminal state: Campaign ROLLING_OUT in the Head of Maintenance Console; VP lands back on the Decisions Queue with the item now shown under “Recently decided.”

Figure 2 — Cross-surface interaction, VP Console highlighted.

10.2 Weekly Business Review cycle

• Initiator: VP or delegate, typically Thursday/Friday.
• Participating: VP Console only (read-aggregates from Head of Maintenance/PM/Maintenance Supervisor Web via the shared spine).
• Record changes: WBR Draft created/edited; on Sign-off, frozen to Signed.
• Approvals: Sign-off is itself the approval — a personal VP attestation.
• Notifications: reminder if no draft by Thursday; confirmation to any subscribed stakeholders on publish (if configured).
• Exceptions: a section’s data source is unavailable at preview time → Sign-off blocked, explicit inline flag.
• Terminal state: Signed WBR appears in Reviews history, exportable, referenced by future weeks’ diff view.

11. Data Requirements

Source entities consumed (owned elsewhere, per the Argo Shared Operating Model): Vehicle, Work Order, Cohort, Campaign, Roadmap Item — all read via the shared spine, never duplicated or locally recomputed. Source entities owned here: Decision, Risk, Weekly Business Review (Section 9).

Field	Definition
Canonical IDs	Every cross-referenced entity (Campaign, Cohort, WO, Roadmap Item) is referenced by its canonical ID from the owning console; the VP Console never mints a competing ID.
Ownership	Decision/Risk/WBR are VP-owned records of truth; all other displayed data is read-only, owned by Head of Maintenance/PM/Maintenance Supervisor Web consoles per the Argo Shared Operating Model.
Freshness	Portfolio heat-grid and TH drill-in: cached 15 minutes, explicit “as of” timestamp always shown. Decisions/Risk: real-time (no cache) given their approval-critical nature.
Aggregation level	Portfolio/product/Tricycle-Hardware-wide only; no bay- or WO-level operational detail is computed here — always sourced pre-aggregated from Head of Maintenance/PM.
Retention	Decisions and Risks: retained indefinitely (permanent audit record). Signed WBRs: retained indefinitely, exported copies are the VP’s own responsibility to archive further.
Data-quality rules	A KPI tile that cannot compute (missing upstream data) shows an explicit “data unavailable” state, never a zero or blank that could be misread as “good.”
Missing-data behaviour	See row above; additionally, any product in the portfolio heat-grid lacking a defined reliability metric ([VERIFY] per Section 7.2) shows “metric not configured” rather than a blank or a zero.
Stale-data indicators	Explicit “stale” tag per Section 7.1, computed against each metric’s declared refresh interval.
Reconciliation rules	Every number shown must match its Head of Maintenance/PM/Maintenance Supervisor-Web source exactly at the same timestamp — verified by the cross-surface reconciliation tests, Section 20.
Export schema	WBR export (PDF/DOCX): sections in builder order, each with its “as of” timestamp and any VP narrative. Decision export (CSV/PDF): id, title, type, submitter, submitted date, decided date, decision, decider, comment, routing-rule trigger.

12. Metrics & Analytical Definitions

All metrics below reuse the Argo Shared Operating Model’s canonical definitions (Section 5 of that document) without local redefinition. Presented here with the VP-specific drill-down and incomplete-data behaviour.

Metric	Numerator / denominator	Window	Drill-down	Incomplete-data behaviour
Fleet-Ready %	(Healthy + routine-due vehicles) ÷ active fleet (withdrawn excluded)	Real-time, cached 15 min	→ TH drill-in VRI band chart	Shows “data incomplete — X% of fleet unclassified” if telemetry-dark vehicles exceed 5% of fleet
VRI band distribution	Vehicle count per band (Healthy/Watch/At-risk/Critical/Unknown)	Rolling 90-day, per Shared Operating Model §5	→ Critical Cohorts table filtered to that band	Unknown slice always shown separately, never folded into Healthy
Cohort recurrence rate	Cohort vehicles recurring after fix ÷ cohort size	Per-cohort observation window	→ PM Console Cohort Detail (read-only)	Cohorts with <5 members show “sample too small” instead of a misleadingly precise percentage
Median time-to-resolve	Median hours NEW → IN_SERVICE (BLOCKED-pause rule applies)	Rolling 30-day	→ Head of Maintenance dispatch workbench (read-only)	Excludes still-open WOs; shown alongside open-WO count so the number isn’t misread as complete
First-pass validation rate	Gate #2 passes without send-back ÷ total Gate #2 submissions	Rolling 30-day	→ Maintenance Supervisor Web data-quality console (read-only)	n/a below 10 submissions in window — shows raw count instead
MDBF / MTBF	Mean distance / time between confirmed failures, per cohort or system	Rolling 90-day	→ PM Console cohort analytics (read-only)	Falls back to duty-day basis if odometer data missing, per Shared Operating Model §5
Cost of Poor Quality (COPQ)	Rider-days-lost value + direct repair spend (two components, always broken out)	Rolling 30-day / quarterly for WBR	→ PM Console COPQ analysis (read-only)	If the rider daily-earning proxy is unset, shows the repair-spend component only with an explicit “earnings proxy not configured” note rather than a false zero
Decision median time-to-decision	Median (decided_at − submitted_at) across Decisions	Rolling 30-day	→ Decisions Queue filtered to decided items	Excludes withdrawn/superseded; shown with count

13. Search, Filtering & Navigation

• Global search (⌘K) scope: Decisions, Risks, Reviews, product names, cohort names (read-through to PM), campaign names (read-through to Head of Maintenance) — federated search across the shared spine’s canonical titles/IDs.
• Faceted filters: Decisions Queue by type/age/status; Risk Register by category/severity/status/trend; Portfolio heat-grid by RAG/product family.
• Compound filters combine with AND within a facet group and across groups (e.g., status=Open AND category=Cohort).
• Saved views: named, persisted per user per list, with a settable default; reset action returns to the system default view (unfiltered, default sort) without deleting saved views.
• No-results behaviour: explicit “No results for these filters” with a one-click “Clear filters” action — never a blank table.
• Recent items: last 10 visited Decision/Risk/Review detail pages, available from the ⌘K palette under a “Recent” heading.
• Deep links: every list row and every notification resolves to a fully-loaded detail page at that exact record, never to a list filtered to “probably this one.”

14. Notifications & Event Contract

Follows the generic cross-surface contract in the Argo Shared Operating Model, Section 6 (deduplication, retry, read/unread, deep-link requirement) exactly. VP-specific event types:

Trigger	Recipient	Channel	Priority	Deep link
Decision routed to VP	VP	In-app + push (per [VERIFY-3] transport) + Notification Centre	Normal (High if safety-critical routing trigger)	Decision Detail
Decision aging past 3 / 7 days	VP	In-app + Notification Centre	Escalating (Normal → High)	Decision Detail
Risk auto-created by threshold breach	VP	In-app + Notification Centre	High if severity=High	Risk Detail
WBR not started by Thursday (configurable)	VP	In-app + Notification Centre	Normal	WBR Builder (new/resume)
A previously-decided item changed state unexpectedly (e.g., approved campaign hit a fallout event)	VP	In-app + Notification Centre	Normal	The specific Campaign’s read-only detail

15. Integrations & Cross-Surface Effects

• PM Console: source of truth for Cohort, Engineering-Feedback Item, Roadmap Item, and Outcomes/Experiment data. VP Console reads these read-only; never edits.
• Head of Maintenance Console: source of truth for Work Order, Campaign (operational rollout), Bay/capacity data, and Taxonomy. VP Console reads these read-only; the Decisions Queue is the one place VP write-actions affect a Campaign/Roadmap item’s lifecycle (via the shared spine, not a direct edit).
• Maintenance Supervisor Web Console: source of truth for Evidence Packets and confirmed-record data quality metrics. VP Console reads First-pass validation rate and packet-linked evidence read-only.
• Maintenance Technician Lead mobile / Maintenance Supervisor mobile (out of scope, referenced only): upstream originators of the WO/Case data that rolls up here; VP Console has no direct integration surface with them.
• CPO Console (out of scope, referenced only): downstream consumer — the VP’s portfolio roll-up is itself an input to a future CPO console pass, not built here.
• Auth / role management [VERIFY-7]: VP Console assumes an external identity/role source of truth; it consumes role=VP / VP_DELEGATE assignments, it does not manage them.
• Exports: WBR (PDF/DOCX) and Decision records (CSV/PDF) are generated in-console; no external report-generation system is assumed.

16. Non-Functional Requirements

• Performance budgets: Executive Home first-meaningful-paint under 2s on the shared spine’s cached aggregates; Decision Detail evidence panel loads under 3s or shows an explicit loading state past that.
• Staleness handling: any cached metric older than 2× its declared refresh interval is visibly tagged stale (Section 7.1); Decisions/Risk are never cached (real-time by requirement, Section 11).
• Security & access control: all write actions (approve/reject/accept/sign-off) are server-enforced by role per Section 5; every VP Console screen is read-only-safe to view by an auditor role if one is later introduced (not built in this pass, but the permission model must not preclude it).
• Auditability: every Decision, Risk, and WBR state change is permanently logged with actor/timestamp/comment; logs are never editable or deletable through the UI.
• Accessibility: WCAG 2.1 AA — all RAG/status colour coding is paired with a text label or icon (never colour-only); all charts have a text-equivalent summary on hover/focus.
• Keyboard navigation: ⌘K palette fully keyboard-operable; all list rows and detail-page actions reachable via Tab/Enter without a mouse.
• Browser support: latest two major versions of Chrome, Edge, Safari, Firefox — no IE/legacy support.
• Observability: every write action emits a structured event to the shared event log (Section 14) for downstream monitoring/alerting.
• Data privacy: no rider-identifying data is displayed at VP altitude beyond aggregate counts; individual rider records are never surfaced here.
• Export protection: every export action is logged with actor/timestamp/record-scope; exported files carry a footer stating “Confidential — Vehicle Operations.”
• Error recovery: every module failure is isolated (Section 7.1 partial-failure isolation) — one broken data source never blanks the whole page.

17. Complete UI-State Catalogue

Every page and module in this document defines the following states explicitly; the general rules (not restated per-module beyond Sections 7.1–7.10 above) are:

State	General rule applied across this console
Initial loading	Skeleton shimmer matching the canonical design-system skeleton pattern; never a blank white area.
Partial loading	Modules load independently; a slow module shows its own skeleton while sibling modules that finished render immediately (no page-level loading gate).
Populated	Standard rendered state with live data and the “as of” timestamp where caching applies.
Selected	Selected row/card gets the canonical selection highlight (brand-green-tinted background per the design system) and updates any inspector/detail panel in place where applicable.
Hover	Row hover reveals row actions; chart hover shows crosshair + exact value tooltip; RAG badges show their “why” tooltip.
Focus	Visible focus ring on every interactive element for keyboard navigation, per accessibility NFR.
Disabled	Sign-off and Approve/Reject buttons are disabled (not hidden) with a tooltip explaining why (e.g., “Evidence still loading”) whenever their preconditions aren’t met.
Empty	Canonical .id-empty-state with a specific, checkable message (never generic “no data”) — see per-page empty states above.
Filtered-empty	“No results for these filters” + Clear filters action, distinct from a genuinely empty list.
Error	Inline retry banner scoped to the failed module only (partial-failure isolation).
Recoverable error	Retry action re-fetches just the failed module without a full page reload.
Permission denied	403 pages/actions show “Only the VP or an active acting-VP delegate can do this” rather than a generic access-denied message.
Stale data	Explicit stale tag with last-refreshed timestamp, per Section 7.1.
Connection lost	A persistent top-of-page banner (“Connection lost — retrying”) while the client is offline; write actions are queued client-side and disabled with a tooltip until reconnection, never silently dropped.
Optimistic update	Not used for Decisions/Risk/WBR sign-off (too consequential); these always wait for server confirmation before showing success.
Update conflict	If a Decision or Risk was changed by another actor since the page loaded (e.g., a delegate and the VP both open it), the second submitter sees a conflict dialog with the other actor’s change and must explicitly re-confirm.
Destructive confirmation	Withdraw-a-decision and Reject actions show a lightweight confirm step (not a heavy modal) stating the exact consequence (“This will revert Campaign X to Proposed”).
Completed / success	A brief, specific success state (“Decision approved — Campaign X is now Approved”) — never a generic toast with no reference to what changed.

18. Edge Cases & Failure Scenarios

• A Campaign the VP is about to decide on has a vehicle withdrawn mid-review: the evidence panel shows a live re-fetch warning (“Scope changed since this decision was submitted — N vehicles withdrawn”) before Approve is allowed to proceed, per the Argo Shared Operating Model §7/§9.2 fallout rule.
• Two Decisions reference the same Cohort (e.g., a Campaign and a separate Roadmap item both target Bundle R2): both are shown with a cross-reference banner so the VP doesn’t approve overlapping/conflicting interventions unknowingly.
• A Risk auto-created by a withdrawal-spike threshold is duplicated because the same spike also triggered a cohort-recurrence risk: the register de-duplicates by (category, linked-cohort/withdrawal-window) key within a 24-hour window, merging into one risk with both triggering conditions listed.
• A WBR draft’s evidence for “Decisions closed this week” references a Decision that was later Withdrawn after the draft was built but before Sign-off: Preview re-fetches live, so the withdrawal is reflected automatically; Sign-off is blocked if this creates an internal inconsistency (e.g., a section claims a Decision is Approved while it’s now Withdrawn) with an explicit “data changed since draft — refresh section” prompt.
• Stale executive rollups: if the shared spine’s aggregation job is delayed, every affected KPI tile shows the stale tag (Section 7.1/17) rather than a silently outdated number; the Executive Home banner additionally shows a console-wide “data as of {t}” notice if more than 3 modules are stale simultaneously.
• Missing evidence on a routed Decision (e.g., the Evidence Packet was deleted/corrupted upstream — should not happen given append-only versioning, but must degrade safely): Approve/Reject are disabled with an explicit error; “Request more evidence” remains available, routing back to the submitter.
• Low-confidence cause feeding into a Decision’s impact preview: the impact-preview panel shows the underlying confidence level (High/Med/Low, from the shared reliability model) alongside the projection, never presenting a low-confidence estimate with the same visual weight as a high-confidence one.
• A taxonomy code referenced in a Decision’s evidence is merged into another code (Head of Maintenance governance action) while the Decision is still open: the evidence panel shows both the original code and a “superseded by {new code}” note, per the Argo Shared Operating Model §8 rule 6 (historical auditability).
• Failed WBR export (PDF/DOCX generation error): the Signed record itself is unaffected (it was already frozen at Sign-off); the export action shows a retry option and, on repeated failure, offers a raw-data export fallback so the VP is never blocked from getting the content out of the system.
• Downstream system unavailable (e.g., Head of Maintenance Console’s live data temporarily unreachable): TH drill-in and Decisions evidence panels show the error/stale state (Section 17) rather than blocking the entire VP Console — Risk Register, Reviews history, and Settings remain fully usable since they don’t depend on that specific upstream.

19. Product Analytics

• Events instrumented: page_view (per route), decision_viewed, decision_approved, decision_rejected, decision_conditioned, decision_withdrawn, decision_superseded, risk_created, risk_accepted, risk_escalated, risk_closed, wbr_started, wbr_previewed, wbr_signed, wbr_exported, saved_view_created, delegation_started, delegation_ended.
• Key funnels: Decision routed → viewed → decided (time-to-decision, Section 12); WBR started → previewed → signed → exported (completion funnel, target: no abandoned drafts past the following Monday).
• Task success: % of Decisions decided (approved/rejected/conditioned) vs. left to age past 7 days.
• Abandonment: WBR drafts started but never signed, by week.
• Error rates: evidence-panel load failures per week (target trending to zero — a direct data-quality/integration health signal).
• Time to decision: median and p90, tracked per Decision type (Campaign/Roadmap/Withdrawal/Resourcing) to spot systemic bottlenecks.
• Feature usage: saved-views creation rate, ⌘K usage rate vs. sidebar navigation (signal for whether power-user features are landing).
• Adoption/recurring use: weekly active use of the console by the VP persona itself (a console the VP stops opening is a failed console, regardless of feature completeness).

20. Acceptance Test Suite

20.1 Functional acceptance scenarios

• Approve, reject, condition, withdraw, and supersede each produce the exact downstream state transition specified in Section 8/9.
• A WBR can be built, previewed (with live re-fetch), signed, and exported end-to-end without any manual data entry beyond narrative commentary.

20.2 Permissions tests

• A non-VP, non-delegate user attempting Approve/Reject/Sign-off receives 403 with the exact message specified in Section 5.4.
• A delegate can Approve/Reject/Accept-risk but cannot Sign-off a WBR or Withdraw/Supersede a VP decision (Section 5.1/9).

20.3 Transition tests

• Every state transition in Section 9’s three entity tables is individually testable and produces the specified downstream effect.

20.4 Cross-surface reconciliation tests

• Fleet-Ready %, VRI band distribution, COPQ, and median time-to-resolve shown in the VP Console match the Head of Maintenance Console and PM Console exactly at the same timestamp (Section 4.4/11).
• An Approved Campaign is visible as APPROVED in the Head of Maintenance Console’s rollout board within one refresh cycle of VP approval.

20.5 Data-quality tests

• A cohort with <5 members never displays a misleadingly precise recurrence percentage (Section 12 incomplete-data behaviour).
• Telemetry-dark vehicles are never counted as Healthy in the VRI distribution (Section 12).

20.6 Notification tests

• Every notification type in Section 14’s table deep-links to the exact record specified, verified by automated link-target assertions.
• Duplicate notifications within the 5-minute dedup window collapse per the Argo Shared Operating Model §6 rule.

20.7 Export tests

• A signed WBR’s PDF/DOCX export byte-for-byte reflects the content hashed at sign-off (verified by re-hashing the exported content’s text extraction).
• Decision CSV/PDF export includes every column specified in Section 11’s export schema row.

20.8 Failure-recovery tests

• Killing the evidence-panel data source mid-load shows the recoverable-error state and a working retry, per Section 17.
• A Decision approval submitted during a downstream-write failure surfaces the reconciliation error and retry path specified in VP-FR-001.

20.9 Accessibility tests

• Full keyboard traversal of the Decisions Queue → Decision Detail → Approve flow with no mouse.
• Every RAG/status colour has a paired text label, verified by an automated colour-only-encoding audit.

20.10 No-dead-end tests

• Every navigation item, row, chart, and notification in this document resolves to a real, populated destination — verified against the control-action register in the Coverage & Reconciliation Matrix.

21. Assumptions, Dependencies & Proposed Decisions

21.1 Assumptions

• The shared Argo data spine (Vehicle, WO, Cohort, Campaign, Taxonomy) is available to this console via the same read layer the Head of Maintenance/PM/Maintenance Supervisor Web Consoles use — this console does not stand up a parallel data path.
• A VP role and an optional VP-delegate role already exist or will exist in the platform’s identity system [VERIFY-7].

21.2 Dependencies (external, unresolved by any available source)

• [VERIFY-3] Notification transport (push/socket/poll) — governs which channels the Notification Centre can actually deliver through.
• [VERIFY-7] Auth/role-management system of record for VP/VP_DELEGATE assignment.
• Non-Tricycle-Hardware products’ reliability metrics for the Portfolio Heat-Grid (Section 7.2) are not defined by any available source — this PRD specifies the row/column contract and RAG logic; the actual metric per other product line is a [VERIFY] pending those products’ own instrumentation.

21.3 Proposed Product Decisions made in this document (source-silent areas resolved per instruction)

• Campaign/Roadmap VP-approval routing rule (scope/cost/safety/withdrawal-duration thresholds) — Argo Shared Operating Model §4.5, reused here.
• 24-hour Decision-withdrawal window and the Supersede alternative for later reversals — Section 9.1.
• WBR versioning-on-edit-after-signing behaviour — Section 7.8/9.3.
• Risk de-duplication key and window (Section 18) for auto-created risks.
• Notification deduplication/retry policy — Argo Shared Operating Model §6, reused here.

22. Glossary

• Argo — The field maintenance, reliability, and fault-intelligence operating system for Rechaj’s electric tricycle fleet, run by Maintenance under Vehicle Operations.
• Head of Maintenance — the Maintenance unit.
• Maintenance Supervisor — Maintenance Supervisor.
• RTS — Return To Service — the Maintenance Supervisor-exclusive transition moving a Work Order to IN_SERVICE.
• VRI — Vehicle Risk Index — the 0–100 reliability score defined in the Argo Shared Operating Model, Section 5.
• Cohort — A set of vehicles sharing a root factor (kit revision, batch, supplier lot, firmware, jig/process) used as the unit of reliability intervention.
• Campaign — A bounded, approved fleet intervention with a start and end date, targeting a defined problem or cohort — distinct from a Maintenance Schedule.
• Maintenance Schedule — A reusable, indefinite maintenance rule/policy driven by one of four philosophies (Time, Usage, Condition, Ad hoc). Sampling is not among them: an Investigation campaign carries its own sampling rule and its own in-scope vehicles.
• Decision — A VP-owned record of a routed approval request, with a full lifecycle and audit trail (Section 9.1).
• Risk — A named, tracked business concern with an owner and mitigation status, distinct from a Cohort (a data pattern) (Section 9.2).
• WBR — Weekly Business Review — the VP’s signed, versioned weekly artefact (Section 9.3).
• COPQ — Cost of Poor Quality — rider-days-lost value plus direct repair spend, always shown as two components.
• RAG — Red/Amber/Green status coding used across the Portfolio Heat-Grid and other summary views.
• Acting-VP delegate — A time-boxed delegate with full approval authority except WBR sign-off (Section 5.1).

23. What a review section, a delegation and a scope note read as

A weekly-review section says where its numbers came from. Each section of the WBR builder reads Pulled live where it loaded from source, Failed where it did not, and Unavailable where the VP marked it so. A section is never silently empty: the reader can tell a quiet week from a broken feed.

Sign-off is never delegated. The delegation surface reads Active or Off for the acting delegate, and the sign-off row reads Never delegated, because a weekly review is a personal attestation. Withdrawing and superseding a decision stay with the VP for the same reason.

A capability this console does not hold reads By design. Where the coverage view shows the VP without operational controls, taxonomy governance or the cohort workbench, it states By design rather than leaving a gap that reads as an omission.