pm maintenance prd

ARGO Product Manager Console Cohort Intelligence, Engineering Loop & Roadmap Atlas Web · 1440px desktop · Vehicle Operations / Maintenance Document 2 of 5 · Version 1.0 · Status: Draft for engineering handoff Owner: PM, Vehicle Operations MocX Smart Technologies Inc. · Confidential

1. Cover & Document Control

[TABLE] Field | Detail Product & surface | Argo — Product Manager 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 PM Console; the Product Manager (Vehicle Operations) as end user. 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_VP_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. [/TABLE] Contents

2. Executive Summary

The Product Manager owns the question the whole Argo system exists to answer at engineering altitude: which hardware problems are real, which are worth fixing, and did the fix actually work. Today that judgment is made from a table of confirmed faults with no pivoting, an engineering-feedback kanban with no rich evidence, an outcomes view that is a row of bars instead of a real before/after curve, and a roadmap that isn’t tied to measured impact. The PM Console exists to make cohort intelligence, engineering feedback, intervention outcomes, and roadmap impact one continuous, evidenced workflow: notice a cohort trending toward the 15% recurrence threshold, pivot by every supported dimension to confirm it’s real, receive or build the evidence packet, prioritize it against the rest of the backlog, propose the fix as a Campaign or Roadmap item, and — months later — see the actual before/after curve that proves (or disproves) that the fix worked. Decisions this surface enables: which Engineering-Feedback items get prioritized and linked to a roadmap commitment; which interventions get proposed as Head of Maintenance campaigns; whether an outcome counts as resolved or needs a second pass. Success looks like: a PM can run the entire quarterly reliability review from this console, with every number reconciled against the Head of Maintenance and VP Consoles.

3. Persona & Operating Context

3.1 Responsibilities

• Decide which hardware problems to fix, in what order, and prove whether the fix worked.
• Own the engineering feedback loop between confirmed field failures and TH Engineering.
• Own the quarterly reliability review and the roadmap’s reliability-impact narrative.

3.2 Working cadence

Daily: monitor the cohort watchlist and the engineering-feedback pipeline. Weekly: review new evidence packets, update intervention proposals. Quarterly: run the full Quarterly Reliability Review, informing the roadmap.

3.3 Primary jobs to be done

• “Is any cohort trending toward the intervention threshold, and is it real or noise?” → Cohort Analytics Workbench.
• “What’s the actual root-cause evidence behind this pattern?” → Evidence-Packet Inbox → Record/Cohort drill-down.
• “What should TH Engineering work on next, and why?” → Engineering-Feedback Pipeline, prioritization.
• “Did the fix we shipped last quarter actually reduce recurrence?” → Outcomes/Experiments.
• “What’s on the roadmap, and what’s its projected reliability impact?” → Roadmap.
• “What’s the quarter’s reliability story for leadership?” → Quarterly Reliability Review builder.

3.4 Decisions made here

• Prioritize/score Engineering-Feedback items (impact scoring, RICE-style).
• Propose an Intervention and request it become a Head of Maintenance Campaign (subject to Head of Maintenance/VP approval per the routing rule).
• Commit a Roadmap item and its projected impact model.
• Accept or reject an Outcome as “resolved” vs. requiring a second intervention.

3.5 Inputs received

• Evidence Packets from the Maintenance Supervisor Web Console.
• Confirmed Tier-2 fault data, cohort membership, and recurrence chains from the shared spine.
• Campaign rollout progress and completion data from the Head of Maintenance Console.

3.6 Outputs produced

• Prioritized Engineering-Feedback backlog, linked Roadmap items, Intervention/Campaign proposals, and the signed Quarterly Reliability Review.

3.7 Pressure points

• Distinguishing a genuine emerging cohort from statistical noise on small sample sizes — the workbench must make sample size and confidence visible, never hide behind a bare percentage.
• Evidence arriving from the Maintenance Supervisor Web Console with inconsistent completeness — the Evidence-Packet Inbox must surface completeness/quality signals, not just a raw inbox count.

3.8 What this role explicitly cannot do

• Cannot dispatch technicians, approve bay replenishment, validate a repair or return a vehicle to service, or directly operate an individual Work Order — those are Head of Maintenance/Maintenance Supervisor-mobile-altitude actions. The PM Console never exposes a WO’s operational controls, only its confirmed-fault data as an analytical input.
• Cannot promote, merge, or reject a taxonomy code — that’s the Head of Maintenance’s exclusive authority (Argo Shared Operating Model §3).

4. Goals, Non-Goals & Measurable Success Criteria

4.1 Product outcomes

• Every cohort crossing the 15% recurrence threshold generates a visible, actionable Engineering-Feedback item or Intervention proposal within one business day.
• 100% of submitted Evidence Packets are triaged (assigned/prioritized/rejected/merged) within 5 business days.

4.2 Operational outcomes

• Median time from Evidence Packet submission to a linked Roadmap-item decision under 15 business days.
• Every completed Campaign has a computed Outcome/Experiment record within its measurement window, with zero manually-reconstructed before/after analyses.

4.3 Adoption & usability outcomes

• PM completes the full Quarterly Reliability Review (data pull → narrative → export) without leaving the console.

4.4 Data-quality outcomes

• Cohort recurrence and COPQ figures reconcile exactly with the Head of Maintenance and VP Consoles at the same timestamp.
• Sample-size and confidence are shown alongside every cohort/pivot statistic; no percentage is displayed without its denominator visible on request.

4.5 Explicit non-goals

• Not a dispatch or bay-operations tool. Not a repair-validation or RTS surface. Not a taxonomy-governance tool (view-only reference here; promote/merge/reject lives exclusively in the Head of Maintenance Console).

5. Role, Permission & Authority Model

[TABLE] Action | Product Manager | PM Analyst (delegate/associate) | Server-enforced rule View cohort analytics, records, evidence packets | Full | Full | Read access requires role ∈ {PM, PM_ANALYST}. Build / submit an Evidence-Packet-derived Engineering-Feedback item | Full | Full (draft only, cannot finalize prioritization) | PM_ANALYST can create/edit but the Prioritize action (RICE scoring lock-in) requires role=PM. Propose an Intervention / request a Campaign | Full | Draft only | Submission to Head of Maintenance requires role=PM. Commit a Roadmap item | Full | None | role=PM only — a roadmap commitment is a resourcing signal that must trace to one accountable owner. Accept/reject an Outcome as resolved | Full | None | role=PM only. Build / publish the Quarterly Reliability Review | Full | Draft/edit only | Publish requires role=PM (mirrors the VP Console’s WBR sign-off pattern). Export records / evidence | Full | Full | All exports audit-logged with actor + timestamp + record scope. [/TABLE]

