pm tricycle hardware prd

PM, Vehicle Operations — Console PRD

1. Cover & document control

• Product: Atlas · PM, Vehicle Operations console
• Unit: Vehicle Operations · MocX Smart Technologies Ltd (Rechaj)
• Owner: PM, Vehicle Operations
• Surface: Atlas web · 1440px desktop · read-only on operational records; the PM sets goals, runs investigations and sets health targets
• Status: Draft for build
• Flow: products/atlas/flows/pm-tricycle-hardware/index.html
• Related consoles: Head of Maintenance, Production Manager, Retrofit Station Manager, Inventory Manager, Procurement Manager (live at launch); PM Maintenance, Cluster Maintenance, VP Vehicle Operations (ship later)

2. Executive summary

The Product Manager for Vehicle Operations owns visibility across the entire unit — production, maintenance, retrofit and inventory — but has no single place to see it. Today the answer to “how is the unit doing, and where is the problem” is stitched together from each role’s own console.

The PM Console is one monitoring and analysis cockpit that rolls up every business unit so the PM can answer any question about any team, in any business unit, at a glance — and then act on what the analysis shows. Every business unit page reads in tabs named for what they hold — the unit’s work, the material it moves, and Analyse (how long things take, how often they happen, what is causing them, and whether it is getting better or worse). The PM can set delivery goals and every target the console measures against, open investigations into a pattern, push announcements when field feedback is acted on, and export any of it; it still never operates a work order. An assistant answers questions about the data in the PM’s own words. It is deliberately distinct from the VP, Vehicle Operations console (executive sign-off) and from the deep PM, Maintenance console (reliability engineering loop) — it sits between them as the PM’s day-to-day cross-business-unit cockpit.

3. Persona & operating context

Persona: Hadiza Mamudu, Product Manager, Vehicle Operations. Scope is all clusters and facilities, read-only.

Responsibilities

• Hold a live, cross-business-unit picture of the unit’s health.
• Spot where a business unit is slipping and drill to the driving metric.
• Triage the requests and product feedback coming up from the field.

Working cadence

• Daily: the Overview board and the attention watchlist; triage new tech feedback.
• Weekly: the business unit pages and cross-business-unit analytics.
• Monthly: read and export the operations report for leadership.

Primary jobs to be done

• “How is the whole unit doing right now?” → Overview north-star band.
• “Which business unit needs attention, and why?” → Business unit health board → status breakdown.
• “What does team X look like at a glance?” → Teams directory scorecard.
• “What is the field asking for?” → Requests.
• “What is broken in the apps?” → Tech feedback.
• “What is the story for leadership?” → the operations report.

What this role cannot do

• Cannot operate a work order, dispatch, validate a repair, or sign anything off — those are role-console and VP actions.
• Cannot open another role’s console from here (access is role-based).

4. Goals, non-goals & success criteria

Goals

• One surface that answers any cross-business-unit question in under a minute.
• Every metric is real, computable from a source that is live at launch, and consistent with the source console it comes from.
• Business unit health is computed and auditable, never hand-set.
• Analysis, not just levels: distributions with median / mean / P90, rates, cause rankings and backlog direction, all derived from live case-level records.
• The PM can act on a finding without leaving the console — set a goal, open an investigation, assign it, chase it, and read back what was found.

Success criteria

• The PM can brief leadership on any business unit without leaving the console.
• Every KPI reconciles with its source console at the same timestamp.
• Every business-unit-health rating can be explained from its metric breakdown.
• The PM, the delivery owner and the accountable head read the same goal figures.
• No investigation closes without a root cause and the action taken on the record.

Non-goals

• Not an operations tool (no work-order execution, dispatch, or sign-off). The actions the PM does have are investigation and goal-setting actions only.
• Not the VP executive console; not the PM Maintenance reliability console.
• Not a taxonomy, campaign, or engineering-loop surface.

5. Launch-data constraint (binding)

This console ships before the PM Maintenance and Cluster Maintenance consoles are reworked and go live. Therefore every metric must be computable from a source that is live at launch.

• Maintenance metrics come from the Head of Maintenance console only: Fleet-ready, open work orders, median time to resolve, repeat rate, immobilised (withdrawn), work-order aging, work-order fault-class counts, and — from the Head of Maintenance scheduler — preventive-maintenance compliance, schedule attainment, due-this-week, overdue and PM backlog. Work-order priority is Argo’s P1/P2/P3, and the Fleet Status Wall bands derive from each vehicle’s worst open case priority (Critical P1 / At-risk P2 / Watch P3 / Healthy = no open case / Unknown telemetry-dark). Anything visible on the Head of Maintenance design is treated as computed.
• Production, Retrofit, Inventory and Procurement metrics come from their own live consoles.
• Recurrence is used, and it is derived here. One definition governs every surface: a case is a repeat when the same unit had a case of the same fault class inside the 30 days before it. It is computed on this console from the case records (plate, fault class, opened date), which the Head of Maintenance already publishes per case, so it is never taken as a finished figure from another console and the two can never disagree. Repeat rate is the measure; first-time fix is its complement (100 minus the repeat rate) and is never computed separately. Below 10 cases in the window the console reads sample too small rather than a percentage. The Head of Maintenance derives the same measure from the same records for its own console.
• Not used anywhere (no data at launch): rider-days lost, MTBF, cohort intelligence, and engineering escalations routed to TH Engineering. This applies to the north-star band, business-unit-health drivers, analytics charts, notifications, the attention watchlist, the Requests queue, and the team scorecards.

6. Roles, permissions & authority

• Read-only on operational records. No create, edit, transition or sign-off on a work order, case, requisition or stock movement. Operational control stays in each role’s console.
• The PM does have authority over three things of their own, none of which touch an operational record:
  • Delivery goals — set, edit and void a business unit’s goals, and name the delivery owner.
  • Investigations — open one, assign it to a named owner, remind them, set the period after which an unresolved one alerts the PM, and export a findings pack.
  • Targets — choose which drivers feed a business unit’s health, set their green / amber / red bands, set every breach threshold and every step SLA.
• Tech feedback triage — a communication action, not an operational one.
• Role-based access. The PM cannot open another role’s console from here; business unit pages present a rollup, not a launch point. Assignment reaches the owner by notification.

7. Information architecture

Sidebar, grouped; every item is a page rendered by the router.

• Overview — General overview (the cockpit) · Rider overview
• Business units — Production · Maintenance · Retrofit · Inventory · Procurement
• Insight — Teams · Analytics · Requests · Tech feedback
• Reporting — Reports
• Shell — Notifications (bell), Settings (account menu), the assistant (docked, bottom right)
• Reached from their own section head, never the side nav — Announcements (from Tech feedback)

Inventory and Procurement are two units on the sidebar and two pages. Inventory answers what is on the shelf and what the catalogue holds; Procurement answers what is on order and what it cost to get here. They were one page with the orders behind a tab, which put a question about a vendor inside the answer to a question about stock.

• Inventory — Stock & catalogue · Categories & units · Locations · New items · Analyse. Categories & units sits straight after the catalogue because it is what the catalogue is built from: the registers an item is named from are the answer to “why can I not file this item”, and burying them behind Locations would put a question about the item between the reader and its answer. Its sidebar count is critical items.

• Procurement — Orders & requisitions · Analyse. It carries open requests, the urgent ones among them, orders in transit and requisitions in flight. It has no sidebar count.

• The health board still scores them as one. The Overview card reads Inventory & Procurement and covers both halves of supply, because Procurement has no driver pair, no band set and no card of its own: a fifth unit on that board would need all three, and none has been set.

