head of maintenance console prd

ARGO

Head of Maintenance Console

Fleet, Bays & Field-Maintenance Operations

Atlas Web · 1440px desktop · Vehicle Operations / Maintenance

Document 3 of 5 · Version 2.0 · Status: Draft for engineering handoff

Owner: PM, Vehicle Operations

MocX Smart Technologies Inc. · Confidential

1. Cover & Document Control

Field	Detail
Product & surface	Argo — Head of Maintenance Console (Atlas web, 1440px desktop)
Version	2.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 Head of Maintenance Console; the Head of Maintenance 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	v2.0 — current. Adds the Investigations queue the PM assigns into this console (7.11, FR-N1–FR-N6), the Send feedback entry point in the sidebar, and the Head of Maintenance persona alias.
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_Maintenance Supervisor_Web_Console_PRD.docx; Argo_Web_Console_Coverage_and_Reconciliation_Matrix.docx.

2. Executive Summary

The Head of Maintenance runs the fleet’s entire field-maintenance operation: every bay, every dispatch, every schedule, every campaign, and the taxonomy that makes all of it classifiable. This is Argo’s operational flagship — the surface the gap analysis and foundational brief both single out as needing to prove the workbench bar (a real 3-pane dispatch surface, a real planning calendar, a real campaign rollout board) rather than a dashboard with a table underneath.

The Head of Maintenance Console exists to let one Head of Maintenance run every bay and every campaign for a full week without a spreadsheet or an unmodelled side process: a command centre that shows the whole fleet’s state at a glance, a dispatch workbench that reassigns work across bays with real capacity awareness, a scheduler that plans condition and ad hoc maintenance, a campaign builder with a live rollout board, and the sole authority in all of Argo to promote, merge, or reject a taxonomy code.

Decisions this surface enables: cross-bay reassignment under capacity conflict; resolving an escalated Blocked work order; approving a bay’s replenishment request; promoting/merging/rejecting a proposed failure mode; approving a schedule or campaign within Head of Maintenance’s own authority (or routing it to VP per the routing rule). Success looks like: the Head of Maintenance runs a full week — every bay, every campaign, every blocked case, every taxonomy proposal — from this console alone.

3. Persona & Operating Context

Persona alias. The built console titles this role Head of Maintenance (Chinelo Okonkwo in the prototype); Head of Maintenance and Head of Maintenance are the same person and the same surface. Where this document says Head of Maintenance, the console says Head of Maintenance.

3.1 Responsibilities

Own the fleet’s field-maintenance operation end to end: dispatch, bay capacity, scheduled maintenance, campaigns, replenishment approvals, and taxonomy governance.
Resolve every escalation that reaches the Head of Maintenance: Blocked work orders the Maintenance Supervisor couldn’t unblock, replenishment requests, taxonomy proposals.

3.2 Working cadence

Continuous, intraday: the Command Centre is the Head of Maintenance’s always-open surface. Daily: dispatch reassignment, replenishment approvals. Weekly: scheduler due-load review, campaign rollout checks. Ad hoc: taxonomy governance decisions as proposals arrive.

3.3 Primary jobs to be done

“What’s happening across every bay right now?” → Command Centre / Fleet Status Wall.
“Which work orders need reassignment or are at risk of breaching SLA?” → Dispatch Workbench.
“What maintenance is coming due, and do we have capacity for it?” → Scheduler.
“How is this campaign’s rollout progressing, bay by bay?” → Campaign Rollout Board.
“Is this a real new failure mode, and should it become a canonical code?” → Taxonomy Governance.
“Does this bay’s replenishment request get approved?” → Replenishment Approvals.

3.4 Decisions made here

Cross-bay work order reassignment under capacity awareness.
Unblock or escalate-further a Blocked work order.
Approve/reject a bay’s replenishment request (or route to VP if the campaign/roadmap routing rule applies to an associated large-scope action).
Promote, merge, or reject a proposed taxonomy mode — the sole authority in Argo for this action.
Approve a Campaign’s rollout (Head of Maintenance tier) or forward it to the VP Decisions Queue when the routing rule requires it.

3.5 Inputs received

Work orders and their state from the Maintenance Technician Lead/Maintenance Supervisor mobile apps (out of scope, referenced as upstream originators).
Intervention/Campaign proposals from the PM Console.
Proposed taxonomy modes raised by Technicians and endorsed by Maintenance Supervisors (mobile or Maintenance Supervisor Web).
Replenishment requests from Maintenance Supervisors (mobile, out of scope, referenced as origin).
Stock into the Head of Maintenance store: delivery notes from the Inventory Manager against the store’s own requests.

3.6 Outputs produced

Reassigned/unblocked work orders, approved replenishments, promoted/merged/rejected taxonomy codes, approved and rolled-out campaigns, generated scheduled-maintenance occurrences.

3.7 Pressure points

A Blocked work order sitting unresolved directly costs a rider their livelihood — the console must make block age and reason instantly visible, never buried in a filtered view.
Capacity conflicts across schedules, campaigns, and backlog compound silently if not forecast — the due-load view must surface conflicts before they become missed SLAs.

3.8 What this role explicitly cannot do

Cannot make product-roadmap decisions (PM Console’s authority) or perform executive portfolio governance (VP Console’s authority) — the Head of Maintenance operationalizes what PM/VP decide, and escalates upward what exceeds Head of Maintenance’s own approval threshold, but does not set roadmap priority or accept portfolio-level risk.

4. Goals, Non-Goals & Measurable Success Criteria

4.1 Product outcomes

Zero work orders breach a defined SLA without an active, visible mitigation (reassignment, escalation, or an explicit accepted-risk flag).
100% of taxonomy proposals are resolved (promoted/merged/rejected) within a defined SLA window, with full audit trail.

4.2 Operational outcomes

Median time-to-resolve trending down quarter over quarter, reconciled with the PM/VP Consoles.
Zero campaigns stall for lack of a rollout-board view — every campaign’s per-bay, per-vehicle progress is always current.

4.3 Adoption & usability outcomes

Head of Maintenance runs an entire week’s operation (dispatch, scheduling, campaigns, governance, replenishment) from this console with zero reliance on spreadsheets or side channels.

4.4 Data-quality outcomes

Fleet-Ready %, VRI distribution, cohort recurrence, and COPQ reconcile exactly with the PM and VP Consoles at the same timestamp.

4.5 Explicit non-goals

Not a product-roadmap tool (PM Console) or an executive risk/decision tool beyond Head of Maintenance’s own approval tier (VP Console). Not a cohort-analytics workbench (PM Console) or an evidence-packet/data-quality desk (Maintenance Supervisor Web Console) — this console operationalizes and governs; it does not perform deep analytical investigation.

5. Role, Permission & Authority Model

Action	Head of Maintenance	Dispatch Maintenance Service Lead (dispatch-scoped delegate)	Server-enforced rule
View command centre, dispatch, scheduler, campaigns, taxonomy, reports	Full	Full (dispatch/bay-scoped views only)	Read access requires role ∈ {HEAD_OF_MAINTENANCE, DISPATCH_SERVICE_LEAD}; taxonomy governance detail is view-only for the delegate.
Reassign a work order across bays	Full	Full	Requires role ∈ {HEAD_OF_MAINTENANCE, DISPATCH_SERVICE_LEAD}.
Unblock / re-escalate a Blocked WO	Full	Full for dispatch-originated reasons; escalates to Head of Maintenance for inventory/taxonomy-originated blocks	Rider-as-blocker and no-stock reasons may be resolved by the delegate if the resolution is dispatch-scoped (e.g., rescheduling); inventory-approval-requiring resolutions require role=HEAD_OF_MAINTENANCE.
Build / approve a Maintenance Schedule	Full	None (view only)	role=HEAD_OF_MAINTENANCE only.
Build / approve a Campaign (Head of Maintenance tier)	Full	None (view only)	role=HEAD_OF_MAINTENANCE only; VP-tier campaigns additionally require the VP Console’s Decision per the routing rule.
Promote / merge / reject a taxonomy proposal	Full	None	role=HEAD_OF_MAINTENANCE exclusively — no other role in Argo, including any Maintenance Supervisor, can execute this action, per the Argo Shared Operating Model §3.
Approve a replenishment request	Full	None	role=HEAD_OF_MAINTENANCE only.
Export reports / sign off operational reports	Full	Full (own scope)	All exports audit-logged with actor + timestamp + scope.

5.1 Delegation and acting-role behaviour

The Dispatch Maintenance Service Lead persona (Argo Shared Operating Model §0 C14) is modelled here as a standing, dispatch-scoped delegate role, not a time-boxed acting delegation — it reflects a real, permanent division of labor (dispatch operations vs. cluster governance) rather than covering for the Head of Maintenance’s absence. A separate, time-boxed “acting Head of Maintenance” delegation (mirroring the VP Console’s acting-VP pattern) is available for planned absences and carries full authority except taxonomy promote/merge/reject, which — like the VP Console’s WBR sign-off — is a non-delegable, personal governance act.

5.2 Multi-bay and multi-role behaviour

The Head of Maintenance has cluster-wide visibility across all bays by default; the console supports a per-bay filter/lens (Section 13) for focused work without losing the cross-bay view needed for capacity-aware reassignment. A technician or Maintenance Supervisor operating across multiple bays (Argo Shared Operating Model, field-flow-fixes spec Q-24, logged [VERIFY] there) is reflected here simply as their assigned-bay field being editable per work order — this console does not resolve the underlying multi-bay staffing policy, only displays whatever assignment the roster reflects.

5.3 Audit requirements

Every reassignment, unblock/escalate, schedule/campaign approval, taxonomy governance action, and replenishment approval is logged with actor/timestamp/reason.
Taxonomy governance actions are additionally kept in a permanent, append-only audit log (never edited or deleted) per the Argo Shared Operating Model §3, since they affect historical record reclassification.

5.4 Forbidden actions and expected error responses

A Dispatch Maintenance Service Lead attempting to promote/merge/reject a taxonomy proposal receives 403: “Only the Head of Maintenance can govern the taxonomy.”
Any attempt (from any role, including Head of Maintenance) to execute a Return-to-Service transition from this console is rejected — this console has no such control, per the Argo Shared Operating Model §2.24 (RTS is Maintenance Supervisor-mobile-exclusive).

6. Complete Information Architecture

Command Centre — /maintenance/home
Targets — /maintenance/targets (read-only, set by the PM; §23)
Tricycle cases — /maintenance/dispatch (tabbed: Repairs · Battery · Oil change · Field escalation) → /maintenance/dispatch/:woId (work-order detail) → /maintenance/dispatch/:caseId (case detail) → /maintenance/bays (bay operations) → /maintenance/bays/:bayId (bay detail)
Bays — /maintenance/bays (bay operations, §7.3) → /maintenance/bays/:bayId (bay detail)
Retrievals — /maintenance/retrievals (tabbed: Incoming · Parts recovered · Recovery) → /maintenance/retrievals/:retrievalId (retrieval record)
Scheduler — /maintenance/scheduler (calendar/planning) → /maintenance/scheduler/new (schedule builder) → /maintenance/scheduler/:scheduleId (detail, pause/resume/retire) → /maintenance/scheduler/cohorts (vehicle cohorts and onboarding cohorts)
Campaigns — /maintenance/campaigns → /maintenance/campaigns/new (builder) → /maintenance/campaigns/:campaignId (rollout board)
Taxonomy — /maintenance/taxonomy (proposed modes queue) → /maintenance/taxonomy/:proposalId (endorsement history, promote/merge/reject) → /maintenance/taxonomy/reference (full catalog, read reference)
Inventory — /maintenance/replenishment (tabbed: Approvals · Parts) → /maintenance/replenishment/:requestId (approval detail) → /maintenance/replenishment/parts/:partId (part record)
Reports — /maintenance/reports (operational sign-off, history)
Investigations — /maintenance/investigations (the queue the PM assigns into this console, §7.11)
Notifications — /maintenance/notifications
Settings — /maintenance/settings (saved views, notification preferences, delegate management, bay roster references)

Figure 1 — Head of Maintenance Console sitemap.

6.1 Cross-surface deep links

Dispatch WO detail’s Tier-2 confirmed cause deep-links to the Maintenance Supervisor Web Console’s Record Detail (read-only) when a full evidence view is needed.
Campaign rollout board’s originating proposal deep-links to the PM Console’s Intervention Proposal detail (read-only).
A VP-routed Campaign/Schedule shows its Decision status with a deep link to the VP Console’s Decision Detail (read-only from here).
Taxonomy proposal’s endorsement history deep-links to the originating Maintenance Supervisor’s endorsement record (mobile or Maintenance Supervisor Web, whichever endorsed).

6.2 Breadcrumbs, saved views, command palette

Breadcrumb pattern: Argo / Head of Maintenance Console / {section} / {sub-page}. Saved views apply to Dispatch (bay/status/severity filters), Scheduler (schedule-lane visibility), Campaigns (status filters), and Taxonomy (proposal-age sort). ⌘K destinations: any of the 9 routes; jump to a specific WO/bay/schedule/campaign/proposal by ID; quick actions “New schedule”, “New campaign”, “Reassign WO {id}”.

7. Complete Page Inventory

7.1 Command Centre (Fleet Status Wall hero)

Purpose: the Head of Maintenance’s always-open view of the entire fleet and operation. Entry: default landing route. Exit: every module links to its full page.

Modules, in visual order

Fleet Status Wall (signature module) — a live geospatial/status map: every vehicle plotted (or, absent live GPS confirmation [VERIFY], grouped by bay/region) and colour-coded by VRI band (Healthy/Watch/At-risk/Critical/Unknown per the Shared Operating Model §5); click a vehicle for a hover card (plate, status, current WO if any); click a bay marker to drill into Bay Detail (7.4). Bays are shown as capacity-coloured markers (green/amber/red by current load vs. roster).
Operations feed: chronological, real-time list of the last 50 operationally-relevant events (WO created/blocked/unblocked/resolved, campaign milestone, taxonomy proposal raised, replenishment requested) with relative timestamps and deep links — this is the console’s live pulse, not a static log.
KPI & trend band: Fleet-Ready %, open WO count by status (New/In Repair/Blocked/In Service today), median time-to-resolve (rolling 7-day), repeat visit rate (vehicles back for the same fault inside 30 days) — each a count-up tile with a 7-day sparkline.
Opened-vs-closed burn-down: a dual-line chart, WOs opened vs. closed per day over a rolling 30-day window, brushable, with a backlog-trend annotation (“backlog growing/shrinking”).
Fleet & cohort watchlist: cohorts trending toward the 15% recurrence threshold (read-only reference to PM Console data) and vehicles with Critical VRI, ranked, with “View in PM ›” / “View WO ›” deep links.

Chart definitions

Fleet Status Wall colour logic: matches the Shared Operating Model §5 VRI bands and hard overrides exactly (any open P1 → Critical marker; immobilised → at least At-risk; telemetry-dark >48h → a distinct “Unknown” grey marker, never folded into Healthy).
Burn-down chart: opened = count of WOs entering NEW that day; closed = count reaching IN_SERVICE or CLOSED_NOT_FAULT that day; drill-down on any day’s bar filters the Dispatch queue to that day’s activity.