5.1 Delegation and acting-role behaviour

A PM may designate a PM_ANALYST for day-to-day cohort/evidence work; final prioritization, campaign submission, roadmap commitment, and review publication remain PM-only, mirroring the non-delegable pattern established for VP-only actions in the VP Console PRD.

5.2 Multi-bay and multi-role behaviour

Not bay-scoped — the PM Console operates at product/cohort altitude across all bays; a cohort’s per-bay distribution is shown as a dimension within the analytics workbench (Section 7.2), never as a bay-operational view.

5.3 Audit requirements

• Every Engineering-Feedback prioritization change, Intervention proposal, Roadmap commitment, and Outcome decision is logged with actor/timestamp/rationale.

5.4 Forbidden actions and expected error responses

• A PM_ANALYST attempting to submit an Intervention/Campaign proposal receives 403: “Only a Product Manager can submit this for Head of Maintenance review.”
• Any attempt from this console to directly transition a Work Order or Campaign’s operational rollout state (Head of Maintenance-owned) is rejected — the PM Console has no such control to attempt in the first place; this is enforced by the absence of the control, not just a permission check.

6. Complete Information Architecture

• Reliability Home — /pm/home
• Cohort Analytics — /pm/cohorts (workbench) → /pm/cohorts/:cohortId (detail) → /pm/cohorts/:cohortId/vehicles (affected-vehicle drill-down) → /pm/cohorts/:cohortId/recurrence (recurrence-chain investigation) → /pm/cohorts/:cohortId/copq (cost-of-poor-quality)
• Engineering Loop — /pm/packets (evidence-packet inbox) → /pm/feedback (pipeline) → /pm/feedback/:itemId (item detail, prioritization, impact scoring)
• Interventions — /pm/interventions/new (proposal builder) → /pm/interventions/:id (detail, campaign-request status)
• Outcomes — /pm/outcomes (experiments list) → /pm/outcomes/:campaignId (before/after detail, ROI, confidence)
• Roadmap — /pm/roadmap → /pm/roadmap/:itemId (detail, impact modelling)
• Reviews — /pm/reviews (history) → /pm/reviews/new (quarterly review builder) → /pm/reviews/:id (detail/export)
• Notifications — /pm/notifications
• Settings — /pm/settings (saved views, notification preferences, delegate management) Figure 1 — PM Console sitemap.

6.1 Cross-surface deep links

• Cohort detail’s linked-code cell deep-links to the Head of Maintenance Console’s Taxonomy reference view (read-only — promote/merge lives there, not here).
• Engineering-Feedback item’s evidence section deep-links to the originating Evidence Packet in the Maintenance Supervisor Web Console (read-only).
• Intervention detail deep-links to the Head of Maintenance Console’s Campaign Rollout Board once approved (read-only progress view).
• Roadmap item and Outcomes summaries roll up read-only into the VP Console’s TH drill-in.

6.2 Breadcrumbs, saved views, command palette

Breadcrumb pattern: Argo / PM Console / {section} / {sub-page}. Saved views apply to Cohort Analytics (pivot + filter state), Engineering-Feedback Pipeline (status/priority filters), and Roadmap (Now/Next/Later grouping). ⌘K destinations: any of the 9 routes by name; jump to a specific cohort/item/roadmap entry by ID or title match; quick action “New intervention proposal”; quick action “Start quarterly review.”

7. Complete Page Inventory

7.1 Reliability Home

Purpose: orient the PM on the state of product reliability at a glance. Entry: default landing route, notifications, ⌘K. Exit: every module links to its full page.

Modules, in visual order

• Reliability Driver Tree (signature module) — see 7.1a for full spec; embedded condensed here (top 2 levels only) with “Expand full tree ›” link.
• Header KPI band: Fleet-Ready %, MDBF/MTBF trend, cohort count by status (Watch/Rising/Intervened), COPQ (both components).
• Cohorts to watch (top 5 by recurrence-rate trend) — condensed workbench rows; “Full workbench ›”.
• Engineering-feedback pipeline snapshot (count by stage) — “Full pipeline ›”.
• Recent outcomes (last 3 completed campaigns’ before/after headline) — “All outcomes ›”.

Reliability Driver Tree — full definition (7.1a)

A decomposition module: the root node is the portfolio’s overall reliability score (Fleet-Ready % as the top-line proxy); child nodes decompose by System (from the taxonomy — MTR/CTRL/BAT/DRV/BRK/HARN/HMI/TEL/CHS/INV), then by Cohort within a system, then by individual Fault Class. Each node shows its contribution to the overall score’s movement (e.g., “Drivetrain: −2.1 pts this month, driven mainly by Cohort Bundle R2”) so a PM can trace “why did reliability move” down to the specific cohort/cause, not just see an aggregate number.

• Interaction: click any node to expand its children; the tree remembers expand/collapse state per session; a breadcrumb trail above the tree shows the current drill path.
• Each leaf (Fault Class) node deep-links to that class’s cohort/record view.
• States: skeleton on load; explicit “insufficient data to decompose below this level” leaf state when a node’s sample size is too small (< 5 vehicles) rather than showing a misleading precise split.

Acceptance

• Every driver-tree node’s contribution value sums correctly to its parent’s total movement (verified by the reconciliation tests, Section 20).

7.2 Cohort Analytics Workbench

Purpose: the PM’s primary investigative tool — pivot confirmed-fault data by any supported dimension to confirm whether a pattern is real and where it concentrates.

Layout

• Pivot control bar: dimension selector (multi-select from: kit revision, install batch, supplier, VCU type, firmware version, component/system, bay, region, assembly jig/process), metric selector (recurrence rate, MDBF/MTBF, COPQ, open-fault count), time window selector (30/90/180/365 day, or custom range).
• Primary chart: small-multiples grid, one panel per top-level pivot value, each showing the recurrence curve over the selected window, sorted by current recurrence rate descending.
• Cohort table below the chart — full column spec (not “standard table behaviour”): Cohort name/ID, type, member count (active fleet, i.e., withdrawn excluded per the Shared Operating Model), recurrence rate (%, with sample-size shown on hover), trend (7/30-day sparkline), status (Detected/Watched/Intervened/Stable/Retired), linked Fault Class/code, days since first detection, “Investigate ›” row action.
• Sort: any column; default sort recurrence rate descending. Filter: status (multi-select), pivot dimension value (chip-based, compounds with the pivot control bar). Bulk action: “Export selected cohorts” (CSV, schema in Section 11).

Cohort Detail (drill-in from workbench row)