Records open as pages of their own: production and retrofit work orders, maintenance cases, supply orders, kits and bundles, items, serials, batches, vehicles, requisitions and new-item requests.

Boots straight to Overview (no login gate) and honours ?scenario=<view> deep links.

8. Page inventory

Overview — a layered cockpit: a four-tile north-star KPI band (units closed MTD, fleet-ready, median time to resolve, riders live · first-pass yield and typical cover read on the pages that own them, Production and Inventory); the Business unit health board (one computed RAG tile per business unit with headline metrics, sparkline and drill-in); and a cross-business-unit attention watchlist.

Every business unit page reads in tabs, named for what they hold rather than numbered: Production — Work orders · Output · Analyse. Maintenance — Cases · Parts & spend · Analyse. Retrofit — Work orders · Vehicles & kits · Analyse. Inventory — Procurement · Stock & catalogue · New items · Analyse. The breach KPI row sits on the first tab of each unit, because it is the glance layer rather than a section.

Production — Work orders: active work orders, units closed today, on-time completion, first-pass yield, behind-schedule; the unit’s delivery goals; throughput trend (day / week / month); work-order status; and every work order, ordered worst first — behind and at-risk at the top — rather than a filtered subset. Output: the bundle log, what this unit built and the parts it consumed. Analyse: median / mean / P90 rework time with open-defect count, repeat rate and 8-week backlog change; a rates band (fixed on time, first-time fix, top-priority share, defects per 100 built); a rework-time distribution beside a most common defects ranking with each defect’s share; an open-defect backlog trend (raised vs cleared); the six units failing QA most often; and the investigations register.

Maintenance — Cases: metrics from Head of Maintenance (fleet-ready, open cases, repeat rate, immobilised, WO aging); vehicle health bands (Fleet Status Wall, derived from each vehicle’s worst open-case priority, shown as a shape + colour legend — Healthy / Watch / At-risk / Critical / Unknown); a Preventive maintenance card (PM compliance, schedule attainment, due this week, overdue, PM backlog); and a consolidated cases table with an Issue category column (Repair / Oil change / Field escalation / Battery / Unclassified), a category and priority (P1/P2/P3) filter, its own date filter and search, the rider beside every plate, and status With Maintenance Supervisor / With Maintenance Supervisor.

Analyse: a speed band (typical / average / slowest-10% time to resolve, open cases, repeat rate, 8-week case-backlog change); a rates band (fixed on time, first-time fix, critical share, cases per 100 of fleet); a time-to-resolve distribution beside a most common faults ranking carrying each fault’s share of all cases with the vital few in red; an open-backlog weekly trend reading arrival against resolution (falling behind / keeping up); the six vehicles with the most repeat cases, each row opening its case history and each flaggable for investigation; and the investigations register. The work tabs and Analyse do not repeat each other — the fault ranking, the resolve-time metric and the arrivals trend belong to Analyse only.

Retrofit — Work orders: the same KPI band, the unit’s delivery goals, conversions trend, rider pipeline, build quality and every work order worst-first. Vehicles & kits: the kit log and the vehicles with the kit fitted to each, its stage and its elapsed retrofit time. Analyse: mirrors Production on conversion reworks, with a most common conversion issues ranking and the vehicles reworked most often.

Inventory — Procurement: on-hand, critical items, open requests, orders in transit, days of cover, committed spend; requisitions in flight oldest-first; and where the time goes — the median days a requisition spends being approved and ordered, in transit, and being received. Stock & catalogue: the item catalogue with stock health carried in the row, and the batches stock arrived in. New items: requests for items not in the catalogue yet, and the approval levels those requests clear. Analyse: typical days of cover with below-reorder / out-of-stock / critical counts and the 8-week used-vs-received change; a rates band (well stocked, in stock now, ran out, chronic); a days-of-cover distribution beside consumption top movers; a stock-cover trend; the parts that stocked out most often; and the investigations register.

Teams — three tabs. Scorecards, a directory of every built role; a row opens a read-only scorecard of that team’s live metrics (no console launch — access is role-based). Members, the roster of every person in each business unit with the role they hold, the bay, facility, station or warehouse they are assigned to and who they report to on the org chart; a member can be added from the staff record, and a row opens that member’s record with the actions they took and the assignment they can be moved to. Activity, the trail of what members did: the action and the detail behind it. The Headline and Secondary columns are not set on this page: they are the business unit’s driver set from Analytics › Targets, valued from the same metric definitions and coloured by the band the PM set, so a team is judged on the metric the PM chose to judge that business unit on. Which driver leads and which is second is set on Analytics › Targets (FR-D1), and every team in a unit is scored on that same pair so the column compares down the table.

Analytics — a proactive-management view (not a repeat of the Overview trends): a drivers-vs-target table across every business unit (value vs target, RAG-scored, worst-first, with an off-target count and a business-unit filter). Open requests by business unit reads on the Requests page, where its bars set that page’s unit filter. Work orders by fault class reads on Maintenance and output-and-reliability by site on Production — a unit-specific chart lives on the unit it concerns. A segmented control switches to a Targets editor that reads one business unit at a time — that unit’s drivers and which of them leads, the bands for those drivers, its breach targets and its step SLAs together — with settings that belong to no single unit (the comparison window, the investigation alert period) on a General tab. Edits recompute the RAG live across the console, and every edit lands in the audit trail (section 32).

Requests — the operational request queue coming up from the field: parts replenishment and parts requests from Maintenance, with computed KPIs, priority + date filters and search.

Tech feedback — inbound bug reports and improvement requests, submitted through the Send feedback form in every persona console and typed at source (type · impact · area); actionable triage that emails the sender.

Reports — one operations report, every line computed from the records at render time (section 16).

Notifications — a cross-business-unit feed that clicks through to the relevant page; new tech feedback and threshold breaches raise notifications.

Settings — account, scope and data-source panel.

9. Metrics catalogue & sources

Every metric on the console and the live console it is computed from.

Metric	Definition	Source console
Units closed · MTD	Units finished, month-to-date · one work order builds or converts several, so this is never the work-order count	Production + Retrofit
Fleet-ready	% of active fleet able to complete a duty cycle	Head of Maintenance
First-pass yield	Units passing QA first time	Production / Retrofit
Repeat rate	Share of cases in the window whose unit had the same fault inside the 30 days before it	Case records · derived on this console
Median time to resolve	In-bay confirmed → Resolved · the clock starts when Is the tricycle in the bay? is set to yes (default no) · computed here from the case records, like repeat rate, so the tile and the Analyse card cannot disagree	Case records
Open work orders	New + in repair + blocked now	Head of Maintenance
Immobilised	Withdrawn · cannot self-propel	Head of Maintenance
WO aging · >7 days	Open WOs older than 7 days	Head of Maintenance
PM compliance	Preventive services done on schedule	Head of Maintenance (scheduler)
Schedule attainment	Scheduled occurrences met	Head of Maintenance (scheduler)
Due this week / Overdue / PM backlog	Preventive occurrences by due state	Head of Maintenance (scheduler)
Active work orders	Open build WOs on the floor	Production / Retrofit
Units closed today	Finished, QA-passed units	Production / Retrofit
On-time completion	WOs closed on time · 30d	Production / Retrofit
Behind schedule	Active WOs past pace	Production / Retrofit
Riders live	Riders on the road today, out of the kekes retrofitted to date	Retrofit Station Manager
On-hand	Warehouse stock on hand	Inventory Manager
Critical items	Items below critical / stocked out	Inventory Manager
Days of cover	Parts cover at current burn	Inventory Manager
Open requests	Requests awaiting an order	Procurement Manager
Orders in transit	POs in transit	Procurement Manager
Committed spend	Value on open POs	Procurement Manager

