maintenance supervisor web console prd

ARGO Maintenance Supervisor Web Console Engineering-Grade Field Evidence & Data Fidelity Atlas Web · 1440px desktop · Vehicle Operations / Maintenance Document 4 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 — Maintenance Supervisor Web 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 Maintenance Supervisor Web Console; the Maintenance Supervisor (desk analysis role) 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_Product_Manager_Console_PRD.docx; argo-head-of-maintenance-console-prd-v2.0.docx; Argo_Web_Console_Coverage_and_Reconciliation_Matrix.docx.

Contents

2. Executive Summary

The Maintenance Supervisor’s mobile app validates one repair at a time, at one bay, in real time. But turning a field failure into a defensible engineering case — one TH Engineering will actually act on — takes analysis the bay floor was never built for: comparing records across vehicles, pulling telemetry and photos into one coherent narrative, spotting a cohort before it becomes a crisis, and clearing the unclassified backlog that would otherwise pollute every reliability number downstream. The Maintenance Supervisor Web Console exists as that analysis desk — engineering-grade record investigation, cohort intelligence, evidence-packet construction, and data-quality stewardship, explicitly distinct from the Maintenance Supervisor’s at-bay mobile validation gate. It is the only place in Argo where raw field records become a structured, versioned Evidence Packet ready for the PM’s engineering-feedback pipeline, and the only place a Maintenance Supervisor can propose or endorse a taxonomy mode from an analytical (not just at-bay) vantage point — though never mint, promote, or merge a code. Decisions this surface enables: which unclassified records get assigned a code, proposed as a new mode, or returned for correction; which cohorts and records belong in an evidence packet; when a packet is complete enough to submit; which data-quality issues need corrective action with a technician or bay. Success looks like: a Maintenance Supervisor turns raw field records into a defensible engineering case entirely from this console, without manually assembling evidence anywhere else.

3. Persona & Operating Context

3.1 Responsibilities

• Analyze confirmed and unclassified field records for patterns, root-cause rationale, and data quality.
• Build and submit Evidence Packets that become the PM’s engineering-feedback pipeline’s raw material.
• Clear the unclassified queue and monitor capture/validation fidelity across technicians and bays.

3.2 Working cadence

Daily: unclassified queue triage, records workbench review. Weekly: cohort investigation, data-quality review by technician/bay. Ad hoc: evidence-packet construction as a cohort or record set warrants engineering escalation.

3.3 Primary jobs to be done

• “What does the full evidence for this record actually look like — photos, telemetry, prior history?” → Records Workbench → Record Detail.
• “Is this vehicle’s failure part of a bigger pattern?” → Cohorts → Time-to-first-failure, Vehicle Timeline.
• “What do I do with this batch of unclassified records?” → Unclassified Queue.
• “I have enough evidence — help me turn it into a case TH Engineering will act on.” → Evidence-Packet Builder.
• “Which technicians or bays need coaching on capture quality?” → Data-Quality Console.
• “Where did my submitted packet go, and what’s its status?” → Escalations.

3.4 Decisions made here

• Assign an existing taxonomy code to an unclassified record, or propose a new mode / recommend a merge (never mint/promote/merge outright).
• Decide an Evidence Packet is complete and ready to submit.
• Flag a data-quality issue for corrective action with a named technician or bay.

3.5 Inputs received

• Confirmed and unclassified Tier-2 records, evidence (photos/telemetry), and validation outcomes from the mobile Maintenance Supervisor/Maintenance Technician Lead apps (out of scope, referenced as upstream).
• Cohort membership and recurrence data from the shared spine (same model the PM Console uses).

3.6 Outputs produced

• Classified records (assigned codes or proposed modes), submitted Evidence Packets, data-quality corrective-action flags.

3.7 Pressure points

• An incomplete or low-quality Evidence Packet reaching the PM pipeline wastes a PM’s time and erodes trust in Maintenance Supervisor-sourced evidence — the builder must enforce a real completeness gate, not just a submit button.
• Unclassified records left too long pollute every downstream reliability metric — the queue must make age and volume impossible to ignore.

3.8 What this role explicitly cannot do

• Cannot mint, promote, or merge a canonical taxonomy code under any circumstance, from either this console or the mobile validation gate — that authority is Head of Maintenance-exclusive (Argo Shared Operating Model §3). This console’s taxonomy actions are limited to Assign (an existing code), Propose (a new mode, routed to Head of Maintenance governance), and Recommend-merge (a suggestion, not an execution).
• Cannot casually duplicate the mobile Return-to-Service workflow — this console may inspect mobile validation outcomes read-only but has no RTS control of any kind.
• Cannot dispatch technicians, approve bay replenishment, or operate a Work Order’s dispatch/bay assignment — those are Head of Maintenance Console actions.

4. Goals, Non-Goals & Measurable Success Criteria

4.1 Product outcomes

• Unclassified queue age trending toward zero — no record sits unclassified past a defined SLA (default 5 business days) without an active flag.
• 100% of submitted Evidence Packets pass the builder’s own completeness gate before reaching the PM pipeline (never a manually-bypassed submission).

4.2 Operational outcomes

• Median time from record availability to packet submission trending down.
• Data-quality issues flagged here (by technician/bay) show measurable improvement quarter over quarter, tracked in the Data-Quality Console’s own trend.

4.3 Adoption & usability outcomes

• An Maintenance Supervisor completes the full evidence → packet → submission workflow without leaving the console or hand-assembling evidence elsewhere.

4.4 Data-quality outcomes

• Confirmed-record counts, cohort membership, and recurrence figures reconcile exactly with the PM/Head of Maintenance/VP Consoles at the same timestamp.

4.5 Explicit non-goals

• Not a repair-validation or RTS tool — that is the Maintenance Supervisor mobile app’s exclusive domain, referenced here only as a read-only source of validation outcomes. Not a dispatch, scheduling, or campaign-operations tool (Head of Maintenance Console). Not a roadmap or outcomes-modelling tool (PM Console) — this console’s engineering escalation ends at a submitted Evidence Packet; what happens to it afterward is the PM’s domain.

5. Role, Permission & Authority Model

Action	Maintenance Supervisor (desk)	Server-enforced rule
View records, cohorts, unclassified queue, data quality	Full	Read access requires role ∈ {Maintenance Supervisor, Maintenance Supervisor_DESK} — the same underlying Maintenance Supervisor identity used for the mobile validation gate, since it is one persona across two surfaces.
Assign an existing code to an unclassified record	Full	role ∈ {Maintenance Supervisor, Maintenance Supervisor_DESK}; the assigned code must exist in the current taxonomy (no free-text codes, per the Argo Field Flow Fixes Spec’s parts-picker precedent applied here to taxonomy assignment).
Propose a new mode / recommend a merge	Full (propose/recommend only)	role ∈ {Maintenance Supervisor, Maintenance Supervisor_DESK}; the action is Propose or Recommend, never Promote/Merge — those verbs and their transitions do not exist as available actions for any Maintenance Supervisor-tier role in this console, enforced by their absence from the API surface, not just a permission check.
Build, save-draft, and submit an Evidence Packet	Full	role ∈ {Maintenance Supervisor, Maintenance Supervisor_DESK}.
Flag a data-quality corrective action	Full	role ∈ {Maintenance Supervisor, Maintenance Supervisor_DESK}.
Export records / evidence	Full	All exports audit-logged with actor + timestamp + record scope.