• Header: cohort name, defining factor(s), member count, status, linked code(s).
• Recurrence curve (large, brushable, hover crosshair) with the 15% intervention threshold shown as a reference line.
• Affected-Vehicle Drill-Down tab: table of every member vehicle, columns: plate/VIN [VERIFY-1 canonical ID], VRI, last fault date, fault count in window, withdrawal status; row action “View vehicle timeline ›” (Section 7.2b).
• Recurrence-Chain Investigation tab: for each vehicle with ≥2 WOs on the same/related Tier-2 code, a chain timeline (WO id, date, confirmed code, resolution, days-to-next-recurrence); chain view groups by vehicle, expandable.
• Cost-of-Poor-Quality tab: the two-component COPQ breakdown (rider-days-lost value, direct repair spend) scoped to this cohort, per the Shared Operating Model §5.2 formula, with a trend chart.
• Action: “Propose intervention ›” (routes to Section 7.4 builder, pre-scoped to this cohort).

7.2b — Vehicle Reliability Timeline (shared micro-module)

A horizontal timeline per vehicle: every Signal/WO as a dot, colour-coded by outcome (confirmed fault / not-a-fault / still open), hoverable for a one-line summary, clickable to the WO’s read-only detail (deep link to Head of Maintenance Console). This is the same signature pattern referenced across Argo’s field surfaces, reused here at PM altitude for cohort investigation.

States & acceptance

• A cohort pivot with fewer than 5 vehicles in a bucket displays “sample too small — showing raw counts” instead of a percentage, everywhere in the workbench and detail views.
• Acceptance: every displayed recurrence rate is reproducible from the underlying WO/vehicle data by the definition in the Shared Operating Model §5.1, verified by the data-quality tests in Section 20.

7.3 Evidence-Packet Inbox

Purpose: the PM’s queue of Evidence Packets submitted by Maintenance Supervisors via the Maintenance Supervisor Web Console, awaiting triage into the Engineering-Feedback Pipeline.

Columns

• Packet title, submitting Maintenance Supervisor, cohort/record scope, version (v1/v2… with a “revised” tag per the Shared Operating Model §2.10/§7.3 versioning rule), submitted date, completeness indicator (does it include narrative + recommendation + evidence, per the Maintenance Supervisor Web Console’s own validate-completeness gate), status (Submitted/Acknowledged/Returned/Closed).

Row actions

• Acknowledge (moves to Acknowledged, notifies the submitting Maintenance Supervisor, does not yet create a Feedback item).
• Convert to Engineering-Feedback item (opens Section 7.4’s item detail pre-filled from the packet).
• Return for correction (reason required — routes back to the Maintenance Supervisor Web Console, sets packet status Returned, per the Shared Operating Model’s packet versioning rule; the Maintenance Supervisor’s resubmission arrives as a new version, not a new packet).
• Merge into an existing Feedback item (if this packet duplicates an already-tracked item — links both, does not discard the packet).

States & acceptance

• Empty state: “No packets awaiting triage.” A packet that fails its own completeness gate on the Maintenance Supervisor Web side never appears here as Submitted — it remains a Draft on the Maintenance Supervisor side (enforced upstream, verified here by never seeing an incomplete Submitted packet in this inbox).
• Acceptance: every Convert action produces a real, linked Engineering-Feedback item — never a copy that loses the link back to the source packet’s evidence.

7.4 Engineering-Feedback Pipeline & Item Detail

Purpose: the tracked, prioritized backlog of “hardware needs to change,” whether sourced from an Evidence Packet, an automatic cohort-threshold breach, or manual PM creation.

Pipeline view

• Kanban-style columns: New / Triaged / Prioritized / Linked to Roadmap / Rejected / Merged — matching the lifecycle in the Shared Operating Model §2.11. Each card shows title, source (packet/auto/manual), impact score, cohort link, age.
• List-view toggle with the same columns as sortable/filterable table fields (source, impact score, cohort, age, status).

Item Detail — every field

• Header: title, source (linked Evidence Packet or auto-trigger cohort/threshold detail, or manual-entry note), status, age.
• Evidence panel: for packet-sourced items, the full packet content inline (narrative, evidence gallery thumbnails, cohort scope) — never just a link-out; for auto-triggered items, the specific cohort/threshold data that fired it.
• Impact/priority scoring: a RICE-style panel — Reach (vehicles affected), Impact (severity-weighted, using the S1–S4 scale), Confidence (High/Med/Low, distinct from any capture/root-cause confidence field per the Shared Operating Model §0 C11 non-conflation rule), Effort (PM-entered estimate) — computed score = (Reach × Impact × Confidence) ÷ Effort, shown with its inputs always visible alongside the score (never a bare number).
• Linkage: to a Roadmap Item (create new or link existing) and to a TH Engineering tracking reference [VERIFY-6] — if no external TH Engineering system is confirmed, this field is a free-text/URL reference the PM maintains manually, clearly labelled as such.
• Actions: Triage (assign initial category), Prioritize (lock in RICE score — PM-only per Section 5), Reject (reason required, terminal), Merge (fold into another Feedback item, both remain cross-referenced).

States & acceptance

• An item cannot be linked to a Roadmap Item without a Prioritized status — enforced client- and server-side.
• Acceptance: every Prioritized item’s RICE inputs are individually visible and editable with a change history, never a silently-overwritten score.

7.5 Intervention Proposal & Campaign Request

Purpose: the builder that turns “we know what’s wrong and how to fix it” into a formal request the Head of Maintenance Console can operationalize as a Campaign.

Builder steps

• Scope: select a Cohort (pre-filled if launched from Cohort Detail) or define a custom eligibility rule.
• Objective/hypothesis: free text, required (per the Shared Operating Model §4.2 Campaign definition — a Campaign without a stated hypothesis is invalid).
• Intervention package: one or more Interventions (part swap / firmware update / process change / inspection), each with its own parts/capacity estimate.
• Projected impact: auto-computed projected recurrence reduction and rider-days-saved estimate, using the same impact-modelling logic as the Roadmap’s impact modelling (Section 7.6) — shown with a confidence band, never a bare point estimate.
• Submit: routes to the Head of Maintenance Console as a Campaign proposal in PROPOSED status; if the routing rule (Shared Operating Model §4.5) requires VP sign-off, this is shown inline (“This will also require VP approval because: {trigger}”) so the PM knows the full approval path before submitting, not after.

Intervention/Campaign Request Detail

• Status tracking: Proposed → (Head of Maintenance review) → Approved/Rejected → (if applicable, VP review) → Rolling Out → Complete — read-only progress mirrored from the Head of Maintenance Console and, where applicable, the VP Console’s Decision record (deep-linked).
• On Complete: automatically creates the placeholder Outcome/Experiment record (Section 7.6), pending its measurement window.

States & acceptance