Derived on Analyse. These are computed on this console from the case-level records of the source console (opened date, resolved date, fault class, priority, plate, bay), not taken as a figure from elsewhere.

Metric	Definition	Derived from
Typical / average time to resolve	Median and mean of cases resolved in the window, each measured from in-bay confirmation to Resolved	Case records
Slowest 10%	The P90 of closed cases — 9 in 10 finish faster	Case records
Fixed on time	Share of closed cases inside the target	Case records
Rework time target	The window Production/Retrofit rework should close inside	Targets (PM-set)
Repeat rate	Share of cases whose unit had the same fault class inside the 30 days before it · sample too small below 10 cases in the window	Case records
First-time fix	100 minus the repeat rate · the complement, never a second computation	Repeat rate
Cases / defects / reworks per 100	Incidence against the population	Case records + fleet or output count
Backlog change	Opened minus resolved over 8 weeks	Case records
Most common faults / defects / issues	Each cause’s share of the total, vital few first	Case records
Rework time distribution	Closed cases by duration bucket	Case records
Days of cover distribution	Parts by cover bucket	Inventory Manager
Repeat stockouts	Parts that hit zero cover more than once	Inventory Manager

Goal metrics. Delivered, still to go, running rate a day, rate needed from here, finish at the current pace, and ahead/behind pace — all computed from the goal’s target, window and delivered count (see section 11). The card states the ones a reader acts on: delivered against target and how far off pace on the bar, then the rate needed from here and where this pace finishes. Two targets run side by side, so the rest reads on the target record rather than on the card.

Targets drive the thresholds. Every “inside target” measure reads the green band the PM set on Analytics › Targets, never a number hardcoded in the analysis: Fixed on time uses the Median time to resolve target, Production and Retrofit use a Rework time target, and Inventory’s Under cover target count uses the Days of cover target. The label states the threshold it used, and moving the band moves the figure. No measure is stated twice: a count lives in the status band and its rate in the Rates band, never both, and the open count comes from the case records so the work tabs and Analyse cannot disagree.

10. Business unit health model

Each business unit’s status is computed, never set. Each business unit scores its three driver metrics against a target; each metric returns a band (green on target / amber watch / red breach); the worst band wins and becomes the business unit status. Clicking a status badge opens the metric breakdown. The bands below are the defaults. In the Analytics · Health targets tab the PM (a) chooses which drivers feed each business unit’s health (add/remove, not a fixed three) and (b) sets each metric’s green / amber / red bands as explicit low–high ranges — one band set per metric (METRIC_DEF), scored by bandOf, worst band wins — and the whole console recomputes live.

Metric	Target (green)	Watch	Breach
On-time completion	≥ 85%	70–84%	< 70%
First-pass yield	≥ 90%	80–89%	< 80%
Behind schedule	≤ 3	4–6	> 6
Fleet-ready	≥ 95%	90–94%	< 90%
Median time to resolve	≤ 12h	12–24h	> 24h
Immobilised	0	1–5	> 5
Critical items	0	1–2	≥ 3
Days of cover	≥ 21d	10–20d	< 10d
Open requests	≤ 10	11–20	> 20

Drivers: Production / Retrofit = on-time · first-pass yield · behind schedule. Maintenance = fleet-ready · median time to resolve · immobilised. Inventory = critical items · days of cover · open requests.

11. Delivery goals

The PM sets what a business unit has to deliver, and every console working that unit tracks the same figures.

Model. A business unit holds a list of goals, so several run in parallel (Production can chase battery packs and controller units on different windows at once). A goal carries what is being delivered, the target quantity, a start and a deadline, and a named delivery owner.

States. Not started until its window opens — it is never scored as behind before it begins — then Active, then Met the moment delivered reaches the target, or Missed if the window closes short. The PM can also Void a goal (superseded, set in error, priority changed), which requires a reason.

What the card answers. Progress with a marker for where the unit should be by now, delivered against what is left, the rate it is running at, the rate needed from here to land it, and where the current pace finishes (and by how much it falls short). A met or missed card switches to the outcome: delivered against target, how far over or short, the average a day, and the window.

Archiving. Only live goals keep a dashboard card. Met, missed and voided goals move automatically into a Past goals table (ref, goal, target, delivered, result, window, headed by how many were met); a row opens the record, and a voided one shows why. Nothing needs closing by hand, and nothing delivered is deleted.

Actions & reach. New goal adds to the list and never overwrites a running one; Edit changes a running goal; Void ends one with a reason. Setting or editing notifies the delivery owner. A goal drifting off pace raises a Goal behind pace notification to the PM, and a met goal raises Goal met. The delivery owner’s console (Production Manager, Retrofit Station Manager) and the accountable head (Head of Production, Head of Retrofit) show the same list with the same states, read-only — setting and voiding stay with the PM.

12. Investigations

The action tier on the analysis: when the data shows a pattern, the PM turns it into accountable work without touching an operational record.

Raising one. From a recurring vehicle, unit, bay or part (Flag), or from scratch (Open investigation). It takes a subject, a severity, the scope of what is being investigated, and an owner chosen from the people who actually hold that business unit — Head of Maintenance, Production Manager, Retrofit Station Manager, Inventory Manager. Assigning notifies the owner and puts it in their own console’s queue.

Lifecycle. Open > In progress > Resolved. Every step is recorded in an activity log stamped with who did it, their role and when: who opened it, that the assignment was emailed, when the owner started, each finding the owner records, every reminder sent, and the closure.

Closing. Resolved requires both a root cause and the action taken; it cannot be closed without them. A resolved investigation shows both back as its conclusion.

Chasing. Remind nudges the owner and records the nudge. The PM sets the period a goal may run before it alerts them (3 to 30 days); anything unresolved past it is marked running over in the register and raised as an Investigation running over notification naming the owner and days elapsed.

Register. Ref, subject, owner, role, severity, how long it has been running, status and update count, with search, status, severity and raised-date filters, a clear, a live count, and a summary band (active, not started, in progress, running over). Export findings produces a findings pack; the owner can export from their own console too.

Boundary. Investigation actions only. No dispatch, no resolve-the-work-order, no sign-off — those stay in the Head of Maintenance and persona consoles.

13. Requests lifecycle

The Requests queue aggregates the operational requests coming up from the field. Three things that look alike are kept apart and never named interchangeably: a requisition is a purchase raised on Procurement (Polaris); a request to procurement is a unit asking Procurement to buy; a request to inventory is a persona asking the stores for stock they already hold. Types are those that exist at launch: Parts replenishment (stock top-ups from Production, Retrofit and Inventory to Procurement) and Parts requests (repair parts raised by the Head of Maintenance to Inventory). Status follows the request lifecycle: Requested → Ordered → Received. The four KPIs (open requests, parts replenishment, parts request, urgent) are computed from the queue and partition it. Requester identity is split into separate business unit, requester (name) and email columns, and the queue can be filtered by business unit as well as by priority.

14. Tech feedback lifecycle

Feedback is submitted through the Send feedback form carried by every persona console (Atlas, Forge, Polaris, Rider, Inventory, Kit Production) and arrives typed at source: Type (Bug / Improvement), Impact (Blocking / Slows me down / Minor) and the Area of the app it was raised from travel with the submission, alongside the sender’s name, role, email, source app, date and message. A new submission raises a notification and emails the PM on arrival (logged on the record).