States

Loading: skeleton on the map and every KPI tile. Empty: not applicable to an active fleet; a genuinely empty bay (no vehicles assigned) shows “No vehicles currently assigned to this bay” on its marker’s hover card.
Error: map tile/module failures are isolated — the KPI band and feed continue rendering independently.
Stale: any KPI computed more than 2× its refresh interval ago shows the stale tag, per the VP Console’s established convention (reused here for consistency).

Acceptance

Every vehicle marker’s VRI band matches the value shown for that vehicle in the PM/VP Consoles at the same timestamp (cross-surface reconciliation, Section 20).

7.2 Tricycle cases (tabbed)

Purpose: the operational core for tricycle field cases. One tabbed page that holds every case type in the same tabular shape, so the Head of Maintenance can scan, filter, triage and act without switching surface or re-learning a layout.

Page and tabs

The page is titled Tricycle cases (internal key dispatch). A page-level tab strip sits directly under the page head with four tabs: Repairs, Battery, Oil change and Field escalation.
Battery cases are a tab here, not a separate sidebar page. A battery pack fault is a tricycle case and belongs beside the others.
There is no Unclassified tab. An untriaged repair is still a repair, so it sits in Repairs alongside the triaged ones and is separated by its triage state, not by being exiled to its own tab.
Switching a tab re-renders the page; the strip shows on every tab.

One table shape on every tab

A scheduled work order has no fault to validate, because no fault raised it. Its assignment panel names the schedule it came from and the checklist that schedule carries, in place of the fault-validation gate.
Each rail heads its table with a card row: All first, then the statuses a record sits in exactly one of, then Over 24h, the count still standing at a bay more than a day after it arrived. Every card filters the table beneath it. All leads as a card rather than riding underneath as a chip, because it is the number read first.
Over 24h counts what is still at the bay. Anything closed has left, so it is not standing anywhere and is not counted.
Every tab is a table — not a workbench, not cards. Eight columns, same order, the date last: Case ID · WO ID · Plate · Rider · Fault · Priority · stage · Status · Created. On Oil change and Field escalation the WO column is replaced by Odometer: a case of either kind never raises a work order, so that column was a dash on every row.
A case id and a work-order id are different things. The case is raised first; the WO is created after triage. An untriaged record therefore shows its case id and a dash for the WO. Every work order maps back to the case it came from.
A complaint is not a fault. The complaint is the note the case arrived with, in the reporter’s words. The fault is what was selected on Argo at triage, from the taxonomy. The table carries the fault class only; the complaint lives on the detail. An untriaged record reads Not selected yet for its fault. Search matches both.
Priority and stage share one cell — the priority keeps its colour-coded badge because that is the scanning signal, the stage reads as plain text beside it.
Recurrence shows on the row. The fault cell carries a repeat count (1×, 2×, 3×) of how many times that same fault has been raised on that same vehicle, counted against earlier closed occurrences. Recurrence counts on the fault only — never on the wording of a complaint. A repeat can be opened and checked against the vehicle history rather than taken on trust.
Every list table pages. Fifteen rows to a page, with the foot stating the total behind the page and a pager beside it. Changing any filter returns to the first page. Nothing is ever capped silently.

Status, stage and the two terminal states

Status says where it stands: Open · In repair · Blocked · Resolved · Closed.
Stage says who holds it: Awaiting triage · Awaiting booking · With Maintenance Supervisor · With Maintenance Supervisor (fault validation at capture) · With Head of Maintenance · With Dispatch · Closed. The two are separate axes and are never collapsed into one.
Resolved is not the end. Resolved means the repair is done and the tricycle is still on the floor. It becomes Closed only when someone marks it picked, recording who collected it. The two states are counted separately so work that is finished but uncollected cannot hide inside a completion number.
A summary card row partitions the population by status on every tab — the cards must sum to the total — each clickable to filter. Repairs and Battery carry both Resolved · awaiting pickup and Closed (picked). A tricycle case has no pickup step, so its terminal card is Closed.

Dates and ageing

A case being created is not the same event as its fault being captured at triage. Both timestamps are held and both show — the row’s Created column, and separate Case created and Fault captured stages on the state timeline.
Every date names its weekday (“Tue 18 Aug 2026”).
Ageing scales with the elapsed time — minutes, then hours, then days (“29 min open”, “5 hr open”, “3 days open”) and reads in red. A resolved record reads “awaiting pickup 3 days”; a closed one shows its closing date instead of a running age.

Filters

The created date range sits above the summary cards, not in the table head, because it scopes the cards as well as the rows.
The table head carries a search (case id, WO id, plate, rider, fault, complaint, stage) plus facet filters for triage state, status, bay, priority and age (under an hour · under a day · 1 to 3 days · 3 to 7 days · over a week). All of them compose, and the bay lens scopes the whole table.
A Reset filters control sits with the date range and appears only once something is filtered.

The Head of Maintenance store

Two paths feed the bays, and they answer different clocks. A bay-raised replenishment request, once approved here, goes straight to the Inventory Manager, who fulfils it with a delivery note the bay accepts. The store is the second path — stocking ahead of need, because repairs held for faulty returns drain a bay’s usable stock before a bay thinks to ask.

The Head of Maintenance requests stock from the Inventory Manager — multi-line, one request; statuses Requested → Fulfilled (delivery note issued) → Received.
Stock is received into the store against the delivery note, and held there — the store is custody, not bay stock.
Pushing to a bay moves it into that bay’s own stock: the bay’s on-hand rises and the movement is logged against the store, so bay stock and store custody can never double-count.
What is not needed returns to the Inventory Manager, with a required reason on the record.
Every movement is on the record — received, pushed, returned — with quantity, reference and who moved it; pushes and returns are capped by what the store actually holds.

Requesting stock says why it is needed. A request carries urgency, a needed-by date and a reason (required, because the Inventory Manager prioritises on it), and each line searches the warehouse catalog and shows what the store already holds of that part. A line naming something the warehouse does not stock is refused. Inventory fulfilling a request reaches the console as a notification that opens the receipt it is about.

Receiving is a check, not a click. The receipt lists every line as requested against fulfilled, names the shortfall where there is one, and takes the quantity actually received. A serialized part is received unit by unit but not one input per unit: the serial is typed, scanned or read out of an uploaded CSV and lands as a chip in a list that counts itself against what was fulfilled. The receipt will not close until every unit received has one. A delivery can be refused — reject takes a reason (wrong part, quantity does not match the note, damaged in transit, serials do not match, not ordered here) plus the detail; nothing enters the store and the reason goes back to Inventory.

Stock moves from whichever shelf it is on. A movement to a bay names where it is moving from — the store, or another bay — allocates across several bays in one movement, and cannot allocate more than that shelf holds: each bay box takes only what is still unallocated. Where the store holds the units, the movement is a choice of which serials go, and they travel with the quantity.

A return to Inventory reconciles what it is sending. It names the shelf it is leaving, the condition in the warehouse’s bucket vocabulary (Unused, Refurbished, Used, Faulty), the delivery note it came in on, and a required reason. Serials are captured the way they are captured on receipt and read against what that delivery note issued, so a unit that was never issued on it is flagged on the form and on the record. Custody transfers on acceptance, not dispatch: the stock stays the store’s, counted as outgoing and excluded from what the store can spare, until Inventory accepts it.

One table reads the relationship in both directions. Requests from Inventory and returns to Inventory sit in one Requests and returns table with a direction filter, a status filter, a raised-date range, a search and an export. Arriving stock is Received whichever direction it came from.

Parts on hand names which shelf a number is on. The table reads in the store, at the bays and on hand (the two together, which is what the card counts), how a part is tracked (serialized or consumable), where it is, and its last movement. Every part can be moved to a bay or returned to Inventory from a row menu, and from its own record as buttons. The part record lists the units on hand with where each one sits and the delivery it came in on, and the replacement history names the unit fitted.

The unit of measure rides the quantity, not the part. A part is a part whether there is one or a hundred; it is the figure that is counted in rolls, pairs or pieces, so every quantity in every table, dialog and record carries its unit and no column is spent on it.

What each Inventory tab leads with

Approvals opens on what is waiting on the Head of Maintenance, the units held up behind it, what has gone to the Inventory Manager, and how long the oldest request has sat. Every request carries the day and time it was raised, not a bare age.
Stock opens on what there is to receive, what is still owed by Inventory, what is outgoing and not yet accepted, and what is on hand.
Parts leads with the replacement rate: a line readable by day, month or year over its own date range, with the period just gone measured against the period before it. Bringing that number down is what the tab is for.

Record detail

A row opens its record: a work order or battery case to its own detail page, an untriaged case to the case detail. The detail is two columns wide so a record is not one long scroll, with vehicle history and cross-bay capacity full width beneath.
The detail is tables too. A work order reads: The repair · State timeline · Evidence · Parts replaced · Assignment · Vehicle · Resolution · Vehicle history · Cross-bay capacity. A battery case substitutes The pack. A case reads: The case · Rider and vehicle · State timeline · Vehicle history.
Every tricycle case asks one thing on arrival: Is the tricycle in the bay? Yes or no, defaulting to no. Whoever physically receives the vehicle sets yes, and the change is stamped on the record. The flag starts the resolve clock: time to resolve runs from the moment yes is set to the moment the case reads Resolved, so a case still waiting for its vehicle accrues no repair time, and a case resolved without the vehicle ever in the bay contributes no time-to-resolve sample.
Vehicle history lists every earlier repair, battery case, service case and closed prior raised on the same vehicle — or on the same rider where they changed vehicle — with the current record left out, so recurrence is visible on the record rather than hunted for.
The list tables inside a record carry their own search and pager — vehicle history, a part’s riders, every replacement, every stock movement. Search matches the whole row, so a plate, a work-order id, a delivery note or a technician all find their rows, and an empty result names what was searched. A table with no rows shows neither.
Requirement: any table showing a vehicle plate also shows the Rider.

Actions

Unblock (required resolution note), Approve replenishment, Reassign (required note) and Refer back are retained in full, each a durable state change confirmed through a dialog. A cross-bay capacity conflict warns but never blocks (informed-override), and a blocked record carries a banner naming the blocker, the escalation and the paused resolve-clock.
Mark as resolved and Remind Maintenance Supervisor are offered on every tricycle case, not on repairs alone: Oil change, Field escalation and untriaged records too. A tricycle case has no pickup step, so resolving one closes it; the resolution note lands on the case record, and the reminder is recorded beside it.
Remind Maintenance Supervisor — on a work order or battery case, offered only while the record sits on the fault-validation gate; on a tricycle case, for as long as the case is live. It names the Maintenance Supervisor for that bay, shows the gate and how long it has waited, takes an optional note, and on send emails them and raises an in-app notification in Argo. What was sent is recorded on the record, so a second nudge is a visible decision rather than silent repetition.
Mark as resolved — beside Remind Maintenance Supervisor, taking a required resolution note that lands on the Resolution table.
Mark as picked — offered on a resolved repair or battery case, recording who collected the vehicle and closing it.

7.3 Bay Operations

Purpose: per-bay operational detail — roster, capacity, backlog and parts constraints at that bay.

Bay list

Columns: bay name, lead (Maintenance Technician Lead), technician count, current load vs. capacity (%), backlog age (oldest open WO), parts-constraint flag (any Blocked-for-no-stock WOs). A bay with no capacity configured shows a dash for load, never a percentage of zero.

Bay Detail

Roster: technicians assigned, their current WO load.
Capacity: the hours a week the Head of Maintenance has set aside for this bay, against the load standing at it, with the conflict flag when the load is more. The figure is theirs to set and they derive it from how many technicians the bay has, so a bay’s capacity moves when its roster does. Capacity is in hours, never in vehicles: two services on one keke are two pieces of work.
A bay’s load is the tricycle cases standing at it plus the services sent to it, and nothing else. Campaigns have not started. There is no separate backlog figure: the open work orders are the backlog, and counting both stated the same work twice.
Load is derived, never typed. A fault case is costed off its priority until a technician has estimated it; a scheduled service costs what its schedule says a service takes.
Current load & backlog age distribution: a histogram of open WOs by age bucket.
A Retrievals tab sits beside Work orders, built the same way and reading the same retrieval records the Retrievals page reads: retrieval, work order, plate, rider, when it was sent and by whom, and its status, with search and Export. A row opens the retrieval. A bay takes both kinds of work, so both are read where the bay is read.
A serial mismatch is recordable on any item on a kit: the serial actually read off the part, against the serial the register says is fitted. Both are kept. The register is a claim about the part and the part is the fact, so the item is not renamed, it is corrected against.
It is recordable while the strip-down is being closed, per item, and afterwards from the retrieval’s own manifest, because a mismatch is often found on a second look and sometimes by the warehouse. Claiming a mismatch without giving the actual serial does not close the strip-down.
A part already sent to Inventory carries the correction with it: the warehouse holds the item, not the manifest. Every place the serial is read states the actual one with the register’s beneath it, and the mismatch is its own count and its own filter on Parts recovered.
Parts constraints: any WOs Blocked for no-stock at this bay, with a direct link to the Maintenance Supervisor’s (mobile, out of scope) bay-inventory view status and this console’s own Replenishment Approvals queue (7.6) if a request is pending.

States & acceptance

A bay with a triggered capacity conflict shows a persistent amber banner on both the Bay list row and the Bay Detail header, never buried.

7.4 Maintenance Scheduler

Purpose: the planning calendar and rule engine for all preventive-maintenance schedules, a due-window-aware planning tool that projects occurrences, sends each one to a bay, and hands the resulting work order to Argo and the Forge floor app.

Calendar / planning view

A Day / Week / Month planning calendar, one lane per schedule that can generate occurrences, shown side by side with a compact Schedules list.
Every date heading states how many vehicles are due that day, counted distinct: a vehicle covered by two schedules on the same day is one vehicle coming in, not two, so the number is never the sum of the lanes beneath it.
A cell is a count and the hours it needs, not a mark per vehicle: at fleet scale the question is how much work lands when, not which riders. It is toned by the most urgent state in it, names the breakdown on hover, and opens that schedule. A lane’s sub-line states how many of its occurrences fall in the period on screen.
A capacity row closes the grid: for each column, the hours the scheduled work needs against the hours the bays have to give it, red when the work is more. Capacity is the weekly figure the Head of Maintenance sets per bay, and a column covering part of a week takes that share of it. It opens Bay Operations.
The calendar forecasts work that still has to be placed. An occurrence already sent to a bay is on that bay’s load and a serviced one is finished, so counting either here would state the same hours twice; both are read on the register.
Work already past its threshold sits on today rather than behind the period. Late work has to be done now, and plotting it on the date it was due drops it out of every view that has to account for it.
A schedule that generates nothing has no lane: paused, retired and draft schedules are absent, and a condition schedule keeps its lane with no marks until its telemetry feed is connected. Paging the date navigation moves the occurrences, not just the label.
One toolbar carries the Day / Week / Month toggle, ‹ / › period navigation, a live date-range label and a Today reset, beside the status and bay filters; an Expand toggle widens the calendar full-width.
A KPI band sits above the toolbar: Overdue, Due today, Due this week, Due this month, Spare capacity, Sent to bay. All six are counted off the same occurrence states, day placement and bay figures the calendar, the register and the send sheet read, so the band, the calendar, the table and a bay cannot disagree.
Due today, Due this week and Due this month each count distinct vehicles and carry the hours they need. Each is also the way to that calendar view, and all three stay anchored on today however far the date navigation is paged.
Due this month is the calendar month, so the tile and the Month view name the same period.
There is no plain Due total and no total due load. A count or an hours figure with no horizon on it repeats what Due today and Due this week say where it can be acted on.
Overdue is what is past its due threshold. What falls within a schedule’s notice distance but has not passed it reads as Due on the register and lands on its day in the calendar; together they are what Send due to bay acts on, and that button states its own count.
Overdue includes the occurrences past the service limit, and its sub-line names how many of them there are, as N past limit. A past-limit keke is overdue, not a separate kind of number.