5.1 Delegation and acting-role behaviour

No delegate tier is defined for this console — the Maintenance Supervisor is a single-altitude, individually-accountable analytical role; unlike the VP/PM/Head of Maintenance consoles, there is no lower-tier assistant role that performs draft work under a Maintenance Supervisor’s supervision. An Maintenance Supervisor covering another Maintenance Supervisor’s unclassified queue during absence does so under their own identity (visible in the audit trail as “handled by {covering Maintenance Supervisor} for {absent Maintenance Supervisor}’s queue”), not via a formal delegation mechanism.

5.2 Multi-bay and multi-role behaviour

An Maintenance Supervisor’s desk-analysis scope is not bay-limited by default — records, cohorts, and the unclassified queue are fleet-wide unless the Maintenance Supervisor applies an explicit bay/region filter (Section 13). This is a deliberate contrast with the Maintenance Supervisor’s mobile validation gate, which is inherently bay-scoped (the Maintenance Supervisor physically at that bay); the web console is where the same person analyzes beyond their own bay’s data.

5.3 Audit requirements

• Every code assignment, mode proposal, merge recommendation, and packet submission/revision is logged with actor/timestamp/rationale.

5.4 Forbidden actions and expected error responses

• Any attempt (client- or server-side) to invoke a Promote/Merge/Reject action from this console fails not with a 403 but with the action being genuinely absent from the UI and API — there is no endpoint to call, reinforcing that this is an architectural boundary, not a permission flag that could be toggled.
• Any attempt to execute a Return-to-Service transition from this console is rejected (404 — no such route exists here; RTS is mobile-exclusive per the Argo Shared Operating Model §2.24).

6. Complete Information Architecture

• Analysis Home — /fveweb/home
• Records — /fveweb/records (workbench) → /fveweb/records/:recordId (detail: evidence gallery, telemetry overlay, lineage, action inspector)
• Cohorts — /fveweb/cohorts → /fveweb/cohorts/:cohortId (detail, time-to-first-failure, cohort flow) → /fveweb/vehicles/:vehicleId (vehicle drill-down, reliability timeline)
• Unclassified — /fveweb/unclassified (queue) → /fveweb/unclassified/:recordId (assign/propose/merge/request-evidence/return)
• Evidence Packets — /fveweb/packets (list: draft/sent/acknowledged/returned/closed) → /fveweb/packets/new (builder) → /fveweb/packets/:packetId (detail, versions, status)
• Data Quality — /fveweb/quality (console) → /fveweb/quality/technician/:id → /fveweb/quality/bay/:id (drill-downs)
• Escalations — /fveweb/escalations (draft/sent/acknowledged/returned/closed packet tracking + comms history)
• Notifications — /fveweb/notifications
• Settings — /fveweb/settings (saved views, notification preferences, default record filters)

Figure 1 — Maintenance Supervisor Web Console sitemap.

6.1 Cross-surface deep links