The queue is filterable by type, impact, status and date range, with a search that matches name, email, role, area and note. Table columns are From · App · Type · Area · Impact · Received · Status; the detail leads with Type, Impact and Role before the note.

Triage is actionable and emails the sender with an attached note: Acknowledge & start (acknowledgement email; note optional) → In progress; Mark resolved (note required) → Resolved; Dismiss (confirmation with a required reason) → Dismissed; Reopen → New. Status updates live, the KPIs (New / In progress / Resolved / Dismissed) recount, and the sent reply is recorded on the item.

15. Filters & interactions

• Date range lives in each page’s own header actions (never the topbar) and scopes that page’s graphs and tables. Only pages with dated content carry it.
• Table filters — every table carries its own from/to date filter in the table head, independent of the page date range, plus the filters relevant to its rows (status, priority, issue category, severity, business unit), search, and a clear. The investigations register filters by status, severity and raised date.
• Status summary cards sit above the tables that matter: one card per state, carrying the state, a toned icon, the count and what the count is of, with the state in force selected. The card is the filter. Summary bands sit clear of the table beneath them.
• KPI drill-in — every KPI tile opens a detail with its trend and cross-links.
• Detail on interaction — centred dialogs for KPI detail, team scorecards, feedback triage and the assistant panel; no side drawers.

16. Reports

Reports renders one operations report, and every line in it is computed from the console’s own records at the moment the page renders, through the same definitions the unit pages use — so a figure on the report can never disagree with the page it came from.

Section	What it reports
Business unit health	Band, score and lead driver against its target, per unit. The head states the overall band, worst unit winning.
Breaches against targets	Every PM-set measure with its value, its target and a breached/within verdict. The head counts the breaches.
Speed · start to finish	Per unit: how many finished in the window, the typical time and the slowest 10%.
Spend on parts replacement	The parts drawn, priced, biggest first, with the window total against the budget and the rate note when money is not reading in naira.
Open queues	Every queue with its open count and the detail that decides it — behind, P1, past SLA, urgent.

The report carries no date picker of its own: its windowed figures obey the comparison window set on Analytics › Targets › General, and a control that filters nothing is not shipped. Export report downloads the whole report as one CSV. There are no section toggles, no static document list, and no sign-off — the PM reads and exports.

17. Design & canon

Built on the Atlas web canon (Polaris shell + Caesar tables/dialogs): sidebar + topbar + stacked pages, the .kpi band, .tbl tables, .pseg filters, centred .dlg confirmations and toast(). The palette is a restrained green (on target) / amber (watch) / red (breach) status system with neutral greys. Canon-lint 0, flow-diff 0 against the swept reference, every view runtime-probed.

18. Dependencies & out of scope

Dependencies — reads from the live source consoles for its data (Head of Maintenance, Production, Retrofit, Inventory, Procurement) and from the in-app feedback forms.

Out of scope — operating work orders; dispatch; return-to-service sign-off; taxonomy governance; campaigns and the engineering loop; and any metric that only exists on the not-yet-live PM Maintenance and Cluster Maintenance consoles.

Announcements

ID	Requirement
FR-AN1	When feedback has been worked on, the PM can push an announcement: an in-app notification, never an email, delivered to the notification bell of the audience chosen.
FR-AN2	Audience is explicit and carries its reach: everyone on the app the report came from, only the reporter, or every console and app — with the number of people each option reaches shown before pushing. An everyone-on-the-app audience includes the reporter, and the option says so.
FR-AN3	A resolved report offers Announce the fix with the title and message prefilled from the report; a blank announcement can also be composed from the Announcements section. Title and message are required.
FR-AN4	Every push is a durable record: id, title, message, the report it is about, audience, reach, who pushed it and when. Composing sits at the top of Tech feedback; previous announcements are their own page, reached from that head — never from the side nav.
FR-AN5	A report that has been announced says so (Announced · AN-43) and does not offer the action again.

Material layers and the rider lifecycle

ID	Requirement
FR-LC1	Items belong to Production; kits belong to Retrofit. Production builds bundles from individual items; a QA-passed bundle ships to Retrofit as an item; Retrofit assembles bundles and items into kits; only a kit is fitted to a vehicle.
FR-LC2	A bundle is serialised at assembly and a kit at its assembly; the serial scheme is the implementation’s to define. The Bundle log reads on Production, the Kit log on Retrofit.
FR-LC3	The rider lifecycle follows the canonical nine statuses (lead captured through retrofit completed). Retrofit’s scope starts at INSPECTION_PENDING; earlier statuses show on the rider record as context with who moves each.
FR-LC4	RETROFIT_QUEUED fires from the PCA marking onboarding complete and does not wait on INSPECTION_COMPLETED — stated on the rider record.
FR-LC5	The cases table reads status in operational words (Awaiting triage · With Maintenance Supervisor · With Maintenance Supervisor · Blocked · Resolved · Closed), the raised date with its weekday, and the running age in red; category, fault, priority and bay read on the record. An Unclassified case reads Awaiting triage.

Speed · cycle time

ID	Requirement
FR-CT1	Production and Retrofit each report start-to-finish cycle time beside their throughput: typical (median), average, slowest 10% and fastest, with the count of finished units it was measured on.
FR-CT2	Cycle time is computed from the unit’s own lifecycle stamps — a production unit’s start and QA-pass, a retrofit vehicle’s inspection-pending to retrofit-complete — never estimated from work-order progress.
FR-CT3	The figures obey the analysis window; a window with nothing finished states that rather than repeating the all-time number.

Parts cost and replacement spend

ID	Requirement
FR-CS1	Every catalogue item carries a unit cost. The catalogue lists it; the item record adds spend all round (units drawn × unit cost).
FR-CS2	Maintenance carries a parts replacement spend KPI: the total over the analysis window against a PM-settable budget, stating the overrun when breached.
FR-CS3	The spend trend reads week by week over the same window as every other figure — narrowing the window narrows the total and the trend together.
FR-CS4	The priced replacement table (part · units drawn · unit cost · spend, biggest spend first) sums to the same amount as the KPI; both are computed from the same draw events as the unpriced counts.
FR-CS5	The spend budget is set in Analytics › Targets beside the unit’s other targets.

7.z Targets, SLAs and breaches

ID	Requirement
FR-SL1	Every status transition a record can make carries an SLA in hours, per business unit. Stage tables show the verdict per leg; the legs sum exactly to the total.
FR-SL2	Each unit page opens on four breach KPIs. A breached card reads red, says Breached, and names the target it broke.
FR-SL3	Nothing may call itself breached against a number the PM cannot set. Every threshold and every step SLA is editable in Analytics › Targets, which reads one business unit at a time: the unit’s drivers and lead, the bands for those drivers, its breach targets and its step SLAs together, with general settings (the comparison window) on their own tab.
FR-SL4	Unit health is two numbers: the band is the worst driver (a breach never averages away); the score is each driver scored against its own target as a unitless ratio, then averaged with the lead driver weighted heaviest. The score is a snapshot only — never charted as a line, because a composite’s axis is unreadable. Trend is shown per driver, in that driver’s own units, over the analysis window, with direction meaning improving-against-target.
FR-SL5	One chart window: the date range when set, otherwise the last N weeks of the comparison-window setting. KPI trend dialogs cut to it and name the count they drew.
FR-SL6	Backend rule, no console control: when an approval level is vacant, a higher level may choose to sign in its place. Nothing on this surface configures or displays it.
FR-SL7	There is no separate traceability page: the spine’s tables live on the unit pages that own them, ids are links, and related tables read inside the record they belong to.
FR-SL8	Inventory lists the full item catalogue, new item requests with the decision case, requisitions oldest-first, and vendors quoted-vs-actual lead time.
FR-SL9	Maintenance partitions its cases by status in clickable summary cards that sum to the total, defaulting the table to open work.