Triggers and projection

A schedule carries one trigger, and its type is Condition or Ad hoc. A condition schedule fires off a telemetry signal crossing a threshold; an ad hoc schedule is raised as needed, with no trigger of its own. There is no whichever-comes-first second rule: two rules on one schedule make an occurrence a reader cannot place.
The one condition signal there is is distance since the last service. The VCU works it out from its own odometer and it resets when a service-complete or deferral command reaches it, so it is a meter that counts a service cycle rather than a vehicle’s life.

The thresholds and the service limit

Telemetry publishes one signal today: distance since the last service. Every condition rule and every distance schedule is built on it, and the console offers no signal that does not exist.
A condition schedule on that signal may carry three thresholds: a rider-warning distance, a due distance and a service limit. One schedule does today, General preventive maintenance, at 4,500 / 5,000 / 5,200 km since service, covering all active vehicles.
The VCU acts on the first two. At 4,500 km it plays a voice prompt on the DU screen and raises a red unserviced icon that stays on until the service is recorded complete. At 5,000 km the service is due and it plays the prompt a second and final time. The console reads both prompts and does not set them.
5,200 km is the service limit, and its consequence is on the swap, not on the vehicle. Past it, the rider’s next battery swap is blocked. Passing the limit does not lock the vehicle, so the rider can still ride to a bay. The limit and what it triggers on the swap are Rechaj’s.
The priorities are ours to set and the thresholds set them: 4,500 km is P3, 5,000 km is P2, 5,200 km is P1. A scheduled work order is raised at the priority its occurrence holds at the moment it is sent.
Past limit is an occurrence state and it ranks above Overdue. A past-limit row reads “past limit · next swap blocked · clears on return to service or deferral”; an overdue row states how far it is from the service limit, in kilometres and in days at that rider’s own rate.
Send to bay works on a past-limit occurrence as on any other. The send sheet states that the rider’s next swap is blocked until the service is recorded.
A past-limit rider is cleared by the service recorded complete or by a deferral. Recording the service complete in Argo sends the service-complete command to the VCU, and confirming a deferral sends the reset command (Section 15.1). Reassigning is the console’s own record and sends nothing to the vehicle.
Schedule Detail states the thresholds with their priorities: where the row starts reading Due, where the service is due, and, where the schedule carries one, the service limit, with the next swap blocked until return to service.
Each schedule has a notice distance: an occurrence within that many kilometres of its threshold reads Due, beyond it Projected, and past the threshold Overdue. On the schedule the vehicle warns on, the notice is not a preference, it is the distance the keke warns the rider at, so the console and the rider turn amber on the same kilometre.

Defer

Defer on a distance schedule takes a required reason and a come-in mileage: the odometer reading at which the rider is to bring the tricycle in. The defer sheet shows the rider’s current odometer, so the come-in mileage is set against where the tricycle actually is.
On the schedule the vehicle warns on, confirming it sends a reset command to the VCU. The counter restarts, the icon clears, and any swap block for the cycle is released. On any other distance schedule it records the come-in mileage and sends nothing to the vehicle, because that schedule reads the same counter and a reset would move the vehicle’s own service with nothing recorded against it. A deferral is the maintenance team’s decision, so its consequence is Rechaj’s to bear, not the rider’s.
A deferred occurrence is due at its come-in mileage on the live odometer, not on the reset counter. It reads Due within the notice distance of it, and Past limit once the odometer passes it, with the same swap block as the service limit. The row carries “deferred”, the come-in mileage and the reason; next due shows the come-in mileage with the projected date at the rider’s rate.
Every deferral is written to the schedule activity log with actor, time, reason and the mileage recorded, surfaced on Schedule Detail.
Defer on an ad hoc schedule takes days plus a required reason, and moves the occurrence’s next-due date rather than just its day count.
There is no Skip. A service not done is either deferred, with a come-in mileage, or left to the service limit.

Schedule Builder — every field

A schedule is the service it raises, and has no name of its own. The service is picked from the ones that exist, or typed in to add one the console has not carried before, and the schedule takes its name from it. It is the first thing the builder asks.
The confirmation is triggered by the keke arriving. A held occurrence waits for a Maintenance Supervisor, who confirms it when the tricycle is standing at the bay, answering Tricycle at the bay? on the Argo app. It is not a desk action taken at any time: arrival is what there is to confirm.
When an occurrence comes due (required): hold for a Maintenance Supervisor to confirm, or auto-create the work order. Auto-create requires the bay those work orders are raised at, asked the moment that option is chosen.
Type: Condition or Ad hoc. On the schedule the vehicle warns on, the trigger is not asked for at all: telemetry publishes one signal and the vehicle warns against its own thresholds, so the builder states the signal, the distance it is due at and the service limit rather than offering a box to type a number nobody chooses. On any other condition schedule the signal is picked from the published list and the due distance is ours.
Notice distance (not lead time): how many kilometres before its threshold an occurrence starts reading Due. On the schedule the vehicle warns on it is not a field: the keke’s own warning distance decides it, so the builder states that number.
Condition triggers are built from the list of signals telemetry publishes, never free text. There is one on the list today: distance since last service.
Hours per service: the estimated technician-hours each occurrence consumes.
Eligible-population picker: All active · Cohort · By bay · Specific vehicles. The cohort list carries both kinds, the vehicle cohorts somebody drew and the onboarding intakes a rider joined with, grouped so it is clear which is which. Specific vehicles are searchable by plate or rider name; each chip shows plate, rider and current mileage, the comparison for a distance threshold.
A schedule’s occurrences are drawn from the population it names and from nothing else: a schedule scoped to a cohort generates occurrences for that cohort’s members only.
A schedule may be scoped to a bay, because every tricycle has a home bay (Section 7.4.1). By bay sits beside All active, Cohort and Specific, and the builder states how many tricycles the chosen bay carries before the schedule is saved. Where a service is actually worked is a separate fact, decided per occurrence when it is sent.
Save as Draft, or Activate.

Schedule Detail — pause/resume/retire

Schedule Detail pauses, resumes or retires the schedule from the page header beside Edit, not from a card of its own; a Schedule activity card shows the audit log of sends and deferrals with actor, time and reason.
A schedule carries no version and no history of its own. Editing one changes the rule from that point on; what a past occurrence was raised under is recorded on the work order it produced, which is where anyone asking the question is already looking.
Each Schedule Detail carries the schedule roster (Section 7.4.1), narrowed to that schedule, with Serviced at in place of the Schedule column.

7.4.1 The rider register

One table serves the Scheduler page and every Schedule Detail. On the Scheduler it is the rider register: every rider has a row, because the service the vehicle warns on covers every active vehicle, and a rider who has never been scheduled will need one eventually. On a Schedule Detail it holds that schedule’s.
One row per rider, never one per occurrence. A rider covered by more than one schedule holds a single row, with the others counted beside it, so the register’s length is the number of riders and nothing else.
The row shows the most recent thing to happen to that rider, not the most urgent outstanding one: a keke standing at a bay reads Sent to bay, and one signed off this morning reads Serviced, whatever else is still projected against it.
Every tricycle has a home bay, set for the rider, not chosen by them. It is the maintenance bay at the rider’s station where that station has one, otherwise the nearest maintenance bay. The register states it on every row, because it is what a schedule scoped to a bay is drawn from and where the send sheet starts.
Where a service was worked is on the detail, not the list. A Schedule Detail and the rider record carry Serviced at, the bay the occurrence actually went to, marked away from home where that is not where the keke belongs. The Scheduler’s own register does not: where one occurrence was worked is a question about that schedule, not about the fleet.
A row opens the rider’s record.
Narrowing to a single schedule switches the table to that schedule’s own vehicles, because asking for a schedule is asking what it covers, not which riders happen to owe it most urgently.
Columns: Plate · Rider (phone beneath) · Home bay · Schedule · Since last service · Next due · Status · row menu. A Schedule Detail swaps Schedule for Serviced at.
The row menu carries Send to bay (Send to bay early while Projected) and Defer. Sent and serviced rows carry no actions.
Every occurrence keeps its row for the whole cycle: Past limit, Overdue, Due, Projected, Sent to bay and Serviced are all listed, ranked most urgent first, then by how close the occurrence is. Serviced is where a completed service is read: the row keeps its place, states the day it was signed off, and its distance reads from zero again. A sent row states the bay it went to, marked away from home where that is not its home bay; a deferred row carries “deferred”, its come-in mileage and its reason. Acting on a row never removes it, and the card is never withdrawn from the page.
The register carries no work-order number. It answers where a rider stands, not what was raised about them, and the work order is read where work orders are read.
Narrowing is the filters’ job, never the actions’: search across plate, rider, phone, intake, schedule and bay, plus filters for status, schedule, bay sent to and onboarding cohort, with an Export.
The table pages, and its foot states the page against the whole filtered set, so paging never hides how much is on the cycle. Send due to bay acts on the filtered set rather than the visible page, and the batch sheet lists every occurrence it is about to raise.
An occurrence shows its threshold in kilometres with its projected date and the rider’s km/day rate beneath, because a schedule counted in distance has no calendar date to show. Past the threshold it shows how far past instead. A deferred row’s next due is its come-in mileage on the odometer, with the projected date at the rider’s rate beneath it.

7.4.2 The service and its steps

A service is a named thing that holds its own steps. The named services are Routine oil change, Differential inspection and service, Half-shaft and axle inspection, Harness and connector inspection, and Throttle, beside General preventive maintenance. A schedule raises one of them, and a service can be added where the work calls for one the console has not carried.
A step is one instruction and as many acceptance criteria as it takes. The instruction is what the technician works to and is what Argo shows on the bay’s sheet; the criteria are what is ticked before the work order can close. A criterion is written under the step it belongs to, and a step keeps at least one.
General preventive maintenance is the four named services worked in one visit, so its steps are theirs, grouped by the service each came from, and adding a step to a covered service adds it there too. It is derived rather than copied, so the two cannot drift.
Nothing else belongs on a step. A measurement range, an expected part, a serial capture and a failure action are a work instruction rather than a checklist, and what a fault takes to put right belongs to the work order it raises.
A service with no steps says so. Throttle carries none, because the service document gives it none, and a service without them raises a work order a technician cannot action.
The steps are written once, on the service. They are authored from the schedule builder, and editing them there changes that service everywhere it is raised. Schedule Detail states the service and its steps in full, the register names it on every row and opens it, and a work order raised from a schedule reaches it from its assignment panel.
Argo holds the same services and executes them. The console plans against them; the bay works them.

7.4.2.1 The services, step by step

The steps below are the service content, not sample data: they are what a technician is told to do and what has to be true afterwards. A step’s criteria are ticked individually, and every one has to pass before the work order can close.

Routine oil change

ID	Instruction	Acceptance criteria
FR-V1	Verify asset and due interval	Asset and due status verified
FR-V2	Inspect for leaks or damage	Within approved criteria
FR-V3	Drain oil and inspect the removed oil and plug per SOP	Procedure followed and findings recorded
FR-V4	Replace the specified service items and refill	Approved grade, capacity and level
FR-V5	Verify level and leaks, record litres used	No leak, approved level, actual litres recorded

Differential inspection and service

ID	Instruction	Acceptance criteria
FR-V6	Inspect housing, mounts, leaks and noise	No abnormality; safe to operate
FR-V7	Check lubricant and service if due	Grade, capacity, level and interval in spec
FR-V8	Verify operation	Passes the approved test

Half-shaft and axle inspection

ID	Instruction	Acceptance criteria
FR-V9	Inspect shaft, spline, joints and retainers	Wear, play and damage within limits
FR-V10	Check fitment and fasteners	Torque to specification
FR-V11	Record condition and final verification	Meets the approved criteria

Harness and connector inspection

ID	Instruction	Acceptance criteria
FR-V12	Inspect routing, abrasion, plugs and locks	No abrasion; plugs seated and locked
FR-V13	Check seating and continuity using the approved test	Continuity within the approved range
FR-V14	Record repair or replacement and retest	Approved repair method; retest passes

Throttle

ID	Requirement
FR-V15	Throttle carries no steps yet. None were written for it, so the console states that rather than inventing them, and a schedule raising it raises work a technician cannot action until they exist.

General preventive maintenance carries no steps of its own: it is the four services above worked in one visit, so its steps are theirs in that order, each group named for the service it came from. A step added to any of the four is added to it.

7.4.2.2 What a step does not carry

A step carries no parts, quantities or failure actions. Their service document set a parts-and-quantity column and a failure-action-or-fault-code column against every step. Both belong to the work order a fault raises, not to the inspection that found it: the store issues against a work order, and what a failure costs is settled there. A step states what to do and what has to be true, and a fault raises a work order against the rider.
Every service is confirmed by a Maintenance Supervisor. Their document set a confirm mode per service, with the routine oil change confirmed by a telematics and dashboard check rather than a person. That is withdrawn: the supervisor confirms every service, including the oil change. A schedule may still create its work order automatically, which is a decision about the schedule rather than about the service.

7.4.3 Sending an occurrence to a bay

The send sheet opens already answered. Every row starts at the bay its keke is homed at, states that home bay beside the picker, and can be sent elsewhere; a row sent away from home says so. Nothing is asked for that the home bay already answers.
An occurrence is a projection until it is sent. Sending it raises the work order and puts it in a bay’s queue; the keke itself still has to be brought in, so the action is named Send to bay and not dispatch.
The picker lists every bay, each labelled with its current load, so a rider who can more easily reach another bay is sent there.
The single send sheet states rider, onboarding cohort, schedule and hours, and why the occurrence is due (distance since the last service against the threshold, and the rider’s rate). It shows the chosen bay’s load before and after, warns when the bay would pass its rostered capacity, and takes a service date.
A past-limit occurrence is sent like any other. The send sheet states that the rider’s next swap is blocked until the service is recorded.
The batch send sheet is a batch of decisions, not one decision applied many times: every row carries its own bay picker, starting at that keke’s home bay, and a running per-bay load summary updates as bays are changed.
A schedule set to create its work orders automatically raises them at the bay the builder required. Schedule Detail states it as Raised at, and nothing mints a work order without a bay: an auto-create schedule uses that bay, and every other send uses the bay on the sheet.
A capacity warning informs, it does not block: the same informed-override rule the Dispatch Workbench reassignment uses.
Sending puts the service at that bay, so the bay’s load carries its hours from that moment. Nothing is added by hand: the load is read off the work standing at the bay.
Before anything is raised, the relationship-manager app is sent each due service on a rider: the rider, the plate, the service, the distance since the last service, the distance to the service limit, whether the vehicle has warned the rider, and whether the next swap is blocked. A deferred service is sent with its come-in mileage.
When an occurrence is sent to a bay, the relationship-manager app is sent a case against the rider: type Scheduled service, the schedule’s name as the secondary, the Tricycle Maintenance Team, and a description naming the bay and the date. A Scheduled service case is raised only by the Scheduler.
The case is sent when the work order exists, not when a schedule is activated.