• A proposal cannot be submitted without at least one Intervention defined — enforced client- and server-side, with an inline validation message identifying the missing step.

7.6 Outcomes / Experiments

Purpose: prove, with a real before/after curve, whether a completed Campaign actually reduced recurrence — the PM Console’s evidentiary payoff.

Outcomes list

• Columns: Campaign name, target cohort, completion date, measurement-window end date (or “in progress” if not yet reached), recurrence delta (before % → after %), rider-days saved, ROI (if cost data available), confidence.

Outcome Detail

• Before/after recurrence curve: a single brushable chart with a clear vertical marker at the campaign’s completion date, pre-period and post-period both shown, with the 15% intervention threshold as a reference line.
• Rider-days-saved calculation: shown with its inputs (vehicles affected × average off-road-days-avoided), not just the output number.
• ROI: campaign cost (parts + labor, from the Head of Maintenance Console’s campaign cost tracking, read-only) vs. rider-days-saved value + avoided-repair-spend, with the two COPQ components broken out per the Shared Operating Model §5.2.
• Confidence: statistical confidence in the observed recurrence delta, accounting for sample size — a campaign on a 4-vehicle cohort shows a wide confidence band and an explicit “small sample” flag, never false precision.
• Action: “Mark resolved” (PM-only, closes the outcome as successfully addressed) or “Propose follow-up intervention” (routes back to Section 7.5, pre-linked to this outcome as its predecessor, for cohorts where recurrence didn’t drop enough).

States & acceptance

• An Outcome in progress (measurement window not yet reached) shows a clear “measuring — full result on {date}” state rather than a premature or empty chart.
• Acceptance: the before/after delta is computed identically to how the Head of Maintenance/VP Consoles would compute the same cohort’s recurrence rate at those two points in time (shared formula, no local reinterpretation).

7.7 Roadmap & Impact Modelling

Purpose: the quarterly hardware roadmap, tied to measured/projected reliability impact rather than a bare feature list.

Roadmap view

• Now / Next / Later columns (or a timeline-view toggle), each card showing: title, linked Engineering-Feedback item(s), projected recurrence-reduction impact, projected rider-days-saved, confidence, owner (TH Engineering contact if known [VERIFY-6]).

Roadmap Item Detail

• Description, linked Engineering-Feedback item(s) and their evidence (inline, not link-only).
• Impact modelling panel: projected recurrence reduction (%), projected rider-days saved, confidence band, and the assumptions used (which cohort(s), what intervention is assumed) — always shown, never a bare projected number with hidden assumptions.
• Status: Proposed / Committed / In Progress / Shipped / Measuring Impact / Confirmed Impact (this last status links to the realized Outcome once the corresponding Campaign completes its measurement window — closing the loop from roadmap commitment to proven result).

States & acceptance

• A Roadmap item’s “Confirmed Impact” status can only be set automatically by the system once a linked Outcome/Experiment record exists — never manually claimed without the underlying measured proof.

7.8 Quarterly Reliability Review Builder, History & Export

Purpose: mirrors the VP Console’s WBR pattern at PM/quarterly cadence — produce a live-data, signed, exportable review.

Builder

• Start: “Start Quarterly Review” creates a Draft for the current quarter (one per quarter, resumable).
• Auto-populated sections: Driver-tree summary, top cohorts and their status changes this quarter, Engineering-Feedback pipeline throughput, Outcomes completed this quarter (before/after highlights), Roadmap progress and confirmed-impact items.
• PM narrative overlay per section; Preview (live re-fetch, “as of” timestamp); Publish (PM-only, freezes a hashed snapshot, mirrors the VP Console’s Sign-off semantics exactly).
• Export: PDF/DOCX in the same restrained Argo visual system as this document set.

History & acceptance

• Reviews list shows every past quarter with status, publisher, and a quarter-over-quarter diff on headline metrics.
• A published review cannot be edited in place — a re-open creates a new draft version, identical rule to the VP Console’s WBR (Shared Operating Model consistency).

7.9 Notifications

Scoped to PM-relevant event types: new Evidence Packet submitted, cohort crossed the 15% intervention threshold, Intervention/Campaign proposal state change (approved/rejected/rolled out/complete), Outcome measurement window reached, Roadmap item’s linked Outcome confirmed impact.

• List, bulk mark-read, snooze, deep link — identical generic behaviour to the VP Console’s Notification Centre (Shared Operating Model §6).

7.10 Settings

• Saved views (Cohort Analytics pivots, Engineering-Feedback filters, Roadmap groupings).
• Notification preferences, delegate (PM_ANALYST) management, default landing view.

8. Functional Requirements

PM-FR-001 — Convert an Evidence Packet into an Engineering-Feedback item

The PM converts a submitted Evidence Packet into a tracked Engineering-Feedback item.

• Actor: Product Manager or PM Analyst
• Preconditions: Packet status = Submitted or Acknowledged; packet passed its own completeness gate on the Maintenance Supervisor Web Console.
• Trigger: PM clicks Convert on the Evidence-Packet Inbox row.
• Happy path: System creates a new Engineering-Feedback item pre-filled with the packet’s cohort scope, narrative, and evidence links; item enters status New; packet is marked Linked (retained, not consumed).
• Alternate paths: PM instead clicks Merge into an existing item — no new item is created; both records cross-reference.
• Validation: Packet must not already be linked to another Feedback item (prevents duplicate tracking); if it is, the UI offers Merge instead of Convert.
• Permission rule: role ∈ {PM, PM_ANALYST} for creation; Prioritize (a later step) requires role=PM.
• State transition: Engineering-Feedback item: (none) → New. Evidence Packet: Submitted/Acknowledged → Linked.
• Data side effects: New Feedback item record created with a durable reference to the source packet (never copies evidence into a disconnected duplicate).
• Notification side effects: Submitting Maintenance Supervisor notified that their packet was accepted into the pipeline, with a deep link to the new item (read-only from their side).
• Downstream surface effects: Maintenance Supervisor Web Console shows the packet’s status as Linked with a deep link back to this PM Console item.
• Failure & recovery: If the conversion write fails, the packet remains Submitted/Acknowledged and the PM sees an inline retry — no partial/orphaned Feedback item is ever created.
• Acceptance criteria: The new item’s evidence panel shows identical content to the source packet; the link between them is bidirectionally navigable.

PM-FR-002 — Prioritize an Engineering-Feedback item (RICE scoring)

The PM locks in a RICE-style priority score for a Feedback item, making it eligible for Roadmap linkage.