7.y Records

ID	Requirement
FR-RC1	A work order, case or order opens a page, not a dialog. A dialog is for a decision (resolve, remind, reject), never for reading a record.
FR-RC2	A production work order shows the units under it — one row per unit with its serial, state, step, who holds it, started and closed — searchable, filterable by state and paged, with a units-by-state rollup.
FR-RC3	The unit count and closed count are derived from the work order’s own progress, so a record can never disagree with the list it was opened from.
FR-RC4	A retrofit work order creates units, exactly as a production work order does. Its record shows its conversion steps and the units built under it — one row per vehicle with its plate, rider, kit, stage and completion date — and each unit ties to its own rider. A rider is a fact about a unit, never about the work order, so the work-order table counts units rather than naming one plate.
FR-RC5	Records cross-link into traceability: every identifier on a record opens the record it names, and the serialised parts on a vehicle read on that vehicle. A work-order record lists the units under it and nothing else — the bundle and kit logs are the unit page’s tables, not a second copy inside the record.
FR-RC5a	Every work-order record states its expected completion, because that date is what behind is judged against; a status the record cannot account for is not shipped. A date already passed reads red.
FR-RC5b	The only action on a work-order record is open investigation. No control promises a lever the console does not have.
FR-RC5c	Production steps read Created → In progress → Completed.
FR-RC6	A maintenance case record carries what Argo records against the case, in five tabs. The case: id, work order, type, origin (bay walk-in · rider report · telemetry alert · roadside escalation · scheduled service), complaint separately from fault, secondary fault observed, repeat count on this vehicle, priority, status, stage, bay. Triage and timing: triage state, is the tricycle at the bay with who confirmed it and when, raised by with the role, raised, fault captured, last update, waiting. The vehicle: plate, rider, chassis number, VCU (model and serial), battery serial, kit revision, odometer, cohort, station, bay, kit fitted. Who is on it: technician, the supervisor the case is assigned to, department, bay, reminded, resolution note. Plus the parts replaced on that vehicle and vehicle history — every earlier case on the same plate, the current one excluded — where a row opens the case it names.
FR-RC7	Mark as resolved takes a required resolution note. Remind Maintenance Supervisor is offered only while the case sits on a Maintenance Supervisor gate. Both are recorded on the record.
FR-RC8	The case table opens on open work (Open, In repair, Blocked). Finished work is reachable by choosing it, never hidden silently.
FR-RC9	No Line column: a line is an attribute of the unit, reported on the unit’s own record.
FR-RC12	The case table is Open cases in eight columns: case id with the work order id beneath it, the plate with its rider beneath, the type on its own, the fault with the repeat count beside it and the complaint clipped beneath, priority and stage in one cell, bay, status, and the raise date with the age and who raised it beneath.
FR-RC13	Anything raised or opened names who did it. Every table that prints a raise, open, create or receive stamp prints the actor with it, either beneath the stamp or as its own column where the table is built on that split (requester and email on Requests, sender and email on Tech feedback).
FR-RC14	A stamp is a time, not a date at midnight: a record’s raise, capture and last-update stamps carry a time of day, and the capture and update stamps follow the raise.
FR-RC15	Every page and tab opens on its counts. A tab that goes straight into a table makes the reader count rows. Vehicles carry vehicles · retrofit complete · up for retrieval · kits reassigned; the catalogue carries items held · on-hand units · under the cover target · stocked out; new item requests carry requests · awaiting a line manager · approved · rejected; parts replacement carries parts replaced · units drawn · spend · biggest single part, computed from the same aggregation the table reads.
FR-RC16	A retrieval reads as a fact about the vehicle. A keke is sent for retrieval by the retrieval logistics team, marked arrived at the retrofit station, confirmed by the station and completed when the kit comes off. The vehicles table carries the stage with the retrieval id and the reason beneath it; the vehicle record carries every mark with the person who made it. Kit reassignment (a kit taken off one keke and refitted to another) reads on the record as the kit history and on the page as a count.
FR-RC24	One case population. The analysis history and the cases a reader can open are one set: the history is closed, the cases still running are the ones the table lists, and every open count reads the same function. A count of cases means the same number on every card that states it.
FR-RC25	The median time to resolve is computed from the case records, in whole hours, and the health driver, the north-star tile, the business unit card, the team scorecards and the Analyse card all read that computation. No surface carries its own figure for a measure another surface computes.
FR-RC26	Every KPI band is as wide as the cards it holds. A band that gains or loses a card does not leave an empty slot.
FR-RC27	The operation has a roster. Teams lists every member with the role they hold, every place they are assigned to, and who they report to. The head of a line is marked on their row. Joined dates and who added a person are staff-record facts held by the company system, not roster columns; the trail carries the addition. Reports to follows the org chart, which is a line of roles, resolved against a place the two share: a technician reports to the supervisor covering their bay, a supervisor to the cluster manager, a manager to the head of that line.
FR-RC28	A member is added from the staff record, not typed in. The pool is staff who hold no seat on this console; searching it matches name, role, staff id or place, and picking a person populates their role and the places they work. Role is chosen from the roles the operation runs, and a member can be assigned to more than one place — a cluster manager covering two bays, a store keeper covering two warehouses — with the reporting line shown before the choice is saved. The person leaves the pool on being added. This is the flow the Retrofit Station Manager and the Production Manager use to add a team member, and the one the Head of Maintenance uses to add staff to a bay.
FR-RC43	A record says where the vehicle was last seen. The case record and the rider and vehicle record carry the last known position: the place, how it got there, when it was reported and how long ago, with the plate, rider and the source, which is RadR. It is a stated place, not a map.
FR-RC42	One set of parts, and one cover target. The stock analysis measures the catalogue: cover, consumption and repeat stockouts all come from the item records, and every row on those cards opens the item it names. Days of cover is set once, as a target, and the health metric’s bands, the analysis and the below-cover count all read it, so an item cannot be thin on one page and covered on the next.
FR-RC38	The console writes its own trail. Every action that changes a record writes one line through one function: cases resolved and reminders sent, targets set and voided, measurement rules moved, investigations opened and resolved, new items approved and rejected, announcements pushed, feedback answered, approval levels changed, members added and moved, items edited, and every export. An entry may name a subject, and a record reads its own history from that trail rather than keeping a second log.
FR-RC39	One list of places, named as Inventory Manager names them. The inventory locations follow Procurement & Inventory §4: every location has its own warehouse, there is no central warehouse, and a facility is the site that raises requests and receives stock, so a warehouse and a facility may share a site name without being one thing. A person is assigned to those places plus the cluster a field technician covers. There is no all-sites pseudo-place: someone covering everything is assigned to each place they cover. Item units are the canonical five and no others.
FR-RC40	Stock health is stated once. The alert is the item’s thresholds — stocked out, critical, low, in stock — on the badge, in the page counts and in the catalogue sub-line. Days of cover is a separate question and reads in its own column and on Analytics.
FR-RC41	The console fits the screen it is on. No page scrolls sideways as a whole at any width; a table scrolls inside its own card. The sidebar collapses to icons on a narrow screen, the KPI and summary bands fold, and the top bar drops what the page already states.
FR-RC29	What a member did is a record. Every action a member takes on the operation reads on the Teams trail as when, who with their role, the action and the detail behind it, newest first, filterable by date and searchable. The action and the record it names carry where it happened, so the trail states it once. Adding a member or changing an assignment lands there the way a bay roster change lands in that bay’s audit.
FR-RC35	A request names the location it is wanted at, not the business unit that raised it: the warehouse, facility, station or bay Procurement is delivering to. The queue carries it as a column, as its filter and as the split that says where the queue sits, with the filter offering only the locations the rows carry. The new item request already carries where the item will be held, so it states the location once.
FR-RC36	An item is editable from its record. The picture, name, description, category, unit of measure and the item’s reorder thresholds — low and critical — can be corrected; the figures the operation computes for it are not editable here. The name is composed from describe, type and key specs, reads back before it is saved, and cannot be saved as a name the catalogue already holds. A rename carries to every record that names the item, so holdings, serialised units, batches and kit types stay joined to it, and the edit is recorded in the trail.
FR-RC37	An item carries the two reorder thresholds the Inventory Manager sets (Procurement & Inventory FR-U1, FR-U4): a low threshold that raises a low-stock alert and a critical threshold that raises a critical one, per item, suggested from usage and editable on the item record. Low is the consumption expected over that item’s lead time, so an order placed at it lands before the shelf empties; critical sits below it. The catalogue status reads them — stocked out, critical, low, in stock — while days of cover keeps its own reading against the console-wide cover target, and the Critical items headline counts what is stocked out or at its critical level.
FR-RC34	Inventory reads by location as well as by item. Every inventory location lists who holds it, the units on its shelf, its serialised units on hand and its last movement, searchable; a row opens the location with everything on its shelf and every serialised unit traced to it. Both readings compute from the same holdings, so a location and an item cannot disagree. The word for the place is inventory location, and each is named for what it is on the ground: the warehouse, the facility, the retrofit station, the assembly bench, the bays.
FR-RC33	An assignment can be changed from the roster. The places a member covers are editable on their record as a multiple choice over every place the operation runs, and the reporting line resolves against the new places and is shown before the change is saved. A member must hold at least one place, and the change lands in the trail.
FR-RC30	A record reads as a list of facts, not as a table. Every detail page — case, work order, item, kit, batch, rider, request, order — is built from one record card: an uppercase section label, then one row per fact with a leading icon chosen from what the label is about, the label in secondary text and the value set right with any qualifier inline after it. One shape, so every record page changes together.
FR-RC31	A business unit card scores on a ring, and the ring names its parts. The drivers name what the unit is measured on, each with its band dot, own-unit trend and its share of the score; the ring beside them carries the unit’s score as one segment per driver, each as long as that driver contributes and coloured by that driver’s own band. A contribution is the driver’s weighted attainment, the shares sum to the score, and the printed shares sum to the printed score. A driver beating its target does not carry one below its own: attainment caps at the target, so 100% means every driver is at or above target and no surface reads above 100%. Driver values and their targets read on the health dialog behind the band badge.
FR-RC32	Riders live is a part of the retrofitted fleet, not a figure beside it. The card states the riders on the road today out of the kekes retrofitted since the programme started; the gap between them is what is off the road, immobilised or up for retrieval, computed from the records that hold those states. A live count can never exceed the retrofitted count, and every surface that states riders live reads the one computation.
FR-RC21	Every filter filters, and offers only what the rows can hold. A filter repaints the page that mounts its table. Option lists for open-ended dimensions (categories, bays, request types) are read from the data, so a value the rows carry can never be missing from the filter and a value they cannot carry is never offered. A control that sets a value rather than narrowing rows is a form control, not a filter.
FR-RC22	Every table filters on the dimensions its own columns carry: work orders on status, cases on status, category, priority and bay, the kit and bundle logs on state, the catalogue on category and cover status, vehicles on stage and retrieval, requisitions and new item requests on state, requests on location and priority, feedback on type and app, drivers on business unit and band, teams on status.
FR-RC23	Every state the console counts has a subject in the seeds: a blocked case, a team at risk, a stocked-out item, kits assembled and awaiting a vehicle, units awaiting QA, and more than one investigation per business unit. A state with a card, a badge or a filter option and no row behind it reads as a broken filter.
FR-RC18	Every date reads day, date and time — “Sat 20 Jun 2026, 14:12”. A period keeps the day alone (a target window, a By day bucket, a chart axis) because a period is not a moment, and a date input stays a date. A target window names its year.
FR-RC19	Dialogs are 620px wide so a record with a note and an audit trail does not scroll inside itself.
FR-RC20	The catalogue table carries no SKU: the item name carries its tracking and unit, the second column is the category, and the status carries the date of the last count. The SKU is identity on the item record.
FR-RC17	An on-hand figure carries the counts behind it. An item record lists every stock count: what the record said, what was on the shelf, the variance, who counted it and why, newest first.
FR-RC11	The case record carries Is the tricycle in the bay? — yes or no, defaulting to no, stamped when set. The resolve clock starts there: time to resolve runs from yes to Resolved, a case whose vehicle never arrived contributes no sample, and ageing (time since raised) stays a separate figure so the wait for a vehicle is visible rather than counted as repair time.
FR-RC10	A column earns its place on the table it sits on. Severity is not a property of a work order and does not appear on one; kit type is not a property of a retrofit vehicle; the kit a part came from is already one row above on a case record. Where a column is the record’s own identity it is not repeated as a second column.