7.4.4 The rider record

Reached from a register row. The cycle figures sit above three panels, the same shape every other record page here uses: Services, Rider and vehicle, Vehicle history.

The state of the rider’s service cycle first: distance since the last service, what it is next due at, the rider’s daily average, the odometer and the swap gate. Where the service is deferred, next due is the come-in mileage.
Swap gate reads Clear, Service due sent or Swap blocked, from the same occurrence state as the register row: Service due sent while the service is due or overdue, Swap blocked once it is past the service limit or its come-in mileage, and Clear otherwise (Section 15.2).
Every schedule that covers the vehicle, with its threshold, its checklist, the state of each, the bay if one has been chosen, Serviced at, and the same send action the register carries. It carries no distance column: the counter belongs to the vehicle, so it would read the same on every row, and it is already in the band above.
The rider and vehicle: rider, phone, onboarding cohort, home bay, chassis and plate.
Parts replaced: every part fitted to the vehicle or ordered for it, with the work order that carried it, its type, the fault, its status and when. Read from the same rule the work-order detail reads, so a rider record cannot list a part its work order does not.
Everything ever raised against the vehicle or the rider, searchable and paged.
Back returns to the Maintenance Scheduler, which is where the record was opened from.

7.4.5 Cohorts

Reached from the Scheduler header. Two kinds of cohort sit on the page, because they answer two different questions about the same rider.

Vehicle cohorts: a named, fixed list of vehicles, reused as the eligible population for schedules and campaigns. Created and edited here, and from the schedule builder’s population picker.
Onboarding cohorts: the intake group a rider joined Rechaj with — intake name, date joined, rider count and how many of its riders have a service due, with a per-intake rider list (plate, rider, mileage, open work order). Read-only in this console.
The distinction is the point: a vehicle cohort is a set someone drew for a schedule and can redraw tomorrow, while an intake is fixed the day the rider joined. That is what makes the intake worth reading a recurring fault against, and why it is not editable here.
The rider’s phone number sits beneath their name on every roster row and is searchable, because getting the keke to a bay starts with ringing them. The onboarding cohort is on the send sheet and on the Cohorts page, and it stays one of the roster’s filters, so a fault pattern can still be asked of an intake as readily as of a build.
Both tables carry search, filters and Export. The onboarding table filters to intakes with services due.

Lifecycle handoff — Scheduler → Argo → Forge

The schedule authored here is the rule. When an occurrence comes due it emits a work order into Argo, per the schedule’s When an occurrence comes due choice (held for a Maintenance Supervisor to confirm, or auto-created).
The work order then runs the standard lifecycle — NEW → IN_REPAIR → BLOCKED → validated / closed — executed on the Forge floor app. This console tracks the occurrence up to dispatch and monitors it; Argo and Forge own it through the lifecycle.

7.5 Campaigns — Builder & Rollout Board

Purpose: the bounded, approved-intervention execution engine, distinct from the Scheduler (Argo Shared Operating Model §4.2/§4.3 — this page must make that distinction operationally unambiguous, with the worked example and counter-example from the Shared Operating Model reproduced inline for engineer/QA clarity).

Campaign Builder — every field

Objective/hypothesis (required, free text) — carried over read-only if launched from a PM Console Intervention Proposal (Section 15), or entered directly if Head of Maintenance-originated.
Scope: fixed vehicle list, or dynamic eligibility rule (e.g., “all active vehicles in Cohort X as of rollout start, re-evaluated weekly”).
Owner: PM (if proposal-originated) or Head of Maintenance (if Head of Maintenance-originated) — both named, never ambiguous.
Approval path: the routing rule (Shared Operating Model §4.5) evaluates scope/cost/safety/withdrawal-duration and shows the full required approval chain (Head of Maintenance only, or Head of Maintenance+VP) before submission.
Intervention package: one or more Interventions (part swap/firmware/process/inspection), each with its own parts and capacity estimate.
Parts and capacity plan: aggregate parts demand across all in-scope vehicles; bay-by-bay capacity allocation, cross-checked against the due-load forecast (7.4) for conflicts.
Rollout dates: start date, target completion date.
Completion criteria: percentage-of-eligible-fleet threshold, or a hard date, whichever the campaign specifies — required, not optional.
Exceptions: vehicles explicitly excluded and why (e.g., already withdrawn, already serviced elsewhere) — captured at build time and editable during rollout.
Outcome-measurement window: default 90 days post-completion (aligned to the Shared Operating Model’s Recurrence Chain window), editable per campaign.
Submit: routes per the evaluated approval path — Head of Maintenance approves directly (if Head of Maintenance only) or the campaign enters PROPOSED pending a VP Decision (read-only tracked here, deep link to VP Console).

Campaign Rollout Board (post-approval)

Per-bay execution state: a board with one column/row per bay, each showing not-started / in-progress / complete / exception counts for that bay’s in-scope vehicles.
Vehicle-level progress: a table of every in-scope vehicle, columns: plate/VIN, bay, status (not started/in progress/complete/excluded), WO link (if a WO has been emitted for this vehicle’s campaign work), days in current status.
Exclusions: vehicles removed from scope with reason (including the automatic “EXCLUDED — WITHDRAWN” fallout state per the Shared Operating Model §7/§9.2), always visible in a dedicated exclusions list, never silently dropped from the count.
Rescheduling: a single vehicle’s occurrence within the campaign can be deferred (new target date) without cancelling the whole campaign.
Completion: campaign reaches COMPLETE when its completion criteria are met; triggers the Outcome/Experiment record creation (PM Console, read-only reference here) and starts the measurement-window countdown.
Early termination: Head of Maintenance can terminate a campaign before completion (reason required) — remains queryable, never deleted, and still produces a (partial) Outcome record scoped to whatever was completed.

Worked example / counter-example (reproduced for engineering clarity)

An Investigation Campaign (“Confirm gear-wear root cause across Bundle R2, Q3”) carries its own sampling rule (“sample 15% of Bundle R2 weekly for 8 weeks”) and its own in-scope vehicles. It does not create a schedule to execute it; the Schedule generates weekly Occurrences → real WOs. At week 8, the campaign’s aggregated evidence informs a decision — confirmed defect leads to a new, separate fix Campaign (bounded, all Bundle R2 vehicles); the Investigation Schedule is then retired. Counter-example: “sample 15% of Bundle R2 weekly” with no end date and no decision criteria is a Schedule, not a Campaign; “replace all Bundle R2 gears” modelled as a long-recurrence Schedule (instead of a bounded, approved Campaign with a hypothesis and outcome measurement) is equally wrong.

Figure 2 — Maintenance Schedule vs. Campaign canonical model.

States & acceptance

A Campaign cannot be submitted without an objective/hypothesis, defined scope, and ≥1 Intervention — enforced client- and server-side, mirroring the PM Console’s Intervention Proposal validation for consistency.
Acceptance: an approved Campaign’s rollout board reflects real, individually-tracked vehicle states — never a single aggregate percentage with no vehicle-level detail available.

7.6 Taxonomy Governance

Purpose: the sole surface in Argo where a proposed failure mode becomes (or doesn’t become) a canonical taxonomy code. Full authority model per the Argo Shared Operating Model §3.

Proposed Modes queue

Columns: proposal title/description, raised by (Technician), endorsed by (Maintenance Supervisor, mobile or Maintenance Supervisor Web) with endorsement note, age, related WO(s) count, status (Raised/Endorsed/Rejected-by-Maintenance-Supervisor/Promoted/Merged/Rejected-by-Head of Maintenance).
A proposal must be Endorsed by a Maintenance Supervisor before it appears actionable to the Head of Maintenance (a Raised-only proposal shows in the queue but is visibly “awaiting Maintenance Supervisor endorsement,” not yet ready for Head of Maintenance decision) — enforcing the raise → endorse → promote/merge chain exactly.

Proposal Detail — endorsement history, promote/merge/reject

Full endorsement history: every endorsement or rejection along the chain, with actor/timestamp/note — an append-only audit trail.
Related evidence: the WO(s) that raised this proposal, with their Tier-1 capture evidence (read-only).
Promote action: mints a new canonical Tier-2 code (SYSTEM-COMPONENT-MODE format, per the Argo Shared Operating Model taxonomy structure). Requires: system, component, mode name, one-line engineering definition, default severity (P1–P3). On promote, every open WO whose Tier-1 capture matches this proposal’s pattern is re-labelled to reference the new code, and a version bump is recorded.
Merge action: folds this proposal into an existing canonical code. Requires selecting the target code. On merge, all historical and open records referencing the proposal (or any prior code being consolidated) show “superseded by {target code}” per the Shared Operating Model §8 rule 6 — history is never rewritten, only annotated forward.
Reject action: returns to the proposer (Technician/Maintenance Supervisor) with a reason, terminal unless re-raised as a new proposal.
Version bump: every Promote or Merge action increments the taxonomy’s version number, visible in the Reference tab (7.6 Reference) with a changelog entry.
Effect on open and historical records: fully specified above per action — this is the single most consequential action in Argo’s data model and must never silently reclassify a record without a visible, queryable audit trail entry.

Reference tab

The full current taxonomy (all systems and Tier-2 codes, per the table in Section 12/the Shared Operating Model), read-only, with each code’s version history and any “superseded by” annotations.

States & acceptance

Promote/Merge/Reject are each a single, irreversible-once-confirmed action (no silent undo) — but each produces a durable audit entry, so “irreversible” means the taxonomy moves forward, not that the history disappears.
Acceptance: promoting a code makes it immediately available to the mobile capture/analysis flows (out of scope here, but this console’s promote action must emit the event that makes that true) within one refresh cycle.

Figure 3 — Raise → endorse → promote/merge governance chain.

7.7 Inventory

The page is titled Inventory and carries three tabs: Approvals (the replenishment queue below), Stock (what is held, and where) and Parts (what has actually been consumed).

Stock

ID	Requirement
FR-S1	Stock is held per part per bay, with the date the level was last counted.
FR-S2	The tab reports units on hand, parts stocked, units received in the last 7 days and units issued in the last 7 days.
FR-S3	Stock on hand lists each part with its total on hand, the bays holding it and the date it last moved. It filters by search, bay and category, and resets.
FR-S4	A part opens a record showing where it sits by bay, and its assignment history: every receipt against its delivery note and every issue against the work order, vehicle, rider and technician it went to.
FR-S5	Issues are the same events reported under Parts; the two views cannot disagree.
FR-S6	The bay lens scopes the whole tab.
FR-S7	A count is a record, not a calculation. Every count carries where it was taken, what the record said, what was on the shelf, the variance, who counted it and the reason.
FR-S8	The figure can be corrected against what is physically there, from the part record, the stock row or a bay’s own stock table.
FR-S9	A correction names where first, the store or a named bay, and each option states what that place currently holds. Opened from a bay the place is stated rather than offered, so the wrong shelf cannot be corrected by accident.
FR-S10	A correction states the variance as the counted figure is typed, and what the on-hand figure will become, before it is applied.
FR-S11	A reason in words is required on every correction. There is no reason list, because the useful half of a correction is the sentence that accounts for it.
FR-S12	Applying moves the figure only where it was wrong, the store figure or that bay’s line, never both, and writes the correction into the count history with the actor and the day.
FR-S13	A bay’s record carries the stock that bay holds: the part, its category, its tracking, what is on hand, when it was last counted, when it last moved, and a correction beside each line. Part names open the part record, so a bay is a way into the same stock rather than a second copy of it.

Parts

Purpose: answer what was replaced, how much of it, and where — without leaving the console. Built from one row per part replaced on a repair: day, part, category, quantity, work order, plate, bay and technician.
Replacements by part — Part · Category · Replaced all round · Last 7 days · Bays · Last replaced. The all-round total is the running count for that part across every repair on record; the 7-day column is what makes a sudden spike visible against it.
Replacements by day — Day · Units replaced · Parts (the biggest by name, the rest as +N more) · Repairs · Bays. Every number is named, and units against repairs gives parts-per-repair for the day.
A part opens its own record: its totals, its own by-day breakdown, a by-rider table showing which riders and vehicles the part keeps going into, and every replacement behind the number (day, quantity, WO id, plate, rider, bay, technician) — so a count can be opened and checked rather than trusted.
Search, bay and category filters and a reset scope both tables; the bay lens scopes them too.
The date range sits in the head of both tables and scopes both, off one piece of state, with its own clear control. While it is on, the first two summary cards read Replaced in range and Last 7 days in range, because a card labelled all-time under a date filter is wrong.

Approvals

Purpose: the Head of Maintenance approval step in the bay replenishment chain (Maintenance Supervisor requests → Head of Maintenance approves → Cluster Inventory Manager fulfils), per the Argo Field Flow Fixes Spec §5.5/REQ-6 and Argo Shared Operating Model §2.21.

Approval queue

Columns: requesting bay, requesting Maintenance Supervisor, parts requested (list, with serialized/non-serialized indicator per the catalog’s flag), age, status (Requested/Approved/Fulfilled/Rejected).

Request Detail

Full parts list with quantities and current bay on-hand (read-only, sourced from the Atlas IMS per [VERIFY-2]).
Approve: routes to the Cluster Inventory Manager for fulfilment (an Atlas IMS-side action, [VERIFY-2] — this console emits the approval event; fulfilment tracking itself may be an IMS read-through pending that system’s confirmed contracts).
Reject: reason required, notifies the requesting Maintenance Supervisor.

Inventory constraints view

A cross-bay summary of low-stock flags and pending replenishment requests, so the Head of Maintenance can spot a systemic shortage (e.g., the same part low across 3 bays) rather than approving requests one at a time blind to the pattern.

States & acceptance

This entire page’s data contracts are explicitly dependent on [VERIFY-2] (Atlas IMS bay-level stock, read/write/transfer/bind APIs, canonical parts catalog) — the page is fully specified here in terms of required behaviour, but its live data binding cannot be finalized until IMS contracts are confirmed, per the Argo Field Flow Fixes Spec’s explicit instruction not to invent these contracts.

7.8 Reports & Operational Sign-Off

Purpose: the operational counterpart to the PM/VP review builders — a recurring sign-off artefact for Head of Maintenance’s own operational health.

Report Builder

Auto-populated sections: Command Centre KPI snapshot, Dispatch SLA performance, Bay-by-bay capacity summary, Campaigns in progress/completed this period, Taxonomy governance actions this period, Replenishment approvals this period.
Head of Maintenance narrative overlay per section; Preview (live re-fetch); Sign-off (freezes a hashed snapshot, mirrors the VP/PM Console pattern exactly for consistency); Export (PDF/DOCX).