• Record Detail’s WO reference deep-links to the Head of Maintenance Console’s WO Detail (read-only).
• Cohort Detail deep-links bidirectionally with the PM Console’s Cohort Detail (same cohort entity, both consoles show it at their own altitude — analytical/engineering here, product-decision there).
• A submitted Evidence Packet deep-links to its resulting Engineering-Feedback Item in the PM Console once converted (Section 15).
• A record’s mobile validation outcome (Gate #1/#2) deep-links read-only to whatever summary the mobile app’s own data provides — this console does not recreate the mobile validation UI.

6.2 Breadcrumbs, saved views, command palette

Breadcrumb pattern: Argo / Maintenance Supervisor Web Console / {section} / {sub-page}. Saved views apply to Records Workbench (filter/facet state), Cohorts (pivot state), Data Quality (technician/bay grouping). ⌘K destinations: any of the 8 routes; jump to a specific record/cohort/packet by ID; quick action “New evidence packet”; quick action “Next unclassified record.”

7. Complete Page Inventory

7.1 Analysis Home

Purpose: orient the Maintenance Supervisor on the state of field-evidence fidelity and pending analytical work. Entry: default landing route. Exit: every module links to its full page.

Modules, in visual order

• Header KPI band: unclassified queue count + oldest age, confirmed records this period, data-quality composite score, packets awaiting action (draft/returned).
• Cohort Flow (signature module) — see 7.1a for full spec; condensed 2-tier view here with “Full flow ›”.
• Records needing attention (top 10 by age or low-confidence flag) — condensed workbench rows; “Full workbench ›”.
• Recent packet activity (last 5 status changes) — “All packets ›”.

Cohort Flow — full definition (7.1a, signature module)

A Sankey-style flow diagram: left nodes are Tier-1 observed capture codes; middle nodes are confirmed Tier-2 codes; right nodes are Cohorts. Flow-width encodes record volume. Purpose: visually answer “how do field captures actually resolve into confirmed causes, and which cohorts do they feed” — directly surfacing diagnostic-skill signal (which Tier-1 guesses map cleanly to one Tier-2 cause vs. scatter across several, per the Argo Shared Operating Model §2.4’s stated analytical value).

• Interaction: hover any flow band for exact count and percentage; click a Tier-1 or Tier-2 node to filter the Records Workbench to matching records; click a Cohort node to open Cohort Detail.
• States: skeleton on load; “insufficient volume to render a flow” empty state if fewer than 20 records exist in the selected window (a Sankey with too few records is misleading, not just visually thin).

Acceptance

• Every flow band’s count reconciles with the Records Workbench’s own filtered count for the same Tier-1/Tier-2/Cohort combination.

7.2 Records Workbench (3-pane)

Purpose: the Maintenance Supervisor’s primary investigative surface — records rail, record detail, and action inspector, mirroring the Head of Maintenance Console’s workbench pattern at this console’s altitude.

Pane 1 — Records rail

• List of confirmed and unclassified records, each row: record ID, vehicle, Tier-1 capture code, Tier-2 confirmed code (or “Unclassified”), capture confidence, root-cause confidence (shown as two distinct fields, never conflated, per the Argo Shared Operating Model §0 C11), bay, date, reproduced-on-retest flag.
• Filter facets: classification status (Confirmed/Unclassified), bay, date range, confidence level (either field, selectable), cohort membership.
• Sort: default date descending; sortable by any column.

Pane 2 — Record Detail (engineering-grade)

• Header: record ID, vehicle context (plate/VIN/VCU, canonical ID pending [VERIFY-1]), Tier-1 → Tier-2 summary.
• Evidence gallery: every photo captured at fault-capture and at repair/RTS validation, in a lightbox-capable grid, with capture timestamp and which gate it was attached to.
• Telemetry-at-fault overlay: a time-series chart of available telemetry channels (voltage, temperature, CAN error rate, etc., whichever the vehicle’s VCU reports) windowed around the fault timestamp, with the fault moment marked — lets the Maintenance Supervisor visually correlate the confirmed cause with the actual sensor behavior, not just trust the technician’s note.
• Prior cases & recurrence lineage: every previous WO on this vehicle sharing the same or a related Tier-2 code, as a mini recurrence-chain timeline (reused pattern from the PM Console’s Vehicle Reliability Timeline, Argo Shared Operating Model-consistent).
• Tier-1 vs. Tier-2 comparison: side-by-side display of what was captured in the field vs. what was ultimately confirmed — explicitly flagged when they differ, since this is the diagnostic-skill signal the whole two-tier model exists to produce.
• Confirmed-cause rationale: the technician’s corrective-action note and the Maintenance Supervisor-mobile-gate’s root-cause confidence and reproduced-on-retest outcome (read-only, sourced from the mobile validation gate).
• Parts & serial lineage: the accepted requisition’s parts and serials bound to this WO (read-only, per the Argo Shared Operating Model §2.22).
• Validation history: both Gate #1 and Gate #2 outcomes (validated/returned, with reasons if returned) — read-only mirror of the mobile validation gate’s record, never re-editable here.

Pane 3 — Action Inspector

• For an unclassified record: quick actions mirroring the Unclassified Queue’s detail actions (Section 7.3) without leaving the workbench.
• For any record: “Add to evidence packet” (opens or adds to an in-progress packet draft, Section 7.4) and “Flag data-quality issue” (Section 7.5).

States & acceptance

• Selecting a rail row updates Panes 2/3 in place — no full page navigation, matching the Head of Maintenance Console’s established workbench pattern for consistency across Argo’s web consoles.
• Acceptance: the Telemetry-at-fault overlay gracefully shows “no telemetry available for this window” rather than an empty chart when the vehicle was telemetry-dark at the time (Shared Operating Model §5 Unknown-slice consistency).

7.3 Cohorts

Purpose: the Maintenance Supervisor’s own cohort investigation view — narrower and more evidence-grounded than the PM Console’s cohort analytics workbench, focused on “is this pattern real and where’s the evidence” rather than “what should we do about it.”

Cohort list

• Columns: cohort name/type, member count, recurrence rate (with sample size on hover), status, linked code(s), unclassified-record count within this cohort (a signal specific to this console — a cohort with many unclassified records needs Maintenance Supervisor attention before it can even be analyzed reliably).

Cohort Detail

• Time-to-first-failure analysis: a distribution chart of how long after entering service (or after a kit-revision/batch install date) vehicles in this cohort first exhibit the linked fault — the Maintenance Supervisor’s core “is this a manufacturing defect vs. wear-and-tear” analytical tool.
• Cohort flow scoped to this cohort: the same Sankey pattern as 7.1a, filtered to this cohort’s records.
• Member vehicles table with “View timeline ›” per row (Section 7.3a).
• Action: “Start evidence packet from this cohort ›” (Section 7.4, pre-scoped).

7.3a — Vehicle Drill-Down & Reliability Timeline

Same signature micro-module referenced in the PM Console (Argo Shared Operating Model-consistent reuse): a horizontal timeline of every Signal/WO for the vehicle, colour-coded by outcome, hoverable, clickable to read-only WO detail.

States & acceptance

• A cohort with a high unclassified-record count shows a persistent banner (“N unclassified records in this cohort — investigate before relying on this recurrence rate”) since an unresolved classification backlog directly undermines the reliability of this cohort’s own statistics.

7.4 Unclassified Queue

Purpose: the Maintenance Supervisor’s cleared-daily backlog of records that arrived without a confirmed Tier-2 code (e.g., a Tier-1 capture whose teardown found something not in the current taxonomy, or a record referred here for review).

Queue

• Columns: record ID, vehicle, Tier-1 capture code, bay, age, capture confidence, why-unclassified reason (no matching Tier-2 candidate / technician deferred / referred by Head of Maintenance).
• Age-based urgency tag (amber past 3 business days, red past 5 — the SLA referenced in Section 4.1).

Record actions (also available from Records Workbench’s Action Inspector, Section 7.2)

• Assign an existing code: search/select from the current taxonomy (no free text, mirroring the Argo Field Flow Fixes Spec’s parts-picker principle applied to taxonomy) — record becomes Confirmed.
• Propose a new mode: opens a structured proposal form (system, component, proposed mode name, rationale, supporting evidence from this record) — submits to the Head of Maintenance Console’s Taxonomy Governance queue as Raised-then-immediately-Endorsed-by-this-Maintenance Supervisor (since the Maintenance Supervisor proposing here is already performing the endorsement function analytically) — record remains Unclassified pending the Head of Maintenance’s Promote/Merge/Reject decision, then auto-updates once resolved.
• Merge recommendation: flags to the Head of Maintenance that this record likely duplicates an existing code’s failure mode, with the suggested target code — a recommendation, not an executed merge (Section 5).
• Request additional evidence: routes back to the originating technician (mobile, out of scope) with a note describing what’s missing — record remains Unclassified, now flagged “awaiting more evidence.”
• Return for correction: if the record’s Tier-1 capture itself looks wrong (not just under-evidenced), returns to the technician with a reason — distinct from Request-additional-evidence in that it questions the capture itself, not just its completeness.

States & acceptance

• Empty state: “Unclassified queue is clear.” A record proposed as a new mode shows a persistent “pending Head of Maintenance decision” status in this queue until resolved — never silently disappears while awaiting governance action.
• Acceptance: every action produces a durable, auditable state change (Section 9.5) — no action here ever just dismisses a record without a recorded outcome.

7.5 Evidence-Packet Builder & Packet Management

Purpose: the console’s terminal deliverable workflow — the “bundle flow” pattern the foundational brief calls for, applied to turning field evidence into a defensible engineering case.

Builder — step by step

• Select scope: a Cohort (pre-filled if launched from Cohort Detail) or an explicit record set (multi-select from Records Workbench).
• Auto-pull: the system automatically pulls matching records, photos, telemetry snapshots, and the relevant charts (recurrence curve, time-to-first-failure) into a draft packet.
• Include/exclude and reorder: the Maintenance Supervisor curates which auto-pulled evidence items actually go into the packet and in what order they’re presented — not every auto-pulled item is necessarily relevant.
• Add engineering narrative and recommendation: required rich-text fields — a packet’s auto-pulled data alone is never sufficient; the Maintenance Supervisor’s own analytical narrative and a specific recommendation are mandatory.
• Validate completeness: a system-enforced gate checks: at least 1 record, narrative non-empty, recommendation non-empty, at least 1 evidence item (photo or telemetry chart) included. Submit is disabled until all pass, each shown individually (not a single “incomplete” blob).
• Preview: renders the packet exactly as the PM Console will receive it.
• Save draft: at any point, resumable later.
• Submit: packet status → Submitted, lands in the PM Console’s Evidence-Packet Inbox (Section 15).
• Revise (if returned): editing a Returned packet creates a new version (v2, v3, …) with a visible changelog against the prior version — never a silent overwrite, per the Argo Shared Operating Model §2.10/§7.3 versioning rule.
• Version: every submission after the first is explicitly tagged “revised” in the PM’s inbox, prioritized by original submission date (not re-queued to the back), per the Shared Operating Model’s anti-gaming rule.
• Share: a read-only shareable link (internal only) for a draft packet, e.g., to get a second Maintenance Supervisor’s eyes on it before submission — does not submit on its own.

Packet list (draft/sent/acknowledged/returned/closed)

• Columns: title, scope (cohort/record count), version, status, submitted date, last status-change date.

Packet Detail

• Full packet content (as submitted), version history with diffs, current status, and — once acknowledged/converted — a deep link to the resulting PM Console Engineering-Feedback Item (Section 15).

States & acceptance

• A packet cannot be Submitted while its completeness gate fails — enforced client- and server-side, with each failing criterion individually named in the UI.
• Acceptance: a Returned packet’s revision produces a genuinely new version with a diff, and re-submission is visibly flagged “revised” in the PM Console per the Shared Operating Model’s rule.

7.6 Data-Quality Console

Purpose: an interactive QA console — the metric definitions the foundational brief specifically called out as needing to become real (not static tiles).

Metrics, each with a full definition (see also Section 12)

• Captured-at-source completeness: % of Tier-1 captures with all required fields (code, confidence, evidence) present at time of capture.
• Unclassified rate: % of records remaining unclassified past the SLA window, trended.
• Non-fault pollution rate: % of triaged “Confirmed fault” cases that were ultimately triaged not-a-fault at a later stage — a signal of over-eager escalation.
• Complaint-not-reproduced rate: % of not-a-fault closures specifically due to “Complaint not reproduced” (Argo Field Flow Fixes Spec REQ-12 reason set) — distinguishing a genuine intermittent-fault problem from a triage-quality problem.
• Return-to-service failure rate: % of Gate #2 submissions returned (send-back), i.e., the inverse of the PM/Head of Maintenance Consoles’ first-pass validation rate, shown here with technician/bay breakdown.
• Completeness: overall composite score combining the above.

Drill-downs

• By technician: a ranked table, each technician’s individual rates for the metrics above, with a trend sparkline — enables targeted coaching rather than blanket policy.
• By bay: same breakdown aggregated per bay, surfacing systemic (vs. individual) quality issues.
• Issue drill-down: clicking any metric/technician/bay cell opens the specific underlying records driving that number (never a bare percentage with no way to see what’s behind it).

Corrective action

• “Flag corrective action” on a technician or bay row: opens a structured note (issue description, recommended action) that is logged and trended over time — this console does not have HR/disciplinary authority, only a documented, visible quality-coaching record.

States & acceptance

• Every metric cell is drill-through to its underlying records — the explicit anti-decorative-chart requirement from the foundational brief and this document’s own instruction that no chart may lack a metric definition or drill-down.

7.7 Escalations

Purpose: tracks the exact boundary where Argo hands off to TH Engineering — every packet’s full communication and status history in one place, distinct from the Packet Management list (Section 7.5) in that this view emphasizes the conversation/handoff history over the packet content itself.

Escalations list

• Columns: packet title, current status (Draft/Sent/Acknowledged/Returned/Closed), last activity date, PM contact (once acknowledged).

Escalation Detail

• Full status timeline: Draft created → Sent (submitted) → Acknowledged (PM converted it, per PM-FR-001 in the PM Console PRD) → (Returned with reason, cycling back to Draft-revision) → Closed (PM’s linked Engineering-Feedback item reached a terminal or Confirmed-Impact state, mirrored read-only here) — each entry with actor/timestamp/note.
• Comms history: any comments/notes exchanged between the Maintenance Supervisor and PM on this packet (e.g., a Return reason, a clarifying question) — a lightweight threaded log, not a full messaging system.

The exact Argo → TH Engineering boundary

Per the explicit scope boundary in this document’s brief: this console’s engineering escalation ends at a structured, submitted Evidence Packet routed into the PM’s engineering-feedback pipeline. Once the PM converts a packet into an Engineering-Feedback Item, further prioritization, roadmap linkage, and any external TH Engineering system interaction ([VERIFY-6]) are entirely the PM Console’s domain — this console’s Escalation Detail shows that downstream status read-only (via the Closed/terminal mirror above) but has no controls to act on it.

States & acceptance

• Acceptance: every escalation’s status timeline is fully reconstructable from the audit log — no status change here or in the PM Console ever appears without a corresponding timeline entry visible from this side.

7.8 Notifications

Scoped to Maintenance Supervisor-Web-relevant event types: a record becomes eligible for a packet (e.g., cohort crosses a volume threshold suggesting enough evidence exists), a packet is Acknowledged/Returned/Closed by the PM Console, a data-quality metric crosses a concerning threshold, an unclassified record ages past its SLA, a taxonomy proposal this Maintenance Supervisor endorsed is Promoted/Merged/Rejected by Head of Maintenance.

• List, bulk mark-read, snooze, deep link — identical generic behaviour to the other consoles’ Notification Centres (Shared Operating Model §6).

7.9 Settings

• Saved views (Records Workbench filters, Cohort pivots, Data-Quality groupings).
• Notification preferences, default record filters, default bay/region scope for the Records rail.

8. Functional Requirements

Maintenance SupervisorW-FR-001 — Assign an existing taxonomy code to an unclassified record

The Maintenance Supervisor classifies an unclassified record by assigning it a code already in the canonical taxonomy.

• Actor: Maintenance Supervisor
• Preconditions: Record status = Unclassified.
• Trigger: Maintenance Supervisor searches/selects a code from the Unclassified Queue or Records Workbench Action Inspector and confirms.
• Happy path: Record’s Tier-2 confirmed code is set to the selected canonical code; record status → Confirmed; timeline entry appended.
• Alternate paths: Maintenance Supervisor instead Proposes a new mode (Maintenance SupervisorW-FR-002) if no existing code fits.
• Validation: Only codes that exist in the current taxonomy version may be selected — no free-text entry, mirroring the parts-picker principle from the Argo Field Flow Fixes Spec applied here to taxonomy assignment.
• Permission rule: role ∈ {Maintenance Supervisor, Maintenance Supervisor_DESK}.
• State transition: Record: Unclassified → Confirmed.
• Data side effects: Record’s Tier-2 field set; timeline/audit entry appended with actor/timestamp/selected code.
• Notification side effects: None required by default.
• Downstream surface effects: The now-Confirmed record contributes to cohort/reliability metrics in the PM/Head of Maintenance/VP Consoles within one refresh cycle (previously excluded as unclassified).
• Failure & recovery: If the write fails, the record remains Unclassified with an inline retry — no partial/ambiguous classification state.
• Acceptance criteria: The record’s Tier-2 code is visible everywhere the record appears (Records Workbench, Cohort membership, PM Console cohort analytics) within one refresh cycle.

Maintenance SupervisorW-FR-002 — Propose a new taxonomy mode from an unclassified record

The Maintenance Supervisor proposes a new canonical mode when no existing code fits an unclassified record’s evidence.

• Actor: Maintenance Supervisor
• Preconditions: Record status = Unclassified.
• Trigger: Maintenance Supervisor completes the structured proposal form (system, component, proposed mode name, rationale, supporting evidence) and submits.
• Happy path: A new Taxonomy Proposal is created in the Head of Maintenance Console’s governance queue with status Endorsed (the Maintenance Supervisor’s analytical review here counts as endorsement, per the Argo Shared Operating Model’s raise→endorse chain — this Maintenance Supervisor is performing the endorsing function, not merely raising); the record remains Unclassified, tagged “pending Head of Maintenance decision.”
• Alternate paths: Maintenance Supervisor instead makes a Merge recommendation if the evidence suggests a duplicate of an existing code rather than a genuinely new one.
• Validation: System/component/mode-name/rationale all required, non-empty.
• Permission rule: role ∈ {Maintenance Supervisor, Maintenance Supervisor_DESK} — this action creates a Proposal, never a Promote/Merge/Reject, which remain architecturally unavailable from this console (Section 5.4).
• State transition: Taxonomy Proposal: (none) → Endorsed. Record: remains Unclassified, tagged pending-decision.
• Data side effects: New Proposal record created, linked to the originating record’s evidence; Maintenance Supervisor’s action recorded as the endorsement step in the proposal’s audit trail.
• Notification side effects: Head of Maintenance notified a new Endorsed proposal awaits decision.
• Downstream surface effects: Proposal appears in the Head of Maintenance Console’s Taxonomy Governance queue (Section 7.6 of that PRD) within one refresh cycle, ready for Promote/Merge/Reject.
• Failure & recovery: If proposal creation fails, the record remains Unclassified with no orphaned partial proposal — an inline retry is offered.
• Acceptance criteria: The record’s “pending Head of Maintenance decision” tag automatically clears and updates to the resolved code once the Head of Maintenance acts, without further Maintenance Supervisor action required.

Maintenance SupervisorW-FR-003 — Build and submit an Evidence Packet

The Maintenance Supervisor assembles field evidence into a structured, versioned packet and submits it into the PM’s engineering-feedback pipeline.

• Actor: Maintenance Supervisor
• Preconditions: At least one record or cohort is selected as scope.
• Trigger: Maintenance Supervisor completes the builder (Section 7.5): scope, auto-pulled evidence curated, narrative and recommendation written, and clicks Submit.
• Happy path: System validates completeness (≥1 record, non-empty narrative, non-empty recommendation, ≥1 evidence item); on pass, packet status → Submitted; lands in the PM Console’s Evidence-Packet Inbox.
• Alternate paths: Maintenance Supervisor instead Saves as draft (no submission) or Shares a read-only link for a second opinion before submitting.
• Validation: Each of the four completeness criteria is individually validated and individually shown if failing — Submit is disabled, not just unvalidated, until all pass.
• Permission rule: role ∈ {Maintenance Supervisor, Maintenance Supervisor_DESK}.
• State transition: Evidence Packet: Draft → Submitted.
• Data side effects: Packet record created/finalized with full content snapshot at v1 (or v(n) if this is a resubmission per Maintenance SupervisorW-FR-004).
• Notification side effects: PM (and PM Analyst, if configured) notified of the new packet awaiting triage.
• Downstream surface effects: Packet appears in the PM Console’s Evidence-Packet Inbox within one refresh cycle with identical content to what the Maintenance Supervisor built — no re-entry required by the PM.
• Failure & recovery: If Submit fails server-side, the packet remains Draft with all curated content preserved (no data loss) and an inline retry.
• Acceptance criteria: A submitted packet’s content in the PM Console’s inbox exactly matches the Maintenance Supervisor’s Preview — verified by content-hash comparison in the reconciliation tests.

Maintenance SupervisorW-FR-004 — Revise a Returned Evidence Packet

The Maintenance Supervisor revises a packet the PM returned for correction, producing a new version rather than overwriting the original.

• Actor: Maintenance Supervisor
• Preconditions: Packet status = Returned.
• Trigger: Maintenance Supervisor edits the packet content addressing the PM’s return reason and clicks Submit again.
• Happy path: System creates version v(n+1) with a visible diff/changelog against v(n); packet status → Submitted, explicitly tagged “revised”; re-enters the PM’s inbox prioritized by original submission date (not re-queued to the back), per the anti-gaming rule.
• Alternate paths: None — a Returned packet’s only forward path is Revise-and-resubmit or abandon (remains Returned indefinitely, visible in Escalations as stalled).
• Validation: Same completeness gate as Maintenance SupervisorW-FR-003 applies to the revised version.
• Permission rule: role ∈ {Maintenance Supervisor, Maintenance Supervisor_DESK}.
• State transition: Evidence Packet: Returned → Submitted (v(n+1)).
• Data side effects: New version record created; prior version retained and viewable via Packet Detail’s version history; changelog computed and stored.
• Notification side effects: PM notified the packet was revised and resubmitted, with a direct diff link.
• Downstream surface effects: The PM Console’s inbox shows the packet as “revised,” prioritized by original submission date per the Shared Operating Model’s rule.
• Failure & recovery: None special beyond standard save-failure retry.
• Acceptance criteria: The version history shows an unbroken chain from v1 through the current version, each with its own diff, never a silently-replaced single record.

9. Entity & Lifecycle Definitions

The Maintenance Supervisor Web Console owns Evidence Packet outright (full definition in the Argo Shared Operating Model §2.10, reused verbatim) and shares write access (Assign/Propose/Recommend only, never Promote/Merge) to Record classification. It consumes, read-only, Work Order, Cohort, and mobile validation-outcome data.

9.1 Evidence Packet

Status	Entry	Exit	Set by
Draft	Builder started.	Submitted, or abandoned (remains Draft).	Maintenance Supervisor
Submitted	Maintenance Supervisor submits (Maintenance SupervisorW-FR-003) or revises-and-resubmits (Maintenance SupervisorW-FR-004).	Acknowledged, Returned, or (rarely) withdrawn by the Maintenance Supervisor before PM action.	Maintenance Supervisor → PM
Acknowledged	PM converts to an Engineering-Feedback item (PM-FR-001).	Terminal from this console’s perspective — tracks the linked Feedback item’s lifecycle read-only from here (Closed once that item reaches a terminal state).	PM
Returned	PM returns for correction, reason required.	Submitted (new version, Maintenance SupervisorW-FR-004), or abandoned (remains Returned).	PM
Closed	Linked Engineering-Feedback item reaches a terminal or Confirmed-Impact state (mirrored read-only).	Terminal.	System (mirrors PM Console state)

9.2 Record classification status (shared with, not owned exclusively by, this console)

Status	Entry	Exit	Set by
Unclassified	Tier-1 captured but no Tier-2 code fits or was assigned at repair.	Confirmed (via Maintenance SupervisorW-FR-001) or remains Unclassified pending a Proposal (Maintenance SupervisorW-FR-002).	System (on capture without resolution) / Technician (mobile)
Confirmed	A canonical Tier-2 code is assigned (mobile resolution, or Maintenance SupervisorW-FR-001).	Terminal for classification purposes (may still be re-labelled if its code is later merged, per the Shared Operating Model §8 rule 6).	Technician (mobile) / Maintenance Supervisor (this console)

Note: Taxonomy Proposal itself (Raised/Endorsed/Promoted/Merged/Rejected) is owned by the Head of Maintenance Console (see that PRD’s Section 9.4) and reused here read-only, with this console’s Maintenance SupervisorW-FR-002 action creating proposals that enter that lifecycle already at Endorsed.

10. End-to-End Workflows

10.1 Unclassified record → Confirmed or Proposed → resolved

• Initiator: a record arrives Unclassified (Technician’s mobile capture found no fitting Tier-2 code at repair, or was explicitly referred here).
• Maintenance Supervisor reviews in the Unclassified Queue or Records Workbench.
• Path A: Maintenance Supervisor Assigns an existing code (Maintenance SupervisorW-FR-001) → record Confirmed immediately.
• Path B: Maintenance Supervisor Proposes a new mode (Maintenance SupervisorW-FR-002) → Proposal created Endorsed → Head of Maintenance Promotes/Merges/Rejects (Head of Maintenance Console) → record’s tag resolves automatically.
• Terminal state: record is Confirmed with a canonical code either way, contributing correctly to every downstream reliability metric.

Figure 2 — Cross-surface interaction, Maintenance Supervisor Web Console highlighted.

10.2 Evidence Packet → Engineering-Feedback Item (the handoff to TH Engineering)

• Initiator: Maintenance Supervisor, from a Cohort Detail or a curated record set.
• Builder: auto-pull, curate, narrative, completeness gate, submit (Maintenance SupervisorW-FR-003).
• PM Console: packet appears in the Evidence-Packet Inbox, PM converts it (PM-FR-001, that PRD).
• If returned: Maintenance Supervisor revises (Maintenance SupervisorW-FR-004), producing a new version, re-entering the pipeline without losing queue priority.
• Terminal state (from this console’s view): packet Closed once the linked Engineering-Feedback Item reaches a terminal or Confirmed-Impact state in the PM Console — the exact Argo → TH Engineering boundary (Section 7.7).

11. Data Requirements

Field	Definition
Source entities (owned)	Evidence Packet (Section 9.1); record classification write access (shared, Section 9.2).
Source entities (consumed)	Work Order, Cohort, Vehicle, Taxonomy (read-only reference), mobile validation outcomes — all read via the shared spine.
Canonical IDs	Record/WO/Cohort/Vehicle IDs always referenced from their owning source; this console mints only Evidence Packet IDs.
Freshness	Records Workbench and Cohorts: real-time (no cache) given their investigative, decision-supporting nature. Data-Quality Console: cached 15 minutes with explicit “as of” timestamp.
Aggregation level	Individual-record level throughout the workbench; cohort-level for cohort investigation; technician/bay level for data quality.
Retention	Evidence Packets (all versions) retained indefinitely; record classification history retained indefinitely (audit integrity).
Data-quality rules	No record ever displays a Tier-2 code that isn’t a valid current (or explicitly superseded-and-annotated) canonical taxonomy entry.
Missing-data behaviour	Telemetry-at-fault overlay shows “no telemetry available” rather than an empty/misleading chart when the vehicle was telemetry-dark at the fault time.
Stale-data indicators	Explicit stale tag on the Data-Quality Console’s cached view past 2× its refresh interval.
Reconciliation rules	Confirmed-record counts, cohort membership, and recurrence figures reconcile exactly with the PM/Head of Maintenance/VP Consoles (Section 20 tests).
Export schema	Record export (CSV): record_id, vehicle_id, tier1_code, tier2_code, capture_confidence, root_cause_confidence, bay, date, reproduced_flag. Evidence Packet export (PDF): full packet content as submitted, with version marker.

12. Metrics & Analytical Definitions

Metric	Numerator / denominator	Window	Drill-down	Incomplete-data behaviour
Captured-at-source completeness	Tier-1 captures with all required fields present ÷ total captures	Rolling 30-day	→ Data-Quality Console, by technician/bay	n/a below 10 captures in window for a given technician; shows raw count
Unclassified rate	Records unclassified past SLA ÷ total records in window	Rolling 30-day, SLA default 5 business days	→ Unclassified Queue filtered to overdue	Age distribution always shown alongside the rate, never just a bare percentage
Non-fault pollution rate	Confirmed-fault triages later reclassified not-a-fault ÷ total confirmed-fault triages	Rolling 30-day	→ Data-Quality Console issue drill-down	Requires the full triage-to-closure lineage; shows “pending” for cases not yet closed rather than assuming non-pollution
Complaint-not-reproduced rate	Not-a-fault closures with reason = Complaint not reproduced ÷ total not-a-fault closures	Rolling 30-day	→ Data-Quality Console issue drill-down	n/a below 10 closures; shows raw count
Return-to-service failure rate (Gate #2 send-back rate)	Gate #2 submissions returned ÷ total Gate #2 submissions	Rolling 30-day	→ Data-Quality Console, by technician/bay	n/a below 10 submissions; shown alongside the PM/Head of Maintenance Consoles’ first-pass validation rate (the same figure, inverse framing)
Time-to-first-failure (cohort)	Days from install/service-entry date to first linked-fault occurrence, distribution across cohort members	Cohort lifetime	→ Cohort Detail time-to-first-failure chart	Vehicles with no failure yet shown as right-censored in the distribution, never excluded or treated as zero

13. Search, Filtering & Navigation

• Global search (⌘K): records, cohorts, packets, by ID/vehicle/free-text.
• Faceted filters: Records Workbench by classification status/bay/date/confidence/cohort; Cohorts by status/type; Data Quality by technician/bay; Unclassified Queue by age/reason.
• Compound filters combine AND within and across facet groups.
• Saved views: named, persisted per user, settable default, reset returns to system default.
• No-results behaviour: explicit message + Clear filters action.
• Recent items: last 10 visited record/cohort/packet detail pages in ⌘K.
• Deep links: every notification and cross-console reference resolves to the exact record, never a generic list.

14. Notifications & Event Contract

Follows the Argo Shared Operating Model §6 generic contract exactly.

Trigger	Recipient	Channel	Priority	Deep link
Cohort crosses a volume threshold suggesting packet-worthy evidence	Maintenance Supervisor	In-app + Notification Centre	Normal	Cohort Detail
Packet Acknowledged / Returned / Closed	Maintenance Supervisor	In-app + push + Notification Centre	Normal (High if Returned)	Packet Detail
Data-quality metric crosses a concerning threshold	Maintenance Supervisor	In-app + Notification Centre	Normal	Data-Quality Console
Unclassified record ages past SLA	Maintenance Supervisor	In-app + Notification Centre	Escalating (Normal → High)	Unclassified Queue row
Endorsed taxonomy proposal Promoted / Merged / Rejected by Head of Maintenance	Maintenance Supervisor	In-app + Notification Centre	Normal	Record Detail (resolved classification)

15. Integrations & Cross-Surface Effects

• PM Console: the exclusive downstream recipient of submitted Evidence Packets, which it converts into Engineering-Feedback Items (PM-FR-001); this console reads that item’s status back read-only via the Closed mirror (Section 9.1).
• Head of Maintenance Console: owns Taxonomy Governance; this console’s Propose/Recommend actions feed its Proposed Modes queue, and this console reads Promote/Merge/Reject outcomes back read-only.
• Maintenance Technician Lead mobile / Maintenance Supervisor mobile (out of scope, referenced only): source of all Tier-1 capture, Tier-2 resolution, evidence photos, telemetry snapshots, and validation-gate outcomes this console analyzes; this console never edits mobile-originated capture or validation data, only classifies previously-unclassified records and builds evidence artifacts from it.
• VP Console: consumes this console’s data-quality metrics indirectly via the PM/Head of Maintenance Consoles’ own reliability roll-ups; no direct VP integration surface exists here.
• Auth / role management [VERIFY-7]: consumes role=Maintenance Supervisor / Maintenance Supervisor_DESK assignments from an external identity source of record — the same Maintenance Supervisor identity used for the mobile validation gate.
• Exports: Record CSV and Evidence Packet PDF exports generated in-console.

16. Non-Functional Requirements

• Performance budgets: Analysis Home first-meaningful-paint under 2s; Records Workbench pane-switch under 300ms perceived latency; Telemetry-at-fault overlay renders within 3s or shows an explicit loading state.
• Staleness handling: Records/Cohorts real-time; Data-Quality Console cached 15 minutes with stale tag past 2× interval.
• Security & access control: Promote/Merge/Reject are architecturally absent (Section 5.4), not merely permission-gated; all other write actions server-enforced by role.
• Auditability: every classification action, proposal, and packet version permanently logged with actor/timestamp/rationale.
• Accessibility: WCAG 2.1 AA; Cohort Flow (Sankey) and telemetry charts have text-equivalent summaries; evidence-gallery lightbox is fully keyboard-navigable.
• Keyboard navigation: full ⌘K and Tab/Enter traversal, including 3-pane workbench and the evidence-packet builder’s multi-step flow.
• 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 rider-identifying data beyond what’s necessary for vehicle/complaint context; evidence photos are vehicle/component-focused per existing mobile-capture guidance.
• Export protection: every export logged with actor/timestamp/scope; “Confidential — Vehicle Operations” footer on all exports.
• Error recovery: module-level failure isolation on Analysis Home; workbench panes fail independently.

17. Complete UI-State Catalogue

State	General rule applied across this console
Initial loading	Skeleton shimmer on the records rail, cohort flow, and KPI band.
Partial loading	Analysis Home modules and Records Workbench panes load independently.
Populated	Standard rendered state with “as of” timestamp where cached (Data-Quality Console only).
Selected	Selected record row highlights and updates Panes 2/3 in place; selected cohort-flow node highlights its filtered records.
Hover	Row hover reveals actions; chart hover shows crosshair + exact value; flow-band hover shows count + percentage.
Focus	Visible focus ring on every interactive element, including evidence-gallery thumbnails.
Disabled	Submit (packet) disabled with an explanatory tooltip naming the failing completeness criterion until all pass.
Empty	Canonical empty state with specific message (e.g., “Unclassified queue is clear”, “No telemetry available for this window”).
Filtered-empty	“No results for these filters” + Clear filters action.
Error	Inline retry banner scoped to the failed module/pane only.
Recoverable error	Retry re-fetches just the failed module/pane.
Permission denied	404 for architecturally-absent actions (Promote/Merge/Reject/RTS, Section 5.4); 403 for any genuine role-permission violation.
Stale data	Explicit stale tag on the Data-Quality Console past 2× refresh interval.
Connection lost	Persistent banner; write actions (assign/propose/submit) queued/disabled until reconnection.
Optimistic update	Not used for Submit/Propose/Assign (server-confirmed only, given downstream governance/pipeline consequences).
Update conflict	Concurrent edits to the same packet draft (e.g., Maintenance Supervisor editing in two tabs) surface a conflict dialog requiring explicit re-confirmation.
Destructive confirmation	Submit (packet) and Propose (new mode) show a lightweight confirm step stating the exact consequence (“This will submit to the PM pipeline” / “This will create a governance proposal for Head of Maintenance”).
Completed / success	Specific success state naming what changed (“Packet submitted — awaiting PM triage”), never a generic toast.

18. Edge Cases & Failure Scenarios

• A record is added to an in-progress Evidence Packet draft, then later gets re-classified (e.g., its taxonomy code is merged mid-draft): the packet’s evidence panel shows a “scope changed since added” flag rather than silently including stale classification data at submission time.
• Two Maintenance Supervisors independently propose new modes for what is actually the same underlying failure: the Head of Maintenance Console’s duplicate-detection flag (that PRD’s Section 18) surfaces this; from this console’s side, both proposing Maintenance Supervisors are notified when Head of Maintenance merges the duplicate, each seeing their own record’s resolution correctly (not just one of the two).
• A cohort’s membership changes (vehicle withdrawn) while an Evidence Packet built from that cohort is still in Draft: the builder shows a live “cohort membership changed” warning before Submit, consistent with the PM Console’s equivalent edge case, so the packet doesn’t submit against a stale scope.
• Missing evidence: a technician’s fault-capture photo upload failed silently on the mobile side (out of scope to fix here, but this console must degrade gracefully) — the Record Detail’s evidence gallery shows “no photo evidence captured” rather than a broken image icon, and the Evidence-Packet Builder’s completeness gate correctly evaluates whether other evidence types (telemetry, narrative) can satisfy the ≥1-evidence-item requirement.
• Low-confidence cause on a record being added to a packet: the builder does not block inclusion but visually flags the record’s confidence level inline in the packet preview, so the resulting packet never implies false certainty.
• A taxonomy proposal this Maintenance Supervisor endorsed is Merged (not Promoted) by Head of Maintenance: the originating record’s tag resolves to the surviving code, and the record’s history shows “originally proposed as {proposal}, resolved via merge to {surviving code}” — full traceability preserved, per the Shared Operating Model §8 rule 6.
• A record referenced in an already-Submitted (and Acknowledged) Evidence Packet is later reclassified (its taxonomy code merged): the packet itself (already handed off) is not retroactively altered — it remains a faithful snapshot of what was known at submission time — but the Record Detail’s live view reflects the current classification, and the Escalation Detail notes the discrepancy for transparency if the PM later cross-references it.
• Failed evidence-packet PDF export: the Submitted/Acknowledged record itself is unaffected (already durable in the pipeline); export retries, with a raw-content fallback.
• Unclassified queue backlog spikes suddenly (e.g., a batch of records from a new bay onboarding): the queue’s age-based urgency tagging surfaces the spike immediately rather than treating all records as equally low-priority, and the Data-Quality Console’s unclassified-rate trend visibly reflects the spike rather than smoothing it away.
• Downstream system unavailable (PM Console’s Evidence-Packet Inbox temporarily unreachable): Submit remains available (the packet transitions to Submitted in this console’s own system of record) with a “delivery pending” indicator until the PM Console confirms receipt — never a silent submission that the Maintenance Supervisor has no way to verify landed.

19. Product Analytics

• Events instrumented: page_view, record_classified_assign, record_proposed_new_mode, record_merge_recommended, record_evidence_requested, record_returned_for_correction, packet_draft_started, packet_submitted, packet_revised, packet_shared, dq_corrective_action_flagged.
• Key funnels: Unclassified record → Assigned/Proposed → Confirmed (time-to-classification); Packet draft started → submitted → acknowledged/returned → closed (the full evidence-to-impact funnel, cross-referencing the PM Console’s own funnel).
• Task success: % of unclassified records resolved within the SLA window.
• Abandonment: Evidence Packet drafts started but never submitted, by week.
• Error rates: telemetry-overlay load failures, evidence-gallery load failures per week (data-pipeline health signal).
• Time to decision: median time from record Unclassified to Confirmed (either path).
• Feature usage: Cohort Flow interaction rate, evidence-packet share-link usage (a proxy for collaborative review before submission).
• Adoption: weekly active use by the Maintenance Supervisor persona on this console specifically (distinct from their mobile app usage, tracked separately).

20. Acceptance Test Suite

20.1 Functional acceptance scenarios

• Maintenance SupervisorW-FR-001 through 004 each produce the exact state transitions and downstream effects specified.
• A full evidence-packet workflow (scope → curate → narrative → validate → submit → track) can be run entirely from this console.

20.2 Permissions tests

• No role, including Maintenance Supervisor, can invoke Promote/Merge/Reject or RTS from this console — verified by confirming the absence of the corresponding routes/endpoints, not just a permission denial.

20.3 Transition tests

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

20.4 Cross-surface reconciliation tests

• Confirmed-record counts, cohort membership, and recurrence figures match the PM/Head of Maintenance/VP Consoles exactly at the same timestamp.
• A submitted packet’s content in the PM Console’s inbox exactly matches this console’s Preview, verified by content-hash comparison.

20.5 Data-quality tests

• No record ever displays an invalid or non-canonical Tier-2 code.
• A telemetry-dark vehicle’s overlay never renders a misleading empty chart without the explicit “no telemetry available” state.

20.6 Notification tests

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

20.7 Export tests

• Record CSV exports include every column in Section 11’s schema; Evidence Packet PDF export matches the submitted content exactly.

20.8 Failure-recovery tests

• A failed packet submission leaves the draft fully intact (no data loss), per Maintenance SupervisorW-FR-003’s failure clause.

20.9 Accessibility tests

• Full keyboard traversal of Records Workbench’s 3 panes and the Evidence-Packet Builder’s multi-step flow 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 single Maintenance Supervisor identity (role ∈ {Maintenance Supervisor, Maintenance Supervisor_DESK}) spans both the mobile validation gate and this web console — they are one persona across two surfaces, not two separate roles [VERIFY-7 for the underlying identity system].

21.2 Dependencies (external, unresolved by any available source)

• [VERIFY-6] Whether a TH Engineering-side system exists to receive escalations beyond the PM Console’s own pipeline — this console’s Escalation Detail assumes the PM Console’s Engineering-Feedback Item is the system of record unless told otherwise.
• [VERIFY-5] Telemetry channel availability and schema per VCU type, needed to fully populate the Telemetry-at-fault overlay (Section 7.2).
• [VERIFY-3] Notification transport.

21.3 Proposed Product Decisions made in this document

• Evidence-Packet completeness gate’s exact four criteria (Section 7.5) — no source defined them explicitly; adopted as the minimum bar for a defensible engineering case, fully specified and enforced client- and server-side.
• Packet versioning and anti-gaming re-queue rule (revised packets keep original submission-date priority) — reused verbatim from the Argo Shared Operating Model §2.10/§7.3.
• Maintenance Supervisor-web proposal-as-endorsement modelling (Section 8, Maintenance SupervisorW-FR-002) — since this console’s Maintenance Supervisor performs an analytical review equivalent to mobile endorsement, a web-originated proposal enters the Head of Maintenance governance queue already Endorsed rather than requiring a redundant separate endorsement step.

22. Glossary

• Argo — The field maintenance, reliability, and fault-intelligence operating system for Rechaj’s electric tricycle fleet, run by Maintenance under Vehicle Operations.
• Maintenance Supervisor — Maintenance Supervisor — one persona spanning the mobile validation gate and this analysis desk.
• Evidence Packet — A versioned, structured artefact assembled from field evidence and submitted into the PM’s engineering-feedback pipeline (Section 9.1).
• Unclassified record — A confirmed-fault record with no assigned canonical Tier-2 code (Section 9.2).
• Cohort Flow — This console’s signature Sankey-style module tracing Tier-1 capture → Tier-2 confirmed cause → Cohort (Section 7.1a).
• Time-to-first-failure — A cohort’s distribution of days from service-entry/install to first linked-fault occurrence (Section 7.3).
• Data-Quality Console — The interactive QA module covering captured-at-source completeness, unclassified rate, non-fault pollution, complaint-not-reproduced rate, and RTS failure rate (Section 7.6).
• Propose / Recommend (vs. Promote / Merge) — The Maintenance Supervisor’s available taxonomy actions (suggest only) as against the Head of Maintenance’s exclusive authority to execute (Section 5).
• Escalation boundary — The exact point (a submitted Evidence Packet, converted into a PM Engineering-Feedback Item) where this console’s responsibility ends and the PM Console’s begins (Section 7.7).

23. What a record, a gate and a packet read as

A record’s outcome. A validated record reads Confirmed and released; one with no canonical Tier-2 code reads Unclassified; one the gate sent back reads Sent back at Gate #2; one ruled not to be a fault reads Closed not-a-fault. Where a column cannot hold the phrase it carries the short form — Released, Unclassified, Sent back, Not a fault — and the legend and the tooltip keep the full one. There is no fifth outcome.

The validation gate. Gate #2 is pending until it is worked, then either Returned at Gate 2, which sends the record back with its reason, or Closed, released, which is the same event the outcome reads as Confirmed and released.

What the evidence is worth. A record with neither photos nor telemetry is flagged No evidence. A record whose capture cannot be relied on reads Low capture confidence, and one whose assigned cause cannot reads Low cause confidence. These are flags on the record, not outcomes, and they never replace the outcome.

The unclassified queue. A record in the queue reads Awaiting evidence while more is being gathered, Merge proposed where this console has recommended merging it into an existing code, and Not defined where no code has been proposed at all. Proposing and recommending are the only taxonomy actions this console holds; promoting and merging happen elsewhere.

An evidence packet. A packet moves Draft → Submitted → Acknowledged, and ends either Returned with the reason it came back, or Closed.