7.x Traceability

Purpose: answer item-level questions the rest of the console cannot — what is in a kit, where a part came from, who holds what, and how long a vehicle took from inspection pending to retrofit complete. The data is the persona consoles’ own records consolidated in one place, not a second copy of them.

ID	Requirement
FR-TR1	One linked record set: a batch receives serialised items into a store; a kit claims items out of stores; a kit is assembled against a work order and fitted to a vehicle; the vehicle carries a timestamp per lifecycle stage. Every identifier in one table resolves in the others.
FR-TR2	Kit log (Retrofit) and bundle log (Production) — each entry with how many of its lines are filled, its work order, assembler, QA sign-off, state and, for a kit, what it was fitted to. A bundle is described by the part it creates, not by a type: a bundle of items still produces an item, and the bundle’s name is that item. A finished bundle’s state is completed; where it went next is Retrofit’s record to tell.
FR-TR3	Serialised units read on the item they are — the catalogue row opens the item record, and that record lists every serial of it with its batch, store, kit, state and collection date, each opening the serial’s own record. An item record shows every hop in order, from delivery note to the rider it ended up with. There is no standalone table of every serial in the business: a serial is a fact about an item.
FR-TR4	Batches — vendor, delivery note, store received into, quantity, and how much of it has been consumed. A batch record lists every item from it and where each one ended up.
FR-TR5	Riders & vehicles — the kit fitted to each vehicle, its stage, and its elapsed time. A rider record carries the stage timeline, the elapsed time per leg, and the serialised parts on that vehicle.
FR-TR6	Lifecycle — inspection pending to retrofit complete per vehicle, broken into legs (to inspected, to queued, to started, to QA, in rework) with the total, slowest first. The legs must sum to the total.
FR-TR7	The stage sequence is Inspection pending, Inspection completed, Retrofit queued, In progress, Awaiting QA, Rework, Retrofit complete — the sequence the Retrofit Station Manager console uses. The clock starts at inspection pending.
FR-TR8	Who is holding it reads on the item record — holder, role, store, quantity and last movement — alongside the vehicles carrying that part, with the plate, rider, serial and who fitted it. Holdings are not a separate table beside the catalogue; they answer a question about an item, so they live on the item.
FR-TR9	A kit holds at most one item per line, claimed from stock received before it was assembled, so its line count is a ceiling and unfilled lines are reportable.
FR-TR10	Every table pages and states its total; every row opens the record it names.