History

Report history list with status, signer, and period-over-period diff on headline metrics.

States & acceptance

Identical sign-off immutability rule as the VP/PM Consoles: a signed report cannot be edited in place; a re-open creates a new draft version.

7.11 Investigations (assigned by the PM)

Purpose. The PM, Vehicle Operations analyses maintenance case data on their own console and, when a pattern shows up, raises an investigation and assigns it to a named owner. Where that owner is this role, the investigation is worked here. This is the maintenance side of the PM’s analysis loop: the PM asks the question, this console answers it on the record.

Layout. A page under Insight in the sidebar. A summary band (active, not started, in progress, running long) sits above a register of the investigations assigned to this role: reference, subject, who raised it, severity, how long it has been running (flagged red once it passes the period the PM set), and status. The head carries search, a status filter, a severity filter, a raised-from/raised-to date filter, a clear, and Export findings.

Record. A row opens the investigation: severity, days running, status, the scope of what is being investigated, and an activity log naming who did what and when — who opened it, that the assignment was emailed, when this role accepted it, every finding recorded, every reminder the PM sent, and the closure.

Actions. Start work moves it to In progress. Record a finding appends a stamped entry the PM reads back. Close investigation requires both a root cause and the action taken — it will not resolve without them — and a resolved investigation shows both back as its conclusion.

Boundary. Investigation actions only. Working an investigation never dispatches, reassigns, resolves or signs off a work order; that authority stays with the dispatch, scheduler and campaign surfaces of this console.

7.12 Notifications

Scoped to Head of Maintenance-relevant event types: WO blocked/escalated to Head of Maintenance (high priority), capacity conflict detected, taxonomy proposal endorsed (ready for Head of Maintenance decision), a bay replenishment request awaiting approval (in-app and email), campaign approval routed back from VP, schedule/campaign approaching its due/rollout date, and (TH-7) a case raised, triaged, resolved or blocked in the cluster, Inventory fulfilling a maintenance inventory request with its delivery note (opening the receipt), a recovered part accepted by Inventory, and the Head of Maintenance’s own item request approved (in-app and email) or declined with the reason. The full contract is §14.

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

7.13 Settings

Saved views (Dispatch filters, Scheduler lane visibility, Campaign status filters, Taxonomy proposal sort).
Notification preferences, delegate (Dispatch Maintenance Service Lead scope, acting-Head-of-Maintenance) management, default bay lens.

7.14 Retrievals

A retrieval is a tricycle repossessed from a rider. Retrieval Logistics raises it, approves it and dispatches it either into the field or to a maintenance bay; a bay dispatch mints an Argo work order against the bay it chose. This page is the maintenance end of that chain.

Page and tabs

Three tabs, all scoped by the bay lens: Incoming (the tricycles), Parts recovered (what came off, and where each part went) and Recovery (the cross-bay reading).

Incoming

Four KPIs, each setting the filter it names: Awaiting arrival, In strip-down, Completed, Awaiting inventory acceptance. Awaiting acceptance is a reading of a record’s parts rather than a status the record holds, so it is a value of the same status filter, not a card that filters nothing.
Table: Case (Retrieval), WO ID, Plate, Rider (name, phone), Bay, Sent (date, dispatcher), Status, Recovered (recovered against expected). The shape follows Tricycle cases, so the references sit where a reader already expects them. A retrieval with no strip-down open shows no work order. There is no last-update column and no actions column.
Search, status and bay filters, a sent-date range, a reset that appears only once something is filtered, and an export. The trigger is neither a column nor a filter; it reads on the record.
The row opens the record, and the one step it can take next is the primary button there.

The retrieval record

Opens on row click as an inner page whose back control names the tab it came from.
Two panels: Overview (the retrieval and the vehicle side by side, then the work order and Location side by side, then the parts manifest, then the status trail), Parts recovered.
The retrieval carries the retrieval: its case and work-order references, the rider’s 4-week efficiency, who raised it, the sent date, how long it has been open, the bay’s answer and the work order status.
The vehicle carries what is true of the keke: plate, the rider on it with their number, chassis, fitted VCU, kit revision and odometer. A bay and a work-order state describe the retrieval, not the vehicle.
The strip-down carries the technician, hours on the bench, and when it opened and closed.
Location carries the bay it was sent to and, from RadR, where the tricycle actually is: a street address with the time it was last seen, opening in Google Maps. A retrieval nobody has answered for therefore says where the keke got to.
The parts manifest is what the register says is fitted to that keke: Part, Tracking, Recovered, Serial. It carries every unit’s serial before the vehicle is touched; a line nobody has ruled on reads Not yet recovered, and the reason a part was not recovered rides under that state rather than in a column of its own.
The trail is derived from the record’s own stamps, so the trail and the record cannot drift. A step not yet reached reads as what it is waiting for.

Parts recovered

Table: Serial, Part, Came off (plate, rider, date taken), Outcome (badge, where the part is), Case (Retrieval). A recovered part carries its serial and nothing else; the bay does not judge it.
Two KPIs that partition every part: Awaiting acceptance, Accepted by inventory.
Search, outcome and bay filters, a reset and an export.

Recovery

Recovery rate and unaccounted parts over a closed-date range, by bay: Bay, Retrievals, Expected, Recovered, Recovery rate, Unaccounted.
Unaccounted is a number of its own rather than a rounding on the rate, because a part that leaves a rider and never reaches a shelf is what this tab exists to find.
A bay with nothing stripped in range reads as no data, never 0%.

8. Functional Requirements

HOM-FR-001 — Reassign a Work Order across bays

The Head of Maintenance (or Dispatch Maintenance Service Lead) reassigns an open WO to a different bay/technician with capacity awareness.

Actor: Head of Maintenance or Dispatch Maintenance Service Lead
Preconditions: WO is in a non-terminal status (NEW/IN_REPAIR/BLOCKED); target bay exists and is active.
Trigger: Actor selects a WO in the Dispatch Workbench and chooses Reassign in the Inspector pane.
Happy path: System shows each candidate bay’s current load vs. capacity (Shared Operating Model §4.4); actor selects a bay (and optionally a specific technician); WO’s bay/assignee fields update immediately; a timeline entry is added.
Alternate paths: Actor selects a bay with an active capacity conflict — an inline warning is shown but the reassignment is not blocked (informed override).
Validation: Target bay must be active; a WO cannot be reassigned to a bay that is not part of the active roster.
Permission rule: role ∈ {HEAD_OF_MAINTENANCE, DISPATCH_SERVICE_LEAD}.
State transition: No WO status change — bay/assignee fields update in place; status remains whatever it was (NEW/IN_REPAIR/BLOCKED).
Data side effects: WO record’s bay and assignee fields updated; timeline entry appended with actor/timestamp/from-bay/to-bay.
Notification side effects: Previous and new assignee/bay notified as applicable (e.g., the new bay’s Maintenance Technician Lead sees the WO appear in their queue).
Downstream surface effects: Mobile Maintenance Technician Lead/Maintenance Supervisor apps (out of scope, referenced) see the WO under its new bay/assignee within one refresh cycle.
Failure & recovery: If the write fails, the WO remains at its prior bay/assignee with an inline retry — no partial reassignment state.
Acceptance criteria: The reassigned WO appears in the new bay’s Bay Detail queue and disappears from the old bay’s, verified by the reconciliation tests.

HOM-FR-002 — Unblock a Blocked Work Order

The Head of Maintenance (or Dispatch Maintenance Service Lead, for dispatch-scoped reasons) resolves a Blocked WO and returns it to its prior step.

Actor: Head of Maintenance (all reasons) or Dispatch Maintenance Service Lead (dispatch-scoped reasons only, per Section 5)
Preconditions: WO status = BLOCKED.
Trigger: Actor reviews the block reason/escalation timeline in WO Detail and clicks Unblock.
Happy path: System requires a resolution note, WO returns to its prior step (e.g., IN_REPAIR) per the Shared Operating Model §2.3 state machine, timeline entry appended.
Alternate paths: Actor instead escalates further (e.g., Dispatch Service Lead cannot resolve an inventory-approval-requiring block and forwards it to the Head of Maintenance) — WO remains BLOCKED with an updated escalation level.
Validation: Resolution note required, non-empty; inventory-approval-requiring resolutions are blocked for the Dispatch Service Lead role (Section 5 permission rule).
Permission rule: role ∈ {HEAD_OF_MAINTENANCE} for all reasons; role ∈ {DISPATCH_SERVICE_LEAD} only for dispatch-scoped reasons (rider-as-blocker rescheduling, reassignment-resolvable blocks).
State transition: WO: BLOCKED → its prior step (per the Shared Operating Model §2.3 state machine, e.g., IN_REPAIR).
Data side effects: WO record updated with resolution note; timeline entry appended; the resolve-clock’s paused state ends per the Shared Operating Model §2.3a rule.
Notification side effects: The WO’s current holder (Technician or Maintenance Supervisor, per the state it returns to) is notified it is active again.
Downstream surface effects: Mobile apps reflect the unblocked WO in the relevant queue within one refresh cycle.
Failure & recovery: If the underlying blocking condition still applies (e.g., no-stock resolution attempted before replenishment actually arrived), the system does not re-validate this automatically — the actor is responsible for confirming the condition is actually resolved before unblocking; this is a documented judgment call, not a system gap.
Acceptance criteria: The unblocked WO’s timeline shows the full block → resolution sequence, and it is immediately visible and actionable in its new (or restored) holder’s queue.

HOM-FR-003 — Promote a proposed taxonomy mode to a canonical code

The Head of Maintenance mints a new canonical Tier-2 taxonomy code from a Maintenance Supervisor-endorsed proposal.

Actor: Head of Maintenance exclusively.
Preconditions: Proposal status = Endorsed (has passed Maintenance Supervisor endorsement).
Trigger: Head of Maintenance reviews the proposal and endorsement history, clicks Promote, and completes the code definition (system/component/mode/definition/severity).
Happy path: System mints the new code, re-labels every open WO whose Tier-1 capture matches the proposal’s pattern to reference it, records a version bump, and closes the proposal as Promoted.
Alternate paths: Head of Maintenance instead Merges (folds into an existing code) or Rejects (reason required, returns to proposer).
Validation: All code-definition fields (system, component, mode, definition, severity) required; a proposal not yet Endorsed cannot be Promoted (shown as disabled with a tooltip explaining why).
Permission rule: role = HEAD_OF_MAINTENANCE exactly — no other role, including any Maintenance Supervisor, can execute this action (Argo Shared Operating Model §3).
State transition: Proposal: Endorsed → Promoted (terminal). New Taxonomy Code: (none) → Active, version N.
Data side effects: New code record created; every matching open WO’s Tier-2-candidate mapping updated to include it; taxonomy version bumped with a changelog entry; append-only audit log entry recorded (Section 5.3).
Notification side effects: The proposing Technician and endorsing Maintenance Supervisor are notified their proposal was promoted, with the new code’s ID.
Downstream surface effects: The new code becomes available to mobile capture/resolution flows and the Maintenance Supervisor Web/PM Console analytics within one refresh cycle.
Failure & recovery: If the re-labelling of open WOs partially fails (e.g., a concurrent edit conflict on one WO), the code is still minted and the proposal still Promoted; the specific failed WO(s) are flagged for manual reconciliation rather than blocking the entire promotion.
Acceptance criteria: The new code appears in the Taxonomy Reference tab immediately with its version history; every affected open WO shows the new code as an available Tier-2 option.

HOM-FR-004 — Approve a Campaign (Head of Maintenance tier)

The Head of Maintenance approves a proposed Campaign that falls within Head of Maintenance’s own approval authority (does not require VP sign-off per the routing rule).

Actor: Head of Maintenance exclusively.
Preconditions: Campaign status = PROPOSED; the routing rule (Shared Operating Model §4.5) has evaluated this campaign as Head of Maintenance only.
Trigger: Head of Maintenance reviews the campaign definition and clicks Approve in the Campaign Builder/Detail.
Happy path: Campaign transitions to APPROVED, becomes eligible to enter ROLLING_OUT (a distinct explicit action, or automatic on its stated start date — configurable per campaign), and the Rollout Board (7.5) activates.
Alternate paths: Head of Maintenance instead requests changes (returns to the proposing PM with a note, if PM-originated) or rejects (terminal, reason required).
Validation: Campaign must have passed its own build-time validation (objective, scope, ≥1 intervention, all required per Section 7.5) before Approve is available.
Permission rule: role = HEAD_OF_MAINTENANCE; if the routing rule instead evaluates this campaign as requiring VP sign-off, this action is unavailable and the campaign instead awaits the VP Console’s Decision (cross-referenced, not duplicated authority).
State transition: Campaign: PROPOSED → APPROVED → ROLLING_OUT.
Data side effects: Campaign record updated; Rollout Board data structures (per-bay, per-vehicle progress) initialized.
Notification side effects: The proposing PM (if PM-originated) notified of approval.
Downstream surface effects: PM Console’s Intervention Proposal detail reflects APPROVED/ROLLING_OUT status within one refresh cycle; VP Console is not involved for Head of Maintenance tier campaigns.
Failure & recovery: None special beyond standard save-failure retry.
Acceptance criteria: An approved Head of Maintenance tier campaign’s rollout board is populated with its full in-scope vehicle list within one refresh cycle of approval.

HOM-FR-005 - Receive a bay-dispatched retrieval

A retrieval dispatched to a maintenance bay appears on this console the moment Retrieval Logistics dispatches it.

Actor: system, on dispatch by Retrieval Logistics.
Preconditions: the retrieval is approved, its dispatch type is bay, and the destination bay is active.
Trigger: Retrieval Logistics confirms a bay dispatch.
Happy path: the record lands on Incoming scoped to the destination bay, carrying the dispatch record, the rider, the trigger and the Argo work-order reference.
Alternate paths: none. A retrieval cannot be created on this console.
Validation: the destination bay must be one of the cluster’s active bays.
Permission rule: role in {HEAD_OF_MAINTENANCE, DISPATCH_SERVICE_LEAD} to read; nobody may create.
State transition: the record enters at Awaiting arrival, and stays there until the bay answers.
Data side effects: none beyond the record appearing under the bay.
Notification side effects: the destination bay is notified.
Downstream surface effects: the Argo bay app shows the same retrieval on its New rail.
Failure & recovery: a dispatch to an inactive bay is refused at source and stays with Retrieval Logistics.

HOM-FR-006 - The bay answers whether the tricycle is there

Retrieval Logistics dispatches and cannot see where the tricycle got to, so the bay’s answer is the arrival.