• Actor: Product Manager only.
• Preconditions: Item status = Triaged.
• Trigger: PM enters Reach/Impact/Confidence/Effort values and clicks Prioritize.
• Happy path: System computes score = (Reach × Impact × Confidence) ÷ Effort, stores all four inputs alongside the score, item transitions to Prioritized.
• Alternate paths: PM Analyst can propose/edit draft RICE inputs but cannot execute Prioritize (Section 5).
• Validation: All four RICE inputs required and numeric/enumerated as specified; Confidence must use the same High/Med/Low scale as elsewhere, never conflated with capture or root-cause confidence.
• Permission rule: role = PM exactly.
• State transition: Item: Triaged → Prioritized.
• Data side effects: RICE inputs and computed score stored with a timestamped history (re-prioritizing creates a new history entry, never overwrites silently).
• Notification side effects: None required; visible in the pipeline view immediately.
• Downstream surface effects: Prioritized items become eligible for Roadmap linkage (Section 7.7); the Reliability Driver Tree may reference prioritized items in its “why did this move” narrative if linked to a shipped fix.
• Failure & recovery: None special — a failed save leaves the item in Triaged with an inline error and preserved form state (no data loss on retry).
• Acceptance criteria: The item’s RICE inputs are individually visible (not just the final score) everywhere the item is displayed, with a visible history of any re-scoring.

PM-FR-003 — Submit an Intervention Proposal as a Campaign request

The PM submits a scoped, hypothesis-backed intervention to the Head of Maintenance Console for operational approval and rollout.

• Actor: Product Manager only.
• Preconditions: At least one Intervention is defined within the proposal; objective/hypothesis field is non-empty; scope (cohort or custom rule) is defined.
• Trigger: PM completes the builder (Section 7.5) and clicks Submit.
• Happy path: System evaluates the routing rule (Shared Operating Model §4.5) and displays the full approval path (Head of Maintenance only or Head of Maintenance+VP) before final confirmation; on confirm, a Campaign entity is created in PROPOSED status in the Head of Maintenance Console.
• Alternate paths: PM Analyst can build a draft but cannot Submit (Section 5).
• Validation: Objective/hypothesis, scope, and ≥1 Intervention are all required; the projected-impact panel must have successfully computed (not still loading/errored) before Submit is enabled.
• Permission rule: role = PM exactly.
• State transition: Intervention Proposal: Draft → Submitted. Downstream Campaign: (none) → PROPOSED.
• Data side effects: New Campaign record created in the shared spine with full definition per the Shared Operating Model §4.2 (objective, scope, intervention package, parts/capacity plan placeholder, rollout dates to be set by Head of Maintenance).
• Notification side effects: Head of Maintenance notified of the new Campaign proposal awaiting review.
• Downstream surface effects: Head of Maintenance Console shows the new Campaign in its builder/approval queue; if VP routing applies, a Decision record is created simultaneously per the VP Console PRD’s VP-FR-001 precondition.
• Failure & recovery: If the projected-impact computation fails, Submit remains disabled with an inline error naming the failed computation — the PM is never able to submit a proposal with a silently-missing impact estimate.
• Acceptance criteria: The submitted Campaign is visible in the Head of Maintenance Console within one refresh cycle, with the PM’s proposal content carried over exactly (no re-entry required by Head of Maintenance).

PM-FR-004 — Mark an Outcome resolved or propose a follow-up intervention

The PM closes the loop on a completed Campaign’s measured outcome.

• Actor: Product Manager only.
• Preconditions: Outcome/Experiment record has reached its measurement window (before/after data fully computed).
• Trigger: PM reviews the Outcome Detail and clicks Mark resolved or Propose follow-up.
• Happy path: Mark resolved: Outcome status → Resolved, linked Roadmap item (if any) status → Confirmed Impact. Propose follow-up: opens the Intervention Proposal builder (Section 7.5) pre-linked to this outcome as predecessor, following PM-FR-003 from there.
• Alternate paths: None — these are the only two terminal actions on a reached-measurement-window outcome.
• Validation: Measurement window must have been reached (system-computed, not manually overridable) before either action is available.
• Permission rule: role = PM exactly.
• State transition: Outcome: Measuring → Resolved (or remains Measuring/flagged-for-follow-up while a new linked Intervention Proposal proceeds independently through PM-FR-003).
• Data side effects: Outcome record finalized with resolution decision and rationale; linked Roadmap item status updated if applicable.
• Notification side effects: None required by default.
• Downstream surface effects: VP Console’s TH drill-in and Outcomes roll-up reflect the resolution within one refresh cycle.
• Failure & recovery: None special.
• Acceptance criteria: A resolved Outcome is immutable except through a new, separately-tracked follow-up Intervention — the original before/after record is never edited to retroactively look more favorable.

9. Entity & Lifecycle Definitions

The PM Console owns Engineering-Feedback Item, Intervention Proposal, Outcome/Experiment, and Roadmap Item outright (full definitions in the Argo Shared Operating Model §2, reused verbatim). It consumes, read-only, Vehicle, Work Order, Cohort, Evidence Packet, and Campaign (operational rollout state) from the Maintenance Supervisor Web and Head of Maintenance Consoles.

9.1 Engineering-Feedback Item

[TABLE] Status | Entry | Exit | Set by New | Packet converted, or auto-triggered by cohort threshold, or manually created. | Triaged. | PM / PM Analyst / system Triaged | PM assigns initial category. | Prioritized (RICE scored) or Rejected or Merged. | PM Prioritized | RICE score locked in (PM-FR-002). | Linked to Roadmap, or remains Prioritized in backlog. | PM Linked to Roadmap | PM links/creates a Roadmap item. | Terminal (tracked via the Roadmap item’s own lifecycle from here). | PM Rejected | PM rejects with reason. | Terminal. | PM Merged | PM merges into another item. | Terminal (cross-referenced, not deleted). | PM [/TABLE]

9.2 Intervention Proposal

[TABLE] Status | Entry | Exit | Set by Draft | Builder started. | Submitted, or abandoned (remains Draft indefinitely). | PM / PM Analyst Submitted | PM submits (PM-FR-003). | Tracks the downstream Campaign’s lifecycle from here (Proposed → Approved → Rolling Out → Complete, per the Shared Operating Model §4.2) — mirrored read-only in the Intervention Proposal detail. | PM [/TABLE]

9.3 Outcome / Experiment

[TABLE] Status | Entry | Exit | Set by Measuring | Linked Campaign reaches Complete; measurement window (default 90 days) begins. | Ready for review once window elapses. | System Ready for review | Measurement window elapsed; before/after computed. | Resolved, or a follow-up Intervention Proposal is created (Outcome itself remains, cross-linked). | System → PM Resolved | PM marks resolved (PM-FR-004). | Terminal. | PM [/TABLE]

9.4 Roadmap Item