19. The analysis window

FR-W1 — One window. Every distribution, rate, cause ranking and backlog figure in an Analyse view is computed over a single window, clamped to the span of the available records. No band states a period of its own.

FR-W1a — The window length is a setting, and precedence is stated. The PM sets how many weeks an Analyse view compares over, in Analytics › Targets; with no date range set, the views measure that many trailing weeks. A From/To range in the page head overrides it, because naming two dates is the more explicit statement, and the setting says which of the two is in force.

FR-D1 — The lead and second driver are named, not inferred. Each business unit names a lead driver and a second driver from its own driver set. The second is chosen from that set minus the lead, so it can never be an unrelated metric and never the lead twice. Every team in the unit is scored on that pair. Changing the lead to the current second moves the second on; removing a driver holding either role reassigns it.

FR-W2 — The window is named, and the name reconciles. The Analyse view states the window it measured beside the Monitor/Analyse toggle, as real dates and a count of weeks. The dates are the first and last day of the window — not the first and last weekly bucket — so the span and the week count agree arithmetically. A figure never carries a bare period it cannot account for, and never one whose own dates contradict it.

FR-W3 — Present tense is marked. A count that is only true right now (open cases, open defects) says so when the window is the full span, and says it is counting what opened inside the window when the range has been narrowed.

20. Targets reach the people measured by them

FR-T0 — Which consoles are measured how. A console is measured by targets or by goals, never both. Inventory and Maintenance run continuously against a service level and carry targets. Production and Retrofit run finite delivery pushes and carry goals with their finished-goal history (section 21). The PM sets every band and still measures all four units against them in their own Analyse views; this governs only what is pushed out to the persona.

FR-T1 — Visible. The Inventory Manager and Head of Maintenance consoles carry a read-only Targets card showing the bands the PM set on Analytics › Targets, that console’s current value for each, and the gap where it is off target.

FR-T2 — One definition. The card uses the PM’s own green and amber edges. Amber inside the amber band, red past it. There is no second threshold held anywhere else.

FR-T3 — The gap is stated, not implied. An off-target row reads over by 5.4h or under by 3 pts. A difference between two percentages is expressed in points.

FR-T4 — Countable at a glance. The card head states how many measures are off target, so a miss does not depend on reading every row.

FR-T5 — Read-only at the persona. Only the PM changes a band. A persona sees the threshold and who set it, never an edit control.

FR-T6 — Production and Retrofit measure pace. Their Analyse views state Delivering to pace: delivered against where the live goals should stand by now, rolled up across every live goal in the unit. On pace at 100%, watch from 90, behind below. The sub-line states how many goals are behind pace. With no goal running there is no pace, and the measure is absent rather than shown empty.

FR-T7 — No unmeasured target. A target exists only where something is held to it. Rework time was removed when pace replaced it. Maintenance and Inventory keep their targets because they run to a service level, not to a finish line.

FR-T8 — Slow-work evidence needs no target. Where a unit is paced rather than targeted, the evidence behind a slow-work flag is that unit’s slowest 10%, stated as such.

21. Finished goals on the persona side

FR-T9 — A finished goal leaves the live list. Met, missed and voided goals move to a Finished goals table in the persona’s console, exactly as they do in the PM’s.

FR-T10 — The result is stated. Each finished goal shows how it ended: delivered against target, the overshoot or shortfall, or that it was voided.

FR-T11 — A void carries its reason. The reason the PM gave when voiding travels to every console showing that goal. A goal never disappears without one.

22. Where targets and goals live

FR-T12 — Each gets its own page. Targets sits under Overview in the Inventory Manager and Head of Maintenance consoles; Goals sits under Overview in the Production and Retrofit consoles. Both are reachable from the sidebar, not only from the dashboard.

FR-T13 — The dashboard keeps the signal, not the table. The dashboard carries a one-line strip stating whether anything is off target or behind pace and naming the worst one. The strip is the click target for the page. It never repeats what the page holds.

FR-T14 — Worst is comparable. Where measures are in different units, “worst” is the one furthest through its own band, not the largest raw gap. A 5.4h gap and a 3-point gap are not otherwise rankable.

FR-T15 — The page shows the bands, not just the verdict. Each measure is drawn against its red/amber/green bands with a marker where the current value sits, and the band edges are stated.

FR-T16 — Changes to a target are on the record. The Targets page lists every change the PM has made: the measure, what it was, what it became, who changed it and when.

FR-T17 — Every row opens something. A target row opens that measure and its change history. A finished-goal row opens that goal and, where it was voided, the reason.

23. Naming

FR-T18 — One word for it. Every persona console names the thing it is held to Targets, whether that is a standing service level (Inventory, Maintenance) or a delivery push measured against pace (Production, Retrofit). The nav item, the page title, the dashboard strip and the page copy all use it. A finished one goes to Finished targets.

24. Days of cover

FR-C1 — Cover is a per-item rule. The PM sets one number — the days of cover every item should hold. It defines what counts as below cover and is never scored against a single warehouse-wide figure, because there is no such figure.

FR-C2 — What is scored is the count of breaches. The measure held against a band is Parts below cover: the number of items under the per-item rule, counted from the item records. Moving the rule moves the count.

FR-C3 — A median may describe, never score. A typical-cover figure may appear as description, labelled as a median with its spread named. It is never compared to a target, because a median of a per-item measure hides the items about to run out.

FR-C4 — The rule is stated wherever the count is shown. A persona seeing “parts below cover” is told which rule produced it.

25. Naming in the PM console

FR-C5 — One word. The PM console says target for the thing it sets, matching what every persona console shows: New target, Targets, Past targets, Finished targets, and the add, edit, save and void dialogs. Voiding still requires a reason, and that reason travels to every console showing the target.

26. What a target delivers

FR-D1 — Chosen from the unit’s own work. The deliverable is picked from a fixed list per business unit, never typed. Production: units built, work orders closed, bundles assembled. Retrofit: conversions, harness upgrades, retrofit orders closed.

FR-D2 — Every deliverable names its source. Each entry states the record set its count comes from, so a target cannot be set against something no console measures.

FR-D3 — Scope is chosen too. A target carries the model or cohort it applies to, from the models that unit builds or the cohorts it works on, or the whole unit.

FR-D4 — The label is composed. The target’s description is built from the deliverable and the scope, so two targets for the same work read the same way.

FR-D5 — The source reaches the person delivering it. The persona’s own card states which records move the number, and the finished-target detail repeats it.

27. Target progress is counted

FR-D6 — Delivered is derived. A target’s delivered figure is the sum of the output-log records matching its deliverable, its model and its window up to today. It is never typed.

FR-D7 — Elapsed is derived. Days elapsed come from the window and today, so a target’s pace and its progress cannot disagree.

FR-D8 — The filters have to bite. Narrowing the window, changing the model, or choosing the whole unit each change the figure, because each is applied to the records rather than to a stored total.

28. Work orders, ordered by what needs attention

FR-O1 — Nothing is hidden by default. A unit’s work-order table lists every work order, ordered worst first — behind, then at risk, then on track — rather than filtering to the exceptions. A reader who wants only the exceptions filters; a reader who wants the book has it.