Actor: Head of Maintenance, or the bay confirming on Argo.
Preconditions: the retrieval is Awaiting arrival.
Trigger: actor answers Is the tricycle at the bay?, or opens the strip-down without answering.
Happy path: the actor answers yes; the answer is stamped as the arrival and a strip-down work order opens, unassigned. The technician is named when the strip-down is recorded. Opening the work order on an unanswered retrieval confirms the arrival by itself, stamping it and recording on the trail that it was confirmed that way: a keke that is not at the bay cannot be stripped.
Alternate paths: answering no records the answer, notifies Retrieval Logistics and opens no work order. No reason is asked for. The retrieval stays Awaiting arrival and can be answered again.
Validation: the answer is the bay’s alone.
Permission rule: role in {HEAD_OF_MAINTENANCE, DISPATCH_SERVICE_LEAD, MAINTENANCE_SUPERVISOR at that bay}.
State transition: Awaiting arrival to In strip-down on yes; unchanged on no.
Data side effects: the answer and its stamp on yes; the answer alone on no.
Notification side effects: Retrieval Logistics is notified when the answer is no.
Downstream surface effects: the Argo bay app shows the work order on its In-repair rail.
Failure & recovery: if the write fails no work order is opened and the record stays awaiting confirmation.

HOM-FR-007 - The retrieval strip-down is a work order of its own type

Confirming arrival opens a work order of type Retrieval strip-down against the destination bay.

Actor: system, on confirmation.
Preconditions: arrival confirmed.
Trigger: HOM-FR-006 happy path.
Happy path: the work order opens unassigned, runs to IN_REPAIR when the strip-down is recorded, and closes CLOSED_RETRIEVED.
Alternate paths: none. It never reaches IN_SERVICE or CLOSED_NOT_FAULT, because the vehicle is not going back to a rider.
Validation: a retrieval carries at most one open strip-down.
Permission rule: role in {HEAD_OF_MAINTENANCE, DISPATCH_SERVICE_LEAD, MAINTENANCE_SUPERVISOR at that bay}.
State transition: as above.
Data side effects: a work order carrying bay, technician and hours.
Notification side effects: the named technician is notified.
Downstream surface effects: the work order is visible wherever this cluster’s work orders are, filterable by type.
Failure & recovery: a failed open leaves the retrieval awaiting confirmation rather than half-opened.

HOM-FR-008 - Work-order figures are filterable by type

Retrieval strip-downs count as work orders and are excluded from every fault-quality metric.

Actor: system, on every work-order aggregate.
Preconditions: work orders carry a type.
Trigger: any surface that counts or measures work orders.
Happy path: open-WO counts include strip-downs and can be filtered by type; median time to resolve, first-pass validation and WO ageing exclude them.
Alternate paths: a surface reporting deliberately on retrievals filters to the type instead of excluding it.
Validation: no aggregate may silently mix the two.
Permission rule: unchanged from the surface doing the counting.
State transition: none.
Data side effects: none.
Notification side effects: none.
Downstream surface effects: the PM Console’s maintenance metrics inherit the same exclusion.
Failure & recovery: not applicable.

HOM-FR-009 - Closing the strip-down mints the recovered parts

Closing the strip-down sends the whole manifest, and the actor confirms every part came off before it will go.

Actor: Head of Maintenance, or the bay on Argo.
Preconditions: the strip-down is open, or the retrieval has arrived and opening the work order is part of the same act.
Trigger: actor records the strip-down.
Happy path: the actor confirms that all parts on the manifest were recovered and names the technician. A kit comes off a keke whole, so every line is recovered: closing mints one Parts-recovered row per line and sends it to Inventory in the same act, each with no condition and no outcome.
Alternate paths: none. The manifest is what the register holds against that keke, and stripping the tricycle recovers it.
Validation: the close is blocked until all parts on the manifest are confirmed recovered. Nothing is recorded line by line, and hours on the bench are computed from the arrival and close stamps rather than typed.
Permission rule: role in {HEAD_OF_MAINTENANCE, DISPATCH_SERVICE_LEAD, MAINTENANCE_SUPERVISOR at that bay}.
State transition: In strip-down to Parts to settle.
Data side effects: manifest states, serials, reasons, hours, and the minted part rows.
Notification side effects: none.
Downstream surface effects: none beyond the minted part rows.
Failure & recovery: a failed close leaves the work order open and mints nothing.

HOM-FR-010 - A recovered part is settled to Inventory or to the bench

Each recovered part takes its own condition and its own destination.

Actor: Head of Maintenance, or the bay on Argo.
Preconditions: the part is Not yet decided.
Trigger: actor settles the parts.
Happy path: condition is one of Unused, Refurbished, Used or Faulty. Every recovered part goes back to Inventory; there is no destination to choose.
Alternate paths: a faulty part requires a discrepancy note and goes back as faulty, for the warehouse to disposition.
Validation: a condition is required on every part; a faulty part without a note is refused.
Permission rule: role in {HEAD_OF_MAINTENANCE, DISPATCH_SERVICE_LEAD, MAINTENANCE_SUPERVISOR at that bay}.
State transition: the part leaves Not yet decided.
Data side effects: condition, destination, note and the settle stamp.
Notification side effects: none.
Downstream surface effects: none until the return leaves (HOM-FR-012).
Failure & recovery: a refused settle leaves every part undecided rather than settling some of them.
Explicitly not offered: fitting a recovered part to another tricycle, or holding one at the bay to repair. Maintenance strips and returns; Inventory reissues and dispositions.

HOM-FR-012 - Sending is not returning

A returned part is awaiting acceptance until the warehouse takes it, and the claimed condition stays editable for exactly that long.

Actor: Head of Maintenance; the Inventory Manager accepts.
Preconditions: the part has been claimed in a condition.
Trigger: the settle dispatches it.
Happy path: the part reads Sent to inventory under the retrieval’s own reference, and Accepted by inventory once the warehouse takes it.
Alternate paths: where the warehouse records a condition other than the one claimed, the record shows both rather than overwriting the claim.
Validation: a change to a faulty claim requires a discrepancy note, and no change is accepted after acceptance.
Permission rule: the claim is editable by role in {HEAD_OF_MAINTENANCE, DISPATCH_SERVICE_LEAD}; acceptance is the Inventory Manager’s.
State transition: Sent to inventory to Accepted by inventory.
Data side effects: the claim, the discrepancy note, and the acceptance stamp.
Notification side effects: the Inventory Manager’s returns desk is notified on dispatch; this console is notified on acceptance.
Downstream surface effects: the return lands on the Inventory Manager’s returns desk under the same reference.
Failure & recovery: a failed dispatch leaves the part decided but not sent.

HOM-FR-013 - Every settlement is a movement on the store’s own lane

A retrieval return uses the store’s existing outgoing lane rather than a second path.

Actor: system, on dispatch.
Preconditions: HOM-FR-012 happy path.
Trigger: a part is sent to Inventory.
Happy path: the return is written to the outgoing lane under the retrieval’s reference and to the movement log with who moved it, and counts in the Stock tab’s Outgoing to Inventory figure.
Alternate paths: none.
Validation: the movement is marked as coming from a retrieval, so a part that was never store stock never reads as store stock leaving, and store usable quantities are unaffected.
Permission rule: system.
State transition: none beyond HOM-FR-012.
Data side effects: one outgoing row and one movement row per part.
Notification side effects: none beyond HOM-FR-012.
Downstream surface effects: Inventory, Stock shows the movement.
Failure & recovery: a failed write leaves the part decided but not sent, with nothing half-logged.

8.9 Investigations assigned by the PM

ID	Requirement
FR-N1	An investigation raised on the PM, Vehicle Operations console and assigned to this role appears in this console’s Investigations register, and an assignment notification lands in this console’s notifications naming the reference, who raised it and what it is. It is never left to be noticed.
FR-N2	The register shall filter by search, status, severity and raised date, show a live count, clear its filters in one action, and summarise active / not started / in progress / running long.
FR-N3	Opening a record shall show the scope and a full activity log naming actor, role and timestamp for every event: opened, assignment emailed, accepted, each finding, each reminder, closure.
FR-N4	This role can start work on an investigation and record findings against it; every finding is stamped and readable by the PM.
FR-N5	Closing requires a root cause and the action taken. The system shall refuse to resolve an investigation with either missing, and shall display both on the resolved record.
FR-N6	This role can export a findings pack from this console. Investigation actions never dispatch, reassign, resolve or sign off an operational record.

8.10 Send feedback

ID	Requirement
FR-N7	Send feedback shall be reachable from the sidebar as well as the topbar — a topbar-only entry point is too easy to miss. Submissions land in the PM’s Tech feedback queue.

9. Entity & Lifecycle Definitions

The Head of Maintenance Console owns Work Order (operational state), Maintenance Schedule, Campaign (operational rollout), and Taxonomy (governance) outright (full definitions in the Argo Shared Operating Model §2/§4, reused verbatim). It consumes, read-only, Cohort, Onboarding Cohort, Evidence Packet, and Engineering-Feedback/Roadmap data from the PM, onboarding and Maintenance Supervisor Web Consoles.

9.1 Work Order — full status table (Shared Operating Model §2.3, reused verbatim)

Status	Meaning	Set by
NEW	Observed fault captured; awaiting fault-capture validation.	Maintenance Technician Lead / Argonaut, on capture
IN_REPAIR	Fault-capture validated; parts requisition and/or repair and resolution logging underway.	Maintenance Supervisor, on fault-capture validate
BLOCKED	Halted with a reason; escalates up the chain.	Maintenance Technician Lead → Maintenance Supervisor → Head of Maintenance
IN_SERVICE	Repair validated; vehicle returned to service (terminal).	Maintenance Supervisor, on RTS
CLOSED_NOT_FAULT	Triaged not-a-fault, Maintenance Supervisor-confirmed (terminal; excluded from reliability metrics).	Maintenance Supervisor, on not-a-fault confirm

Figure 4 — Work-order state machine with holder/gate overlay (detailed).

9.2 Maintenance Schedule

Status	Entry	Exit	Set by
Draft	Builder started.	Activated, or abandoned (remains Draft).	Head of Maintenance
Active	Activated.	Paused or Retired.	Head of Maintenance
Paused	Actor pauses.	Resumed (→ Active) or Retired.	Head of Maintenance
Retired	Actor retires.	Terminal.	Head of Maintenance

9.3 Campaign (operational rollout, owned here from Approved onward)

Status	Entry	Exit	Set by
Proposed	Built here or received from PM Console.	Approved (Head of Maintenance tier) or Awaiting VP Decision (if routed).	Head of Maintenance / PM
Approved	Head of Maintenance approval (HOM-FR-004) or VP Decision approval.	Rolling Out.	Head of Maintenance / VP
Rolling Out	Rollout begins (start date or explicit action).	Complete or Terminated Early.	System / Head of Maintenance
Complete	Completion criteria met.	Terminal — triggers Outcome/Experiment creation (PM Console).	System
Terminated Early	Head of Maintenance terminates with reason.	Terminal — triggers a partial Outcome/Experiment record.	Head of Maintenance

9.4 Taxonomy Proposal (governance)

Status	Entry	Exit	Set by
Raised	Technician raises a proposed mode.	Endorsed or Rejected-by-Maintenance-Supervisor.	Technician
Endorsed	Maintenance Supervisor endorses and forwards.	Promoted, Merged, or Rejected-by-Head of Maintenance.	Maintenance Supervisor
Rejected-by-Maintenance-Supervisor	Maintenance Supervisor rejects.	Terminal (unless re-raised as a new proposal).	Maintenance Supervisor
Promoted	Head of Maintenance promotes (HOM-FR-003).	Terminal — new canonical code minted.	Head of Maintenance
Merged	Head of Maintenance merges into an existing code.	Terminal — cross-referenced, history annotated forward.	Head of Maintenance
Rejected-by-Head of Maintenance	Head of Maintenance rejects.	Terminal (unless re-raised).	Head of Maintenance

10. End-to-End Workflows

10.1 Blocked-WO escalation and resolution

Initiator: Technician (mobile, out of scope) blocks a WO with a reason (no stock / rider blocker / awaiting replenishment / other, per the Argo Field Flow Fixes Spec §7).
The block escalates: Technician → Maintenance Supervisor (mobile) → Head of Maintenance, per the level field.
Participating: Dispatch Workbench (this console) surfaces the block once it reaches Head of Maintenance level.
Record changes: WO status BLOCKED; escalation timeline entry appended at each level.
Head of Maintenance (or Dispatch Service Lead, if dispatch-scoped) resolves via Unblock (HOM-FR-002) or approves a related Replenishment Request (7.7) if the block was no-stock.
Notification: the WO’s next holder is notified it is active again.
SLA/timer: block age is visibly tracked; the resolve-clock pause rule (Shared Operating Model §2.3a) applies while BLOCKED.
Terminal state: WO returns to IN_REPAIR (or its prior step) and continues through the normal state machine to IN_SERVICE.

Figure 5 — Cross-surface interaction, Head of Maintenance Console highlighted.

10.2 Taxonomy governance: raise → endorse → promote/merge

Initiator: Technician raises a proposed mode (mobile, out of scope) on a WO where the confirmed cause doesn’t fit an existing code.
Maintenance Supervisor (mobile or Maintenance Supervisor Web) endorses or rejects, forwarding endorsed proposals to Head of Maintenance.
Head of Maintenance reviews in Taxonomy Governance (7.6) and Promotes, Merges, or Rejects (HOM-FR-003).
Record changes: proposal lifecycle per Section 9.4; on Promote/Merge, taxonomy version bump and open-WO re-labelling.
Notifications: proposer and endorser notified of the final decision.
Terminal state: a new or consolidated canonical code, immediately available fleet-wide, with full historical auditability.

11. Data Requirements

Field	Definition
Source entities (owned)	Work Order (operational state), Maintenance Schedule, Campaign (rollout), Taxonomy (Section 9).
Source entities (consumed)	Cohort, Onboarding Cohort, Evidence Packet, Engineering-Feedback/Roadmap Item (read-only, from PM/onboarding/Maintenance Supervisor Web Consoles); Vehicle (shared spine, and the sole source of a vehicle’s VIN and its home bay).
Canonical IDs	WO IDs, Bay IDs, Schedule IDs, Campaign IDs, and Taxonomy code IDs are minted here as the owning console; Cohort/Vehicle IDs are always referenced from their owning source, never re-minted.
Freshness	Command Centre and Dispatch Workbench: real-time (no cache) given their operational, decision-critical nature. Scheduler due-load forecast: cached 15 minutes with explicit “as of” timestamp.
Aggregation level	WO-level detail throughout Dispatch; bay-level for capacity; cluster-wide for the Command Centre KPI band.
Retention	Work Orders, Schedules, Campaigns, and Taxonomy actions retained indefinitely (permanent operational and governance record).
Data-quality rules	A capacity forecast never silently omits a data source (e.g., a bay with no roster data shows “roster not configured” rather than a false-zero capacity).
Missing-data behaviour	A WO with an unresolved [VERIFY-1] canonical vehicle identifier still displays with whatever identifying fields are available (plate/VIN/VCU), never blocked from view for missing ID resolution.
Stale-data indicators	Explicit stale tag on any cached view (Scheduler forecast) older than 2× its refresh interval, matching the other consoles’ convention.
Reconciliation rules	Fleet-Ready %, VRI distribution, cohort recurrence, and COPQ reconcile exactly with the PM and VP Consoles (Section 20 tests).
Export schema	Dispatch export (CSV): wo_id, vehicle_id, bay, status, holder, gate, severity, age_days, assignee. Taxonomy export: code_id, system, component, mode, definition, severity, version, superseded_by.

12. Metrics & Analytical Definitions

Reuses the Argo Shared Operating Model’s canonical formulas (Section 5) without redefinition.