[TABLE] Status | Entry | Exit | Set by Proposed | Created from a Prioritized Feedback item, or manually. | Committed or Rejected. | PM Committed | PM commits to the roadmap. | In Progress (TH Engineering begins work — tracked externally per [VERIFY-6]). | PM In Progress | Work begins. | Shipped. | PM (reflecting external status) Shipped | Fix ships; a Campaign may be created to roll it out fleet-wide. | Measuring Impact (once a linked Campaign completes). | PM / system Measuring Impact | Linked Campaign’s Outcome enters Measuring. | Confirmed Impact. | System Confirmed Impact | Linked Outcome resolved with measured data. | Terminal. | System (never manually claimed, PM-FR-004 precondition) [/TABLE]

10. End-to-End Workflows

10.1 Evidence Packet → Confirmed Impact (the full engineering loop)

• Initiator: Maintenance Supervisor (Maintenance Supervisor Web Console) submits an Evidence Packet.
• PM converts it to an Engineering-Feedback item (PM-FR-001).
• PM triages and prioritizes (PM-FR-002); if warranted, links to a new or existing Roadmap item.
• PM (or in parallel) proposes an Intervention/Campaign (PM-FR-003), routed to Head of Maintenance for approval and, if the routing rule requires it, VP decision.
• Head of Maintenance rolls out the approved Campaign; progress mirrors read-only into the Intervention Proposal detail and the Roadmap item (status: In Progress → Shipped).
• On Campaign completion, an Outcome/Experiment record is created (Measuring); at the measurement window, before/after data computes automatically.
• PM reviews and marks Resolved (PM-FR-004); the linked Roadmap item reaches Confirmed Impact.
• Terminal state: a fully evidenced loop from field packet to confirmed, measured hardware improvement — visible end-to-end from either the Feedback item or the Roadmap item. Figure 2 — Cross-surface interaction, PM Console highlighted.

10.2 Quarterly Reliability Review cycle

• Initiator: PM, typically final two weeks of the quarter.
• Auto-populated from the shared spine (driver tree, cohorts, pipeline throughput, outcomes, roadmap progress).
• PM adds narrative, previews (live re-fetch), publishes (PM-only, frozen hashed snapshot).
• Terminal state: published review in history, exportable, referenced by the VP Console’s own quarterly context and by future quarters’ diff view.

11. Data Requirements

[TABLE] Field | Definition Source entities (consumed) | Vehicle, Work Order, Cohort, Evidence Packet, Campaign (operational state) — read via the shared spine per the Argo Shared Operating Model; never locally recomputed or duplicated. Source entities (owned) | Engineering-Feedback Item, Intervention Proposal, Outcome/Experiment, Roadmap Item (Section 9). Canonical IDs | Cohort, WO, and Campaign IDs are always the owning console’s canonical ID; the PM Console never mints a competing identifier for these. Freshness | Cohort Analytics Workbench: cached 15 minutes with explicit “as of” timestamp. Engineering-Feedback Pipeline and Outcomes: real-time (no cache), given their decision-critical nature. Aggregation level | Cohort and Fault-Class level for analytics; individual-vehicle level only within a cohort’s Affected-Vehicle Drill-Down. Retention | Engineering-Feedback items, Intervention Proposals, Outcomes, and Roadmap items retained indefinitely (permanent record of the engineering loop’s history). Data-quality rules | No percentage statistic is shown without its sample size available on hover; cohorts below 5 members always show raw counts instead. Missing-data behaviour | A cohort pivot dimension with no data for the selected window shows “no data in this window” rather than a zero that could be misread as “confirmed zero recurrence.” Stale-data indicators | Explicit stale tag on any cached view older than 2× its refresh interval, matching the VP Console’s convention. Reconciliation rules | Cohort recurrence, COPQ, and Fleet-Ready figures reconcile exactly with the Head of Maintenance and VP Consoles (Section 20 tests). Export schema | Cohort export (CSV): cohort_id, name, type, member_count, recurrence_rate, sample_size, trend, status, linked_code. Engineering-Feedback export: item_id, title, source, RICE inputs + score, status, linked_roadmap_id. [/TABLE]

12. Metrics & Analytical Definitions

Reuses the Argo Shared Operating Model’s canonical formulas (Section 5) without redefinition; adds PM-specific drill-downs and incomplete-data handling. [TABLE] Metric | Numerator / denominator | Window | Drill-down | Incomplete-data behaviour Cohort recurrence rate | Cohort vehicles recurring after fix ÷ cohort size | Configurable, default 90-day | → Cohort Detail recurrence-chain tab | “Sample too small” below 5 members MDBF / MTBF | Mean distance/time between confirmed failures, per cohort/system | Rolling 90-day | → Driver Tree leaf node | Falls back to duty-day basis if odometer missing Cost of Poor Quality | Rider-days-lost value + direct repair spend (two components) | Rolling 30-day / quarterly | → Cohort Detail COPQ tab | Repair-spend-only shown with a note if earnings proxy unset RICE priority score | (Reach × Impact × Confidence) ÷ Effort | Point-in-time, versioned | → Feedback Item Detail history | Never computed with a missing input — all four required Recurrence-after-fix % (Outcome) | Post-campaign recurrence rate for the cohort | Campaign’s defined measurement window (default 90 days) | → Outcome Detail before/after chart | “Measuring” state shown until window elapses; confidence band widens with small samples Rider-days saved | (Pre-fix expected off-road days − post-fix actual off-road days) × affected vehicles | Per campaign, at measurement window | → Outcome Detail ROI panel | Shown with its inputs, never as a bare output number First-pass validation rate (reference) | Gate #2 passes without send-back ÷ total submissions | Rolling 30-day | → read-only reference to Maintenance Supervisor Web data-quality console | n/a below 10 submissions; shows raw count [/TABLE]

13. Search, Filtering & Navigation

• Global search (⌘K): cohorts, Feedback items, Roadmap items, Outcomes, by name/ID/free-text title match.
• Faceted filters: Cohort Analytics by pivot dimension value, status, trend; Engineering-Feedback Pipeline by source/status/priority-score-range; Roadmap by status/quarter.
• Compound filters combine AND within and across facet groups.
• Saved views: named, persisted per user, settable default, reset returns to system default without deleting saved views.
• No-results behaviour: explicit message + Clear filters action.
• Recent items: last 10 visited Cohort/Item/Roadmap detail pages in the ⌘K palette.
• Deep links: every notification and cross-surface reference resolves to the exact record, never a generic list.

14. Notifications & Event Contract