FR-O2 — A unit-specific chart lives on the unit it concerns, and only where it earns the space. Output-and-reliability by site is not carried on Production.

29. The item record is where an item’s facts live

FR-I1 — One record, every question about that item. The catalogue row opens the item: its identity and cost, who is holding it and where, the vehicles carrying it, every serialised unit of it, the requisitions raised for it, and the batches it arrived in.

FR-I2 — The catalogue table carries what plans stock, not what describes it. Item, SKU, unit cost, on hand, cover against the cover rule, lead time and status. Lead time is the vendor’s quoted delivery days for that item, read against the lead-time target. The vendor’s name is on the record; vendor performance is the vendors table’s job.

FR-I3 — A replacement part opens what it was fitted to. Opening a drawn part from a spend or replacement table reaches the same item record, so the vehicles carrying that part are one hop from the money spent on it.

30. New items and the levels they clear

FR-N1 — New item requests are their own tab on Inventory, holding the request queue and the approval levels that govern it, because the queue and its policy are read together.

FR-N2 — Approval depth is what the PM sets, never the approver. The chain is derived from the reporting line; the PM sets how far up a request must go. The table reads business unit, the depth, and the chain that depth produces in signing order.

FR-N3 — No named raiser. Anyone in a unit’s raising role can raise a request, so the table carries no Raised-by column; naming one person would be a fiction.

31. Money, currency and spend

FR-M1 — Stored in naira, displayed in the currency the PM picks. One formatter feeds every figure, so a currency change moves all of them or none.

FR-M2 — Converted money names its rate. When the display currency is not naira, the rate used and the day it was taken read beside the figures.

FR-M3 — The counts and the money come from the same events. A priced table and its unpriced counterpart are computed from the same draw events, so they cannot disagree.

32. The audit trail

FR-A1 — A measurement rule that moves is a record. Every change to a target, a band, a step SLA, a unit’s driver set, its lead or second driver, the comparison window or the display currency is recorded: when, who, what moved, and from what to what.

FR-A2 — Why it is not optional. A threshold that moves silently rewrites what breached meant on every report produced before it. The trail is what makes an earlier report readable.

FR-A3 — It reads where the rules are edited. The trail sits at the foot of every Targets view. It is not repeated on the operations report, which reports the state of the operation rather than the history of its rules.

FR-A4 — Who is the session. Attribution is the authenticated identity; the console holds no separate user model.

FR-A5 — Two trails, one shape. The rules trail records what moved on a measurement rule. The Teams trail records what the people did on the operation — action, module, detail — and both read as when, who, what, from the same stamp format. A rule change made by the PM appears on both, because it is a change to a rule and a thing a person did.

33. Exports

FR-E1 — Export means a file. Every Export control downloads that page’s primary dataset as a CSV — Maintenance cases, requests, tech feedback, team scorecards, drivers against target, investigations findings, and the whole operations report.

FR-E2 — A cell exports its words. Markup is stripped and values are quoted to the CSV standard, so a status badge exports as its status and a comma inside a value does not split a column.

FR-E3 — What downloads is what is on screen. An export reflects the filters and the window in force, and states the row count.

34. Empty and error states

FR-Z1 — An empty table says why it is empty. A table with no rows states whether nothing matches the filters in force or nothing exists yet, and where the filters are the cause the reader can clear them from where they are standing.

FR-Z2 — An empty window is not a zero. Where nothing finished inside the analysis window, a derived figure says so rather than showing the all-time number or a zero that reads as a result.

FR-Z3 — A failed action keeps the reader’s work. An action that cannot complete says what failed and leaves the entered values in place; nothing is silently discarded.

FR-Z4 — A missing record is named. Following an identifier that no longer resolves states which identifier failed rather than opening an empty record.

35. Access

FR-P1 — Permissions are Polaris’s. Only a PM, Vehicle Operations reaches this console; the console holds no role model of its own and shows no permission controls. Every action recorded here is attributed to that authenticated session.

36. Every figure is derived

FR-F1 — A number on this console is computed from a record. Counts, distributions, rates, trends, cycle times and money are derived at read time from the records that produce them.

FR-F2 — A trend exists only where a real series exists. Where the records carry no history for a measure, no line and no direction chip is drawn for it. A chart’s total reconciles with the count of records behind it, including the current partial period.

FR-F3 — A composite is never charted. A unit’s score is a snapshot; direction is shown per driver in that driver’s own units.

FR-F4 — Copy states the thing, not the mechanism. Labels and sub-lines carry the measure, its count or its threshold. Explanations of where a figure came from, how it was assembled, or what a surface is for are not UI copy.

37. The Assistant

An in-console assistant, docked bottom-right, that the PM can ask about the operation in their own words.

FR-AS1 — It reasons over the console’s data. The assistant answers by working over the same records the pages render from: ad-hoc analysis, pattern and anomaly recognition, correlation across business units, comparison over any window the records support, follow-up questions that build on what was just asked, and an account of why a figure moved. Its scope is the analysis a reader could do with the data in front of them, not a fixed list of supported questions.

FR-AS2 — It also locates. Any identifier or name resolves to the thing it belongs to — a serial, plate, kit, bundle, batch, catalogue item, requisition, new-item request, work order, case or vendor — with where it is, what state it is in, and who holds it.

FR-AS3 — Every answer carries its way in. An answer names the record or page behind it and offers it as a click, and the surface it offers is the one that owns the question: a maintenance pattern opens the case that carries the vehicle’s history, not the retrofit record for the same plate.

FR-AS4 — It cannot invent. Answers are grounded in the records reached through defined data access. Where the data does not support an answer, the assistant says so and names what it would need. It states no figure the console cannot show.

FR-AS5 — It reads, it does not act. The assistant opens records and explains them. It does not set a target, raise an investigation, push an announcement or move an operational record; those stay with the controls that own them.

FR-AS6 — The session is not history. Nothing is stored between sessions. Closing the panel or a period of inactivity ends the session and clears its transcript, and reopening starts empty.

FR-AS7 — The transcript leaves only when asked. Copy puts the conversation on the clipboard and Export downloads it as a text file. Those are the only two ways it leaves the panel.

FR-AS8 — Data access is a defined surface, not the whole database. The assistant reads through named data access — locating a record, reading breaches against targets, spend, cycle times, queue depths, case and vendor sets — each subject to the reader’s own permissions. That surface bounds what it can read; it does not bound what it can be asked.

FR-AS9 — Answers stream, and the wait is visible. A long answer renders as it is produced rather than after it completes.

The conversion a register can read, and what the quality figures leave out

ID	Requirement
FR-H1	The conversion rungs are the station’s own, taken whole rather than restated: Waiting to start, Conversion in progress, On hold, Rework, Final checks, Ready for pickup, Collected. Two consoles describing the same journey in different words cannot be read against each other.
FR-H2	On hold is amber beside Conversion in progress, with its reason. It is the same place in the journey, with the work stopped on somebody outside the station.
FR-H3	A unit whose chassis file has been corrected reads Conversion in progress with a Re-check chassis label, because the work has resumed.
FR-H4	Neither hold counts toward the rework rate or the first-pass yield. A keke held because the wrong tricycle arrived, and a keke sent back because its own frame is cracked, are not the station building badly.
FR-H5	Both figures state what they exclude, on the figure. A qualified number carrying no visible qualification is read as unqualified.
FR-H6	A rider sent back from retrofit sits at Inspection pending, with the defect that sent them back on their record.