Metric	Numerator / denominator	Window	Drill-down	Incomplete-data behaviour
Fleet-Ready %	(Healthy + routine-due) ÷ active fleet	Real-time	→ Fleet Status Wall filtered view	Telemetry-dark shown as separate Unknown slice, never Healthy
Median time-to-resolve	Median hours, in-bay confirmed → Resolved · the clock starts when Is the tricycle in the bay? is set to yes (BLOCKED-pause applies)	Rolling 7/30-day toggle	→ Dispatch Workbench filtered to closed WOs in window	Excludes still-open WOs, shown alongside open count
Repeat rate	Cases whose unit had a case of the same fault class inside the 30 days before it ÷ cases in the window. One definition shared with the PM Vehicle Operations console, both computed from these case records rather than one copying the other’s figure. First-time fix is its complement, never a second computation.	Rolling 30-day	→ Dispatch Workbench filtered to the recurring vehicles	“Sample too small” below 10 cases
Due-load / capacity conflict	Forecast technician-hours ÷ rostered capacity, per bay per day	8-week forward forecast	→ Bay Detail capacity panel	“Roster not configured” if capacity data missing, never a false-zero
Cohort recurrence rate (reference)	Cohort vehicles recurring after fix ÷ cohort size	Per Shared Operating Model §5.1	→ read-only reference to PM Console Cohort Detail	“Sample too small” below 5 members
Cost of Poor Quality (reference)	Rider-days-lost value + direct repair spend	Rolling 30-day	→ read-only reference to PM/VP Consoles	Repair-spend-only with note if earnings proxy unset

Due: the count of occurrences within their schedule’s notice distance, across every schedule that generates them.
Overdue: the count of occurrences past their due point, across every schedule that generates them: the due distance, or the due date on an ad hoc schedule.
Due this week (hours): the technician-hours the week’s occurrences represent, summed from each schedule’s hours per service.
Spare capacity: the hours a week set aside less the load standing at the bays, summed across them, naming any bay over its own figure and by how much. This is the second half of the question this page exists to answer, and it opens Bay Operations.
Work waiting: the preventive-maintenance backlog — occurrences generated but not yet dispatched.

Global search (⌘K): WOs, bays, schedules, campaigns, taxonomy proposals, by ID/name/free-text.
Faceted filters: Dispatch by bay/status/severity/gate/age; Scheduler by schedule/type/bay/status; Campaigns by status; Taxonomy by proposal status/age.
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 WO/bay/schedule/campaign/proposal detail pages in ⌘K.
Deep links: every notification and cross-console reference resolves to the exact record.
Per-bay lens: a persistent bay filter (settable as default in Settings) that scopes Dispatch, Scheduler, and Campaigns simultaneously for focused single-bay work, toggleable back to cluster-wide view with one click.
Every data table carries a search over its visible identifiers, faceted filters in its table-card head, and a From / To date range on the table’s primary date.
Every table that shows a vehicle plate also shows a Rider column and a Last-recorded-mileage column immediately after the plate.

14. Notifications & Event Contract

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

Trigger	Recipient	Channel	Priority	Deep link
WO blocked and escalated to Head of Maintenance level	Head of Maintenance	In-app + push + Notification Centre	High	WO Detail (Dispatch)
Capacity conflict detected (Shared Operating Model §4.4)	Head of Maintenance	In-app + Notification Centre	Normal (High if <7 days to conflict)	Bay Detail capacity panel
Taxonomy proposal endorsed (ready for Head of Maintenance decision)	Head of Maintenance	In-app + Notification Centre	Normal	Taxonomy Proposal Detail
Bay replenishment request awaiting approval (TH-7)	Head of Maintenance	In-app + email + Notification Centre	Normal	Replenishment Request Detail
Campaign approval routed back from VP	Head of Maintenance	In-app + Notification Centre	Normal	Campaign Rollout Board
Schedule/campaign approaching due/rollout date	Head of Maintenance	In-app + Notification Centre	Normal	Scheduler / Campaign Detail
Swap gate message still unacknowledged after repeated retries (Section 15.2)	Head of Maintenance	In-app + Notification Centre	High	Rider record for the vehicle
Case raised, triaged, resolved or blocked in the cluster (TH-7)	Head of Maintenance	In-app + Notification Centre	Normal	Case / WO Detail (Dispatch)
Inventory fulfilled a maintenance inventory request, with its delivery note (TH-7)	Head of Maintenance	In-app + Notification Centre	Normal	The store receipt against that delivery note (§7.2)
Recovered part accepted by Inventory (TH-7)	Head of Maintenance	In-app + Notification Centre	Normal	Retrieval record, Parts recovered
Item request raised by the Head of Maintenance approved (TH-7)	Head of Maintenance	In-app + email + Notification Centre	Normal	Item request record
Item request raised by the Head of Maintenance declined, with the reason (TH-7)	Head of Maintenance	In-app + Notification Centre	Normal	Item request record

The Scheduler sends the swap gate Service due, Service breached and Cleared for each rider as their occurrence changes state (Section 15.2).

Investigation assigned (from the PM Console). Trigger: the PM assigns an investigation to this role. Delivery: a notification in this console naming the reference, the raiser and the subject, linking to the Investigations register, plus an email to this role. Follow-ups: a reminder from the PM raises a further notification; an investigation left unresolved past the period the PM set is flagged running over on both consoles.

15. Integrations & Cross-Surface Effects

PM Console: consumes Intervention Proposals as Campaign inputs; provides Campaign rollout status back to PM’s Outcomes view; Cohort data is read-only reference here.
VP Console: Campaigns/Schedules exceeding the routing threshold (Shared Operating Model §4.5) are submitted as Decisions there; this console shows the Decision’s status read-only.
Maintenance Supervisor Web Console: taxonomy endorsements may originate from Maintenance Supervisor Web’s analytical review, not only the mobile validation gate; this console’s Taxonomy Governance reads endorsements from either source identically.
Maintenance Technician Lead mobile / Maintenance Supervisor mobile (out of scope, referenced only): source of Work Order creation, capture, requisition handshake, and RTS — this console reads and operates on WOs at the dispatch/bay level but never performs capture, requisition handshake steps, or RTS itself.
Atlas Inventory Management System [VERIFY-2]: source of truth for parts catalog, bay-level stock, and replenishment fulfilment; this console’s Replenishment Approvals page is fully specified but its live data binding depends on confirmed IMS contracts.
Auth / role management [VERIFY-7]: consumes role assignments for HEAD_OF_MAINTENANCE / DISPATCH_SERVICE_LEAD from an external identity source of record.
Exports: Operational reports (PDF/DOCX), Dispatch/Taxonomy CSV exports generated in-console.
Scheduler → Argo: a due schedule occurrence emits a work order into Argo, either held for a Maintenance Supervisor to confirm or auto-created, per the schedule.
Argo → VCU: recording a scheduled service complete sends the service-complete command to the vehicle’s VCU, and confirming a deferral in this console sends the reset command. Both commands are Telpo’s (Section 15.1).
Scheduler → swap gate: the Scheduler sends the swap gate each rider’s service status as Service due, Service breached and Cleared (Section 15.2). Past the service limit the rider’s next battery swap is blocked, and a recorded service or a deferral lifts the block. Passing the limit does not lock the vehicle.
Argo / Forge lifecycle handoff: the emitted work order runs the standard lifecycle (NEW → IN_REPAIR → BLOCKED → validated / closed) with execution on the Forge floor app; this console tracks and monitors the occurrence up to dispatch, and Argo and Forge own it thereafter.

15.1 Telemetry contract

Every occurrence state on the Scheduler is computed from telemetry, and two commands to the vehicle’s VCU close or restart a service cycle. What the console reads, what is sent to the VCU and what the console does when a reading does not arrive are stated here.

What the console reads

Signal	Per	Used for	Notes
Distance since last service	Vehicle	Every occurrence state: Projected, Due, Overdue, Past limit	The VCU derives it from its own odometer and the last recorded service. It is the only signal the console offers as a condition trigger.
Distance rate (km/day)	Rider	Turning a distance from a threshold into days	Stated on the register, in the service-limit line and in Argo as “how many days at this rider’s rate”.
Odometer	Vehicle	The rider record, the defer sheet, Argo and the oil change next-due calculation	A deferred occurrence is due at its come-in mileage on this reading.
Position	Vehicle	The Fleet Status Wall	Absent live GPS the wall groups by bay rather than plotting.

What is sent to the VCU

Command	When	Effect
Service complete	A Maintenance Supervisor records a scheduled service complete in Argo, on return to service	On the vehicle: clears the unserviced icon and resets distance since last service to zero. On the rider: releases any swap block for this cycle.
Reset on deferral	The Head of Maintenance confirms a deferral on a distance occurrence in this console	The same reset on the vehicle and the rider. The come-in mileage is recorded on the occurrence in Rechaj, not on the VCU.

The commands and what they do are Telpo’s. They are built to Telpo’s documentation.
Neither command is fire-and-forget. Each is retried until the VCU acknowledges it. Until then the service or the deferral shows as pending release rather than closed, and a command that keeps failing is surfaced to the Head of Maintenance by vehicle, because a late or missing command leaves a compliant rider blocked from swapping through no fault of their own.
Nothing else is sent to the vehicle from this console. Sends and reassignments are the console’s own records.

The thresholds

4,500 km warn · 5,000 km due · 5,200 km service limit. The 4,500 and 5,000 km prompts are the VCU’s; the console reads them, derives Due and Overdue from them, and does not set them. The 5,200 km service limit and its consequence on the swap are Rechaj’s, and the console derives Past limit from it. Passing the limit does not lock the vehicle.

A vehicle that goes quiet

A vehicle with no recent reading is telemetry-dark, and it is not treated as compliant. Its occurrences hold the last state that was computed, the row says the reading is stale and how old it is, and the vehicle is counted in the Unknown slice of fleet-ready rather than in Healthy.
A dark vehicle is still scheduled. Its projected occurrences remain, because a keke nobody is hearing from is more likely to be overdue than less.

15.2 Swap gate feed

The Scheduler sends the swap gate each rider’s service status, so the gate knows about upcoming and breached schedules before the rider’s next swap.

Message	When it is sent	What it carries	What it means
Service due	The occurrence enters Due: on General preventive maintenance at 4,500 km since service, where the vehicle warns the rider; on a deferred occurrence, within the notice distance of its come-in mileage	The rider, the vehicle (plate), the schedule and service, and the distance since last service against the threshold (on a deferred occurrence, the odometer against the come-in mileage)	A service is coming up. The swap goes ahead.
Service breached	The occurrence passes the service limit, 5,200 km since service, or a deferred occurrence passes its come-in mileage	The same	The rider’s next swap is blocked.
Cleared	The service is recorded complete and the VCU has acknowledged the service-complete command, or the occurrence is deferred	The same	Any block is lifted and the due notice is dropped.

The feed is not fire-and-forget. Each message is retried until the swap gate acknowledges it, and one that keeps failing is surfaced to the Head of Maintenance by vehicle, because an unacknowledged Cleared leaves a rider who came in blocked at the swap, and an unacknowledged Service breached leaves a rider past the limit swapping.

16. Non-Functional Requirements

Performance budgets: Command Centre first-meaningful-paint under 2s; Dispatch Workbench pane-switch (queue row selection) under 300ms perceived latency (no full reload).
Staleness handling: Dispatch/Command Centre are real-time; Scheduler forecast cached 15 minutes with the stale tag past 2× interval.
Security & access control: all write actions server-enforced by role per Section 5, especially the taxonomy promote/merge/reject exclusivity.
Auditability: taxonomy governance actions are permanently append-only logged (Section 5.3); all other write actions logged with actor/timestamp/reason.
Accessibility: WCAG 2.1 AA; Fleet Status Wall markers use shape + colour (never colour-only) to encode VRI band; all charts have text-equivalent summaries.
Keyboard navigation: full ⌘K and Tab/Enter traversal, including 3-pane workbench pane-switching without a mouse.
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: rider-identifying data limited to what’s operationally necessary for dispatch (no rider financial/personal data beyond contact reference).
Export protection: every export logged with actor/timestamp/scope; “Confidential — Vehicle Operations” footer on all exports.
Error recovery: module-level failure isolation on the Command Centre; Dispatch Workbench panes fail independently (a broken Inspector doesn’t blank the Queue rail).

17. Complete UI-State Catalogue

State	General rule applied across this console
Initial loading	Skeleton shimmer on map, KPI tiles, and workbench panes.
Partial loading	Command Centre modules and Dispatch panes load independently.
Populated	Standard rendered state with “as of” timestamp where cached (Scheduler forecast only).
Selected	Selected WO row highlights and updates Panes 2/3 in place; selected calendar lane highlights its Occurrences.
Hover	Row/marker hover reveals actions or a summary card; chart hover shows crosshair + exact value.
Focus	Visible focus ring on every interactive element.
Disabled	Promote/Merge/Approve/Activate buttons disabled with explanatory tooltip until preconditions met.
Empty	Canonical empty state with specific message (e.g., “No vehicles currently assigned to this bay”).
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	403 with the specific rule violated (Section 5.4).
Stale data	Explicit stale tag on Scheduler forecast; not applicable to real-time Dispatch/Command Centre data.
Connection lost	Persistent banner; write actions (reassign/unblock/promote) queued/disabled until reconnection.
Optimistic update	Not used for Promote/Merge/Reject/Approve (server-confirmed only, given irreversibility); reassignment may optimistically update the queue rail pending server confirmation, reverting on failure.
Update conflict	Concurrent edits (two actors reassigning the same WO) surface a conflict dialog requiring explicit re-confirmation.
Destructive confirmation	Promote/Merge/Reject/Terminate-campaign show a lightweight confirm step stating the exact consequence.
Completed / success	Specific success state naming what changed (“WO reassigned to Bay 3”), never a generic toast.

18. Edge Cases & Failure Scenarios