Follows the Argo Shared Operating Model §6 generic contract exactly (dedup, retry, read/unread, deep-link requirement). [TABLE] Trigger | Recipient | Channel | Priority | Deep link New Evidence Packet submitted | PM (+ PM Analyst if configured) | In-app + Notification Centre | Normal | Evidence-Packet Inbox row Cohort crosses 15% intervention threshold | PM | In-app + push + Notification Centre | High | Cohort Detail Intervention/Campaign state change | PM | In-app + Notification Centre | Normal (High if rejected) | Intervention Proposal Detail Outcome measurement window reached | PM | In-app + Notification Centre | Normal | Outcome Detail Roadmap item reaches Confirmed Impact | PM | In-app + Notification Centre | Normal | Roadmap Item Detail Quarterly review not started by a configurable date | PM | In-app + Notification Centre | Normal | Reviews (new/resume) [/TABLE]

15. Integrations & Cross-Surface Effects

• Maintenance Supervisor Web Console: source of truth for Evidence Packets and confirmed-record data quality metrics; PM Console reads packets and converts them, never edits Maintenance Supervisor Web’s own record/cohort views directly.
• Head of Maintenance Console: source of truth for Campaign operational rollout state, Work Order data, and Taxonomy. PM Console proposes Interventions/Campaigns but the operational Campaign entity and its rollout are Head of Maintenance-owned from approval onward.
• VP Console: consumes PM Console’s Roadmap and Outcomes data read-only for its TH drill-in and Decisions Queue (when a PM-submitted Campaign/Roadmap item is routed for VP approval, per the Shared Operating Model §4.5).
• Maintenance Technician Lead mobile / Maintenance Supervisor mobile (out of scope, referenced only): upstream originators of the WO/fault data that ultimately feeds cohort analytics here; no direct integration surface with this console.
• TH Engineering pipeline [VERIFY-6]: if an external TH Engineering tracking system exists, Engineering-Feedback items and Roadmap items should sync status bidirectionally; absent confirmation, this console maintains the linkage as a manually-updated reference field.
• Auth / role management [VERIFY-7]: PM Console consumes role=PM / PM_ANALYST assignments from an external identity source of record.
• Exports: Quarterly Reliability Review (PDF/DOCX) and cohort/feedback CSV exports are generated in-console.

16. Non-Functional Requirements

• Performance budgets: Reliability Home first-meaningful-paint under 2s; Cohort Analytics Workbench pivot recompute under 3s for the full taxonomy/cohort set, with a loading indicator past that.
• Staleness handling: cached views (15-minute) visibly tagged stale past 2× their interval; Engineering-Feedback and Outcomes are real-time.
• Security & access control: all write actions server-enforced by role per Section 5.
• Auditability: every prioritization, proposal, and outcome decision permanently logged with actor/timestamp/rationale.
• Accessibility: WCAG 2.1 AA; no status/trend encoding by colour alone; driver-tree and pivot charts have text-equivalent summaries.
• Keyboard navigation: full ⌘K and Tab/Enter traversal, including the driver-tree’s expand/collapse.
• Browser support: latest two major versions of Chrome, Edge, Safari, Firefox.
• Observability: every write action emits a structured event to the shared event log.
• Data privacy: no individually-identifying rider data surfaced beyond aggregate/anonymized vehicle references.
• Export protection: every export logged with actor/timestamp/scope; exported files carry the “Confidential — Vehicle Operations” footer.
• Error recovery: module-level failure isolation, matching the VP Console’s partial-failure-isolation pattern.

17. Complete UI-State Catalogue

[TABLE] State | General rule applied across this console Initial loading | Skeleton shimmer, canonical pattern, never a blank area. Partial loading | Modules load independently (driver tree, cohort table, pipeline snapshot each resolve on their own). Populated | Standard rendered state with “as of” timestamp where cached. Selected | Selected cohort/item row highlighted; detail panel updates in place where applicable (e.g., driver-tree node selection). Hover | Row hover reveals actions; chart hover shows crosshair + exact value + sample size. Focus | Visible focus ring on every interactive element. Disabled | Prioritize/Submit/Publish buttons disabled with an explanatory tooltip until preconditions are met. Empty | Canonical empty state with a specific, checkable message per page (Sections 7.1–7.10). Filtered-empty | “No results for these filters” + Clear filters action. Error | Inline retry banner scoped to the failed module only. Recoverable error | Retry re-fetches just the failed module. Permission denied | 403 with the specific rule that was violated (Section 5.4). Stale data | Explicit stale tag with last-refreshed timestamp. Connection lost | Persistent banner; write actions queued/disabled until reconnection, never silently dropped. Optimistic update | Not used for Prioritize/Submit/Publish (server-confirmed only, mirroring the VP Console’s caution on consequential actions). Update conflict | Concurrent edits (e.g., PM and PM Analyst both editing a draft proposal) surface a conflict dialog requiring explicit re-confirmation. Destructive confirmation | Reject (Feedback item) and Mark resolved show a lightweight confirm step stating the exact consequence. Completed / success | Specific success state naming what changed (“Proposal submitted — routed to Head of Maintenance for approval”), never a generic toast. [/TABLE]

18. Edge Cases & Failure Scenarios

• A cohort’s membership changes mid-analysis (a vehicle is withdrawn or reassigned to a different kit revision after a pivot was run): the workbench flags “cohort membership changed since this view was loaded” and offers a one-click refresh rather than silently showing stale membership.
• An Evidence Packet is merged into an existing Feedback item after the PM already started a separate Intervention Proposal from the original packet: the proposal builder shows a warning banner linking to the now-merged item so effort isn’t duplicated.
• A vehicle is withdrawn during an active Campaign’s rollout: per the Shared Operating Model §7/§9.2, the cohort’s active-size denominator updates immediately; the Outcome (once measured) explicitly notes the excluded vehicle count so the before/after isn’t misread as covering the original full scope.
• Parts shortage delays a Campaign’s rollout past its planned completion date: the Intervention Proposal detail (read-only mirror of Head of Maintenance’s rollout board) shows the delay and revised date; the Outcome’s measurement-window start date shifts accordingly, never silently using the original planned date.
• A taxonomy code referenced by a Cohort is merged into another code mid-quarter (Head of Maintenance governance action): the Cohort Detail shows both the original and “superseded by” code, and historical recurrence data remains attributed correctly per the Shared Operating Model §8 rule 6.
• Low-confidence RICE scoring on a Feedback item with very small Reach: the item is still prioritizable, but the pipeline view visually de-emphasizes (not hides) low-confidence, low-reach items so they don’t crowd out higher-confidence priorities, without ever removing the PM’s ability to see and act on them.
• Duplicate cohorts detected across two different pivot dimensions (e.g., a supplier-batch cohort and a kit-revision cohort that happen to have near-identical membership): the workbench surfaces a “high overlap” flag between the two cohort rows so the PM doesn’t double-count the same vehicles as two separate reliability problems.
• Failed quarterly-review export: the Published record is unaffected (already frozen at Publish); export retries, with a raw-data fallback export if PDF/DOCX generation repeatedly fails.
• Downstream system unavailable (Head of Maintenance Console’s live rollout data unreachable): Intervention Proposal detail’s progress mirror shows the stale/error state; Cohort Analytics, Engineering-Feedback Pipeline, and Roadmap (all PM-owned data) remain fully usable.
• An Outcome’s measurement window overlaps a second, unrelated Campaign on the same cohort (e.g., a follow-up intervention started before the first was fully measured): both Outcomes are tracked distinctly with non-overlapping before/after windows, and the Cohort Detail’s recurrence curve annotates both campaign-completion markers so the two effects are never conflated into one curve.