A WO is reassigned to a bay just as that bay’s capacity conflict is detected: the Inspector’s capacity warning re-evaluates live at confirmation time, not just when the pane first loaded, so the Head of Maintenance sees the current conflict state, not a stale one.
Duplicate taxonomy proposals for the same underlying failure mode, raised independently at two different bays: the Proposed Modes queue surfaces a “possible duplicate” flag (matched on system/component/description similarity) so the Head of Maintenance can Merge the newer into the older rather than promoting two codes for one real failure mode.
A vehicle is withdrawn during an active Campaign’s rollout: per the Shared Operating Model §7/§9.2, it’s set to EXCLUDED — WITHDRAWN, removed from the active denominator, and remains visible in the Rollout Board’s exclusions list — bay capacity that would have serviced it is freed and reflected in the due-load forecast within one refresh cycle.
A parts shortage blocks multiple WOs across different bays simultaneously for the same part: the Inventory Constraints view (7.7) surfaces this as a cross-bay pattern, not N separate isolated requests, so the Head of Maintenance can approve one larger replenishment rather than approving redundant small ones.
Bay over-capacity discovered only after a campaign is already rolling out (e.g., an unrelated backlog spike): the Rollout Board shows the affected bay’s vehicles as at-risk of delay, cross-referencing the Bay Detail capacity conflict, so the Head of Maintenance can reschedule specific vehicles (Section 7.5 rescheduling) rather than the campaign silently falling behind.
A delayed VP approval on a routed Campaign: the Campaign remains in Proposed/Awaiting-VP-Decision status here, visibly aging (mirroring the VP Console’s Decisions Queue aging tags), and the Head of Maintenance can see exactly why it hasn’t started rolling out rather than it appearing simply stalled.
A taxonomy code is merged while WOs referencing the old code are still open: those open WOs show “superseded by {new code}” and their Tier-2 candidate list is updated to the new code, without altering any already-confirmed historical resolution on closed WOs (Shared Operating Model §8 rule 6).
Records reclassified after a taxonomy change mid-campaign: if a campaign’s target cohort is defined by a code that gets merged/promoted during rollout, the cohort’s linked-code reference updates to the current code and the rollout board’s scope re-evaluates against the updated definition, with a visible “scope re-evaluated due to taxonomy change” note.
Failed report export: the signed record is unaffected (frozen at Sign-off); export retries, with a raw-data fallback.
Unavailable downstream system (Atlas IMS unreachable, [VERIFY-2]): Replenishment Approvals shows the connection-lost state (Section 17); Dispatch, Scheduler, Campaigns, and Taxonomy Governance — none of which depend on live IMS data — remain fully usable.

19. Product Analytics

Events instrumented: page_view, wo_reassigned, wo_unblocked, wo_blocked_viewed, schedule_created, schedule_activated, schedule_paused, campaign_created, campaign_approved, campaign_terminated_early, taxonomy_promoted, taxonomy_merged, taxonomy_rejected, replenishment_approved, replenishment_rejected, report_published.
Key funnels: WO blocked → escalated → unblocked (time-to-unblock, by reason category); taxonomy proposal raised → endorsed → promoted/merged/rejected (governance funnel, time-to-decision).
Task success: % of Blocked WOs resolved within a defined SLA (e.g., 48 hours) by reason category.
Abandonment: Schedule/Campaign drafts started but never Activated/Submitted, by week.
Error rates: reassignment/unblock write failures per week (operational health signal).
Time to decision: median time from taxonomy proposal Endorsed to Promoted/Merged/Rejected.
Feature usage: Fleet Status Wall interaction rate, per-bay lens usage vs. cluster-wide default.
Adoption: weekly active use by the Head of Maintenance persona; report sign-off completion rate.

20. Acceptance Test Suite

20.1 Functional acceptance scenarios

HOM-FR-001 through 004 each produce the exact state transitions and downstream effects specified.
A full week’s dispatch, scheduling, campaign, and taxonomy governance workload can be run entirely from this console with no external spreadsheet.

20.2 Permissions tests

A Dispatch Maintenance Service Lead attempting Promote/Merge/Reject/Approve-schedule receives 403 with the exact messages 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

Fleet-Ready %, VRI distribution, cohort recurrence, and COPQ match the PM and VP Consoles exactly at the same timestamp.
A promoted taxonomy code is immediately available to the mobile capture flows’ Tier-2 candidate list (verified via the shared spine’s read contract).

20.5 Data-quality tests

A capacity forecast never shows a false-zero for a bay with unconfigured roster data.
Merged/promoted codes never silently rewrite historical resolved-WO data — only forward annotation is applied.

20.6 Notification tests

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

20.7 Export tests

Dispatch/Taxonomy CSV exports include every column in Section 11’s schema; signed reports byte-match their hashed content.

20.8 Failure-recovery tests

A failed reassignment write leaves the WO at its prior bay/assignee with a working retry, per HOM-FR-001’s failure clause.

20.9 Accessibility tests

Full keyboard traversal of Dispatch Workbench’s 3 panes and the Taxonomy Governance promote 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/write layer as the other three consoles.
HEAD_OF_MAINTENANCE and DISPATCH_SERVICE_LEAD roles exist or will exist in the platform’s identity system [VERIFY-7].

21.2 Dependencies (external, unresolved by any available source)

[VERIFY-2] Atlas Inventory Management System contracts — bay-level stock, parts catalog, decrement/transfer/bind APIs, fulfilment tracking for Replenishment Approvals (Section 7.7).
[VERIFY-1] Canonical vehicle identifier format — affects Dispatch Workbench and Fleet Status Wall vehicle references throughout.
Multi-bay technician/Maintenance Supervisor coverage policy (field-flow-fixes spec Q-24) — this console reflects whatever the roster states but does not resolve the underlying staffing policy.

21.3 Proposed Product Decisions made in this document

Due-load/capacity-conflict detection rule and default thresholds (Section 7.4) — Argo Shared Operating Model §4.4, reused here.
Campaign approval routing rule (Head of Maintenance only vs. Head of Maintenance+VP) — Argo Shared Operating Model §4.5, reused here.
Dispatch Maintenance Service Lead modelled as a standing, dispatch-scoped delegate rather than a time-boxed acting role (Section 5.1) — a reasoned product decision given the persona’s defined, permanent responsibilities (Argo Shared Operating Model §0 C14).
Taxonomy promote/merge/reject modelled as non-delegable even under an acting-Head-of-Maintenance delegation (Section 5.1), mirroring the VP Console’s non-delegable WBR sign-off pattern for consistency of governance-action treatment across Argo.

22. Glossary

Argo — The field maintenance, reliability, and fault-intelligence operating system for Rechaj’s electric tricycle fleet, run by Maintenance under Vehicle Operations.
Head of Maintenance — the Maintenance unit.
Maintenance Supervisor — Maintenance Supervisor.
Work Order (WO) — The operational unit tracking a vehicle’s fault from validated capture through parts, repair, and return-to-service (Argo Shared Operating Model §2.3).
Maintenance Schedule — A reusable, indefinite maintenance rule of one of two types: Condition or Ad hoc (Section 7.4).
Service limit: the distance since last service past which the rider’s next battery swap is blocked, 5,200 km on General preventive maintenance. Passing it does not lock the vehicle (Section 7.4).
Campaign — A bounded, approved fleet intervention with a start and end, distinct from a Schedule (Section 7.5).
Taxonomy Governance — The exclusive Head of Maintenance authority to promote, merge, or reject a proposed failure mode into/against the canonical taxonomy (Section 7.6).
Replenishment Request — A bay-level restocking request routed Maintenance Supervisor → Head of Maintenance (approval) → Cluster Inventory Manager (fulfilment) (Section 7.7).
Due-load forecast — The Scheduler’s forward-looking capacity model summing schedules, campaigns, and backlog against rostered technician-hours (Section 7.4).
Fleet Status Wall — This console’s signature live status map of every vehicle and bay by VRI band and capacity (Section 7.1).
VRI — Vehicle Risk Index — the 0–100 reliability score (Argo Shared Operating Model §5).

23. Targets set by the PM

FR-P1 — Visible on the dashboard. The Command Centre carries a read-only Targets card showing the bands the PM, Vehicle Operations set on their Health targets tab: fleet-ready, median time to resolve and immobilized units, each with the current value and the target.

FR-P2 — The gap is stated. A measure past its target reads the size of the gap — over by 5.4h, under by 3 pts — coloured amber inside the PM’s amber band and red past it. A difference between two percentages is expressed in points.

FR-P3 — One definition of on target. The card uses the PM’s own band edges. No second threshold is held in this console.

FR-P4 — Read-only. The Head of Maintenance sees the target and that the PM set it. Changing a band happens only in the PM’s console.

FR-P5 — Countable at a glance. The card head states how many measures are off target.

24. Where targets live

FR-P6 — Its own page. Targets sits under Overview in the sidebar, beside the Command Centre.

FR-P7 — The Command Centre keeps a one-line strip. It states whether anything is off target and names the measure furthest through its band, and opens the Targets page. It does not repeat the table.

FR-P8 — The page shows the bands. Each measure is drawn against its red/amber/green bands with a marker at the current value, and the band edges are stated in words.

FR-P9 — Changes are on the record. Every change the PM has made to a target is listed with what it was, what it became, who changed it and when.

FR-P10 — A row opens the measure. Clicking a target row opens that measure, its bands and its change history.

25. What a bay, an occurrence, a serial and a trend read as

A bay that is no longer running says so on its own record. A bay taken out of service keeps its page and its history and reads Deactivated beside its name, so a closed bay is never mistaken for one with nothing booked.

A scheduled occurrence reads Past limit, Overdue, Due, Projected, Sent to bay or Serviced, and a deferred one carries its come-in mileage and its reason rather than disappearing from the register.

A part swap checks the serial and says which it got. Capturing the serial of a fitted part reads Matched where it is the serial the work order expected, and Serial mismatch where it is not. A mismatch is stated, never corrected silently.

A trend states its direction in words. A measure reads Up N% on the period before, Down N% on the period before, or Level with the period before. No arrow glyph stands in for the sentence.

26. What a tricycle case holds

A case is read by somebody deciding what to do about a vehicle, so it carries the intake, the machine, the machine’s history and who it sits with. The case opened from the case list and the work order opened from a bay are two surfaces onto the same vehicle and state the same things about it.

FR-C1 — The case states where it came from. A bay walk-in, a scheduled service or a field escalation, separately from how far triage has got with it. The triage state is a different question and does not stand in for the origin.

FR-C2 — The case states whether the tricycle is at the bay, and how long it has been. Where nobody has answered that yet, the record says nobody has answered rather than leaving it blank or implying an answer.

FR-C3 — The case carries the complaint in the rider’s words beside the fault chosen at triage, the secondary fault observed, whether the fault repeats, the priority, who raised it, when, and when it last moved.

FR-C4 — The rider and the vehicle are identified down to the unit. Rider and phone, plate, chassis number, control unit, battery serial, kit revision, odometer at the last swap, cohort and bay.

FR-C5 — The vehicle’s earlier record is on the case. How many earlier records there are, how many are still open and which, the last repair and where, the fault that repeats, how many a bay flagged unsafe, how many were raised at top priority, and the bays involved. It counts the rows the vehicle history lists, from one population, so a count and the rows behind it cannot disagree.

FR-C6 — Where the vehicle last reported from is on the case, off its control unit, with when it reported.

FR-C7 — The case names who it sits with: the technician assigned, who triaged it and the department.

FR-C8 — Every vehicle on a case shows a fitted record. A vehicle nobody wrote a fixture for still reads as a real machine rather than a row of dashes.

27. The control unit a vehicle runs on

A control unit is fitted at the retrofit station and replaced at a bay, and telemetry follows its serial, so a vehicle naming a unit that is no longer on it sends every surface reading that unit to the wrong place.

FR-U1 — The assignment is one register. The retrofit station writes to it when a unit is fitted or swapped on the line; a bay writes to it when a unit is replaced in repair. A vehicle has one unit history, not two that disagree.

FR-U2 — The unit shown on a record is read off the register, never stored beside it, so the record and the register cannot drift apart.

FR-U3 — Fitting a part is not an assignment. Replacing a unit during a repair does not reassign the vehicle; the Head of Maintenance reassigns it deliberately.

FR-U4 — The unit offered is the one that work order fitted. Its serial was captured when the bay accepted it into its own inventory. A serial that cannot be typed cannot be invented, and a unit this repair never touched cannot be assigned. Where a work order fitted no unit, the action is not offered and the reason is stated.

FR-U5 — A reassignment takes a reason, and writes to the register and to the case audit trail, old serial to new.

FR-U6 — The unit that comes off is held for assessment, not returned as fittable: a bay pulling a unit has not judged it yet.

FR-U7 — Every unit the vehicle has run on is readable on the vehicle’s own history: the serial, when it went on, who fitted it, from which side, and when it came off, which is when the next one went on, with the reason it was changed. The current unit’s row says how many earlier ones there are.

28. What came off and what went on

Parts were fixed at the point the work order was raised. A technician who opened a keke and found the harness scorched could not add the part that actually went on, could not record the one that came off, and could not correct a line issued in error, so the record of a repair and the repair itself drifted apart from the first hour of the job.

FR-FP1 — Parts are added from the bay’s own inventory, not from a free-text field. A part the bay does not hold cannot be fitted, so the picker offers what is there and nothing else.

FR-FP2 — A quantity cannot exceed what the bay holds. The form refuses it at the point of entry rather than accepting the line and rejecting it later, because a request the store will have to turn down is a round trip nobody needed.

FR-FP3 — A serialised part takes a serial from stock. Fitting one means choosing the specific unit, from the serials the bay actually has free.

FR-FP4 — Replacing a serialised part returns the old one to stock. Changing the serial on a fitted line puts the unit that was on the keke back in the bay’s stock in the same movement, because a part is in exactly one place.

FR-FP5 — Removing a part returns it to stock and nowhere else. There is no destination to choose and no condition to set: the bay does not judge a part it takes off, and a quarantine decision belongs to whoever receives it.

FR-FP6 — The line carries no status. It mirrors the shipped WorkOrderPart, which holds the part, its serials and what happened to them, and nothing else. A status column here would be a second vocabulary for a thing the work order’s own stage already says.

FR-FP7 — The warehouse quantity shows beside the bay’s. A line reads what the bay holds and what the warehouse holds, and a warehouse holding none reads 0 rather than a dash, because nothing in stock is a number and not an absence.

29. Blocking a job by hand

A block was automatic and had exactly one cause: a part the bay could not supply raised one, and the part arriving cleared it. A supervisor waiting on a battery, on R&D or on Telematics had no way to say so, and the resolve-clock kept running on a job nobody could move.

FR-BK1 — A job can be blocked by hand, for a reason off a list. The list is Waiting for battery, Waiting for R&D, Waiting for Telematics, and it is the same list the Argo app offers, word for word. One block read in two places must not have two vocabularies.

FR-BK2 — Blocking is only offered on a job that is running. A job already blocked, done, or picked up is not waiting on a battery, so the control does not exist on it.

FR-BK3 — Escalating sends the case. Choosing a person mails them the record consolidated into one brief — the overview, the notes and timeline, the vehicle history, the evidence and the parts — with a subject that says it is a blocker. The desk the reason belongs to leads the list, because that is who it is almost always for. Escalating to nobody is allowed and sends no mail.

FR-BK4 — A block is stamped and the banner says since when. The same banner carries an automatic and a manual block; a reader should not have to know which kind it is to read it.

FR-BK5 — A manual block is cleared by hand, with a reason. Nothing arrives to clear waiting for R&D. The automatic parts block keeps clearing itself when the part lands.

FR-BK6 — The control is red, outline rather than solid, matching the state it puts the job into. The blocked badge is red everywhere else and the control that causes it cannot be amber.

30. A keke still inside its first three months

The same fault reads differently on a keke converted five weeks ago, but a case said nothing about how new the conversion was, so the question could only be answered by going to look.

FR-CA1 — A red Converted N days ago badge sits beside the status, on the tricycle case and on the tricycle work order both.

FR-CA2 — It stops at three months. Past that the conversion is no longer the first thing to suspect, and a badge on every case would say nothing at all.

FR-CA3 — A battery work order takes none. It carries a pack and a model rather than a plate, and a pack has no conversion date.

FR-CA4 — The conversion station counts the same window from the other end, as its 3-month breakdown rate. The two surfaces read one fact.