19. Product Analytics

• Events instrumented: page_view, cohort_pivoted, cohort_investigated, packet_converted, packet_merged, item_prioritized, item_rejected, intervention_submitted, outcome_reviewed, outcome_resolved, followup_proposed, roadmap_item_committed, review_started, review_published.
• Key funnels: Packet submitted → converted → prioritized → linked-to-roadmap → confirmed-impact (the full engineering-loop funnel, Section 10.1).
• Task success: % of Feedback items reaching Prioritized within 5 business days of submission.
• Abandonment: Intervention Proposal drafts started but never submitted, by week.
• Error rates: pivot-computation failures per week (data-quality health signal).
• Time to decision: median time from cohort threshold breach to a submitted Intervention Proposal.
• Feature usage: driver-tree drill depth (are PMs actually decomposing to Fault Class, or stopping at System level), saved-view creation rate.
• Adoption: weekly active use of the console by the PM persona; quarterly review completion rate (started vs. published, per quarter).

20. Acceptance Test Suite

20.1 Functional acceptance scenarios

• PM-FR-001 through 004 each produce the exact state transitions and downstream effects specified.
• A full quarterly review can be built, previewed, published, and exported end-to-end with no manual data entry beyond narrative.

20.2 Permissions tests

• PM_ANALYST attempting Prioritize/Submit/Publish/Mark-resolved receives 403 with the exact messages specified in Section 5.4.

20.3 Transition tests

• Every state transition in Section 9’s four entity tables is individually testable with the specified downstream effect.

20.4 Cross-surface reconciliation tests

• Cohort recurrence rate, COPQ, and Fleet-Ready % match the Head of Maintenance and VP Consoles exactly at the same timestamp.
• A submitted Intervention Proposal appears as a Campaign in the Head of Maintenance Console’s queue within one refresh cycle, with identical content.

20.5 Data-quality tests

• No cohort below 5 members ever displays a bare percentage without the “sample too small” flag.
• RICE scores are never computed with a missing input.

20.6 Notification tests

• Every notification type in Section 14 deep-links to the exact record specified.

20.7 Export tests

• Published Quarterly Review’s export byte-matches the hashed content at Publish time.
• Cohort/Feedback CSV exports include every column in Section 11’s schema.

20.8 Failure-recovery tests

• A failed Evidence-Packet conversion never leaves an orphaned partial Feedback item (PM-FR-001 failure clause).

20.9 Accessibility tests

• Full keyboard traversal of Cohort Analytics → Cohort Detail → Propose Intervention with no mouse.

20.10 No-dead-end tests

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

21. Assumptions, Dependencies & Proposed Decisions

21.1 Assumptions

• The shared Argo data spine is available to this console via the same read layer as the other three consoles.
• A PM role and optional PM_ANALYST role exist in the platform’s identity system [VERIFY-7].

21.2 Dependencies (external, unresolved by any available source)

• [VERIFY-6] Whether a TH Engineering-side tracking system exists to bidirectionally sync with Engineering-Feedback/Roadmap items, or whether this console is itself the system of record.
• [VERIFY-3] Notification transport.
• Campaign cost data (parts + labor) for ROI computation in Outcomes (Section 7.6) depends on the Head of Maintenance Console’s own cost-tracking fidelity, which is itself dependent on [VERIFY-2] Atlas IMS contracts.

21.3 Proposed Product Decisions made in this document

• RICE-style scoring formula and its four required inputs (Section 7.4) — no source defined a prioritization formula; adopted as specified, fully computed and always shown with its inputs.
• 90-day default measurement window for Outcomes, aligned to the Shared Operating Model’s Recurrence Chain window for consistency.
• Roadmap status enumeration including the system-only “Confirmed Impact” terminal state (Section 9.4) — ensures impact claims are always measured, never asserted.

22. Glossary

• Argo — The field maintenance, reliability, and fault-intelligence operating system for Rechaj’s electric tricycle fleet, run by Maintenance under Vehicle Operations.
• Cohort — A set of vehicles sharing a root factor, the unit of reliability intervention (Argo Shared Operating Model §2.7).
• Evidence Packet — A versioned, structured artefact from a Maintenance Supervisor, submitted into this console’s Engineering-Feedback pipeline.
• Engineering-Feedback Item — The PM’s tracked unit of “hardware needs to change” (Section 9.1).
• RICE — Reach × Impact × Confidence ÷ Effort — this console’s prioritization scoring model (Section 7.4).
• Intervention — The specific corrective package (part swap, firmware, process change) a Campaign applies.
• Campaign — A bounded, approved fleet intervention with a start and end — operationally owned by the Head of Maintenance Console once approved.
• Outcome / Experiment — The measured before/after result of a completed Campaign (Section 9.3).
• Roadmap Item — A planned hardware/process change tied to projected and, eventually, confirmed reliability impact (Section 9.4).
• COPQ — Cost of Poor Quality — rider-days-lost value plus direct repair spend, always shown as two components.
• MDBF / MTBF — Mean distance / time between (confirmed) failures — the core reliability trend metric.
• Driver Tree — This console’s signature decomposition module tracing reliability movement down to cohort/cause (Section 7.1a).

23. The dimensions a cohort is cut on, and how a record reads

A cohort is cut on one of seven dimensions. Install batch · Supplier · Assembly jig / process · Component / system · Firmware version · Bay · Region. The workbench offers these and no others, because each one is a thing an intervention can be aimed at.

A record in the driver tree reads as one of three. Confirmed fault, Not a fault, or Still open. Not a fault is a closed record, not an open one, and it is excluded from reliability rates while staying visible in the capture counts.

A driver node carries the status of its cause, shown as a badge on the node, and reads Settled once the cause is agreed and no longer contested.

Notifications name the thing that moved. Beyond the surface it came from, a notification states the event: a campaign proposal state changed, or a roadmap item confirmed impact, so the reader knows whether a decision is waiting on them or a measurement has landed.