PRD

RECHAJ — MocX Smart Technologies Inc.

Facilities — Facilities Product Manager (Super Admin) Module

Product Requirements Document — Engineering


Status	v1.0 — draft, PRD-first. Specified ahead of the prototype from the Facilities PM intake; supersedes the generic multi-persona intake draft.
Date	July 2026
Prepared by	Product Team (Facilities), from PM intake
Owners	Facilities Product Manager (TBD) · Office of the CPO
Scope	Atlas (web) — Facilities Product Manager (Super Admin) persona only. Facility Manager, Station Manager, Location Acquisition Manager and Department Requester are referenced here and specified in companion PRDs (see §12).
Source of truth	This PRD. No interactive prototype exists yet; the Atlas Facilities PM flow will be built to match this document. Until the prototype ships, this PRD is authoritative and this doc + the prototype win over the generic intake draft where they diverge.
Classification	CONFIDENTIAL

1. Executive Summary

Rechaj runs a growing estate of physical sites — Retrofit Stations, Battery Assembly Units (BAU), Charge-Swap stations, Offices, Experience Centres and tricycle workshops — and today their oversight is fragmented: roles and responsibilities are unclear, issues are reported informally and rarely escalated, reports are undocumented, and there is no enforceable design standard or SOP repository.

The Facilities Product Manager (PM) is the Super Admin of the Facilities module on Atlas and the single accountable owner of the estate. This module gives the PM one operations surface to monitor every facility, run every facility issue and request through a controlled lifecycle, track equipment condition and provisioning, keep the contractor directory current (with each facility carrying its own personnel, equipment, contractors and issues), and author the SOPs, architectural design system and material specifications that standardize how facilities are built, renovated and operated.

The module gives the PM eight working surfaces — an Overview, the Facilities directory, the Facility Issues queue, the Requests queue (equipment + cross-department), Equipment, Contractors, SOPs & Standards, and Settings — plus the shared detail/action overlays (issue drawer with case-note log, SOP authoring & versioning).

North star metric — Facility Health: the share of facilities in a Healthy state. A facility is Healthy when it has no open high-severity issues, no equipment marked OUT_OF_SERVICE, and a current condition report (not flagged STALE); any facility failing one of these is Needs Attention. This single portfolio number is the PM’s headline — driving it up subsumes fast issue resolution, proactive equipment upkeep, and current field reporting. (Health tiers and the exact thresholds are tunable and will firm up once issue SLAs exist — see §7, §11.)

2. Persona


Role	Facilities Product Manager (Super Admin)
Name (prototype)	Ciroma Chukwuma Adekunle
Department	Facilities
Platform	Atlas web (desktop-first, 1440px)
Ownership entry point	A facility issue or request is filed (by a Station Manager, Facility Manager, another department, or the PM directly) and lands in the PM’s queue
Ownership exit point	The issue is `RESOLVED` with a resolution note, or the request is decided (approved, denied, or redirected) — every transition documented in the activity log
North star	Facility Health — share of facilities in a Healthy state (no open high-severity issues · no `OUT_OF_SERVICE` equipment · current condition report)
Sign-in headline	“Keep every Rechaj facility running, standardized, and accountable.”
Sign-in tagline	“Monitor every site, resolve every issue, decide every request, and enforce one design standard across the portfolio from a single operations surface.”

Operating model (who does what): the Station Manager (single site) files issues and equipment requests and submits weekly reports; the Facility Manager reviews, escalates and resolves within their cluster/region; the Facilities PM owns the whole portfolio, holds final decision authority, and is the only role that can author/publish SOPs and design standards. The Location Acquisition Manager sources new sites against requirements the PM publishes as SOPs. Contractors (including the energy team when engaged) are managed as records and assigned to issues; they are not Atlas users in this scope.

3. Module Structure

The Facilities PM module lives under Facilities in Atlas. As Super Admin the PM sees every surface unscoped (all regions, all sites).

Sidebar item	Purpose	Status
Overview	Portfolio health on login — Facility Health, KPIs, alerts, recent activity	Build
Facilities	The estate directory — every site with region, type, status, condition summary; each site carries its personnel, equipment, contractors and issues	Build
Facility Issues	The issue queue and its lifecycle (Open → Resolved)	Build
Requests	Equipment + cross-department requests routed to the PM for decision	Build
Equipment	Facility-grouped inventory, condition, and new-equipment provisioning	Build
Contractors	Contractors engaged per facility, assignable to issues	Build
SOPs & Standards	Authored, versioned SOPs, design system, material specs, spatial playbooks	Build
Settings	Alert configuration, role permissions, audit-log access	Build

Personnel is not a top-level surface — it is a function of each facility, surfaced as a tab in the Facility Record (§5.2). A read-only Facility Record view is reachable from any facility row; every issue, request, and piece of equipment opens its own detail drawer.

4. Lifecycle & Status Model

Two state machines matter to the PM: issue_status (the facility issue/case) and the equipment provisioning + condition model. Request decisions and SOP versioning are two simpler lifecycles alongside them.

4.1 Facility Issue lifecycle

Filed by                        PM / Facility Manager own the lifecycle                          Closeout
Station Mgr / FM / Dept / PM ─► OPEN ─► IN_PROGRESS ─► PENDING_APPROVAL ─► RESOLVED ──────────► (archived)
                                  │         │  ▲            │  (PM approves the                    ▲
                              [assign]  [reassign]          │   proposed remediation)          [Reopen]
                                  │         │               ▼                                      │
                                  └─────────┴────────► case note appended at every transition ─────┘

Ownership rules (as specified):

Any of Station Manager, Facility Manager, another department, or the PM can file an issue (OPEN). Each issue carries a facility, an urgency/severity, an assignee, and a reporter.
The PM (portfolio) or Facility Manager (within cluster) owns OPEN → RESOLVED. Assigning or reassigning notifies both the previous and the new assignee.
PENDING_APPROVAL is the gate where the PM approves a proposed resolution/remediation plan before it can be marked RESOLVED — quality and standards stay enforced.
RESOLVED requires a resolution note. Reopening a resolved issue is permitted and logged (RESOLVED → REOPENED → IN_PROGRESS).
Every issue has an immutable case-note activity log (timestamp + author on each entry; edits create a new entry, never overwrite).

4.2 Request decisions

Filed (Station Mgr / FM / Dept / PM) ─► SUBMITTED ─► PM_REVIEW ─┬─ APPROVED ──► (equipment: provisioning §4.3; cross-dept: actioned)
                                                                ├─ DENIED (comment required)
                                                                └─ REDIRECTED / DECLINED (out-of-scope cross-dept, with reason)

The PM approves or denies any request (equipment, cross-department, issue remediation) with a comment so requesters understand the decision (FR-19).
Cross-department requests are labelled by requesting department; an out-of-scope request gets a redirect/decline with reason path rather than being forced to resolution.
An approved equipment request enters the provisioning states below; it is never silently written straight into inventory.

4.3 Equipment provisioning & condition

Direct add (PM / FM, no approval) ───────────────────────────────────► IN_INVENTORY
New-equipment request ─► REQUESTED ─► PM review ─┬─ DENIED
                                                 └─ APPROVED ─► (BACKORDERED) ─► RECEIVED ─► IN_INVENTORY

Condition (any inventory item):  GOOD · NEEDS_REPAIR · OUT_OF_SERVICE · RETIRED

Direct inventory add and the new-equipment request are two distinct flows — the request flow requires PM approval before an item joins inventory; a direct add (used when provisioning a new or renovated facility) does not.
APPROVED → BACKORDERED → RECEIVED gives a state between “approved” and “in inventory” for items that aren’t yet on-site.
Every condition change is logged with date + reporter for trend/maintenance history.

4.4 SOP & design-standard versioning

SOPs and design standards are authored, published, and version-controlled (v1.0 → v1.1 → v2.0 …). Publishing a new version supersedes the previous one but does not delete it: in-flight work (e.g. a renovation already following the old spec) can reference the version it started under. SOPs are filed under a main category (Cleaning, Moving & Handling, Opening Procedures, Equipment Maintenance, Safety …) and subdivided by area (Offices, Charge areas, Swap areas, General areas, Retrofit Stations, BAUs, tricycle workshops), or by location type for scouting requirements (Retrofit Station, BAU, Charge-Swap station, Office, Experience Centre).

4.5 Flags

Flag	Condition
STALE (amber)	A facility hasn’t reported equipment condition in more than X days — surfaced on the dashboard and the facility row; drives Facility Health
DUPLICATE	Two open issues describe the same fault at the same facility — flagged to the PM with merge/link affordance
ORPHANED	An issue’s assignee has been off-boarded, or a contractor’s engagement has lapsed, while the issue is still open
DRAFT	A case report/note uploaded but not yet submitted (Location Acquisition Manager companion flow)

5. Screen Specifications

Every list view is filterable, sortable, and CSV-exportable (FR-2), supports saved filters/views per user (FR-3), and has explicit empty and stale-data states — an empty result must never be indistinguishable from a loading or broken state.

Greeting (Good morning, <name>) + one-line context summary (“N of M facilities are healthy; K issues and J requests need you today.”).

Stat cards (FR-1):

Card	Definition
Facility Health (hero)	% of facilities Healthy (the north star) + count that Need Attention
Open Issues	Open issues portfolio-wide, split by severity
Pending Requests	Equipment + cross-department requests awaiting a decision
Equipment Condition	Breakdown across Good / Needs Repair / Out of Service / Retired

Filters: facility · region · date range. Below the cards: a Needs-Attention list (the facilities failing a health check and why) and a recent-activity table (issues raised/resolved, requests submitted). STALE facilities are called out explicitly.

5.2 Facilities (estate directory)

The portfolio of every site. Columns: Facility · Type (Retrofit Station / BAU / Charge-Swap / Office / Experience Centre / Workshop) · Region · Status · Health (Healthy / Needs Attention) · Open issues · Last reported. Filter tabs: All · by Type · by Region · Needs Attention.

Row click → Facility Record — a per-site detail view with tabs:

Overview — status, condition summary, health check breakdown.
Personnel — (folded in from the former standalone surface — FR-13, FR-14) lists everyone staffed at this facility with role and contact; add/edit personnel profiles inline. A person can be staffed at more than one facility (multi-facility assignment). Personnel off-boarded while holding an open issue assignment surface as ORPHANED.
Equipment — this facility’s inventory (mirrors §5.5, scoped to the site).
Contractors — contractors engaged at this facility (mirrors §5.6, scoped to the site).
Issues — open/closed issues at this facility.
SOPs — SOPs/standards linked to this facility or its type.

5.3 Facility Issues

The PM’s issue queue (FR-4 – FR-8). Caption: “Every facility issue across the portfolio · review, assign, approve a resolution, and resolve — each step is logged.”

Filter tabs (with live counts): Open · In Progress · Pending Approval · Resolved · Reopened. Plus search and filters by facility, region, severity, assignee.

Columns: Issue · Facility · Severity · Assignee · Reporter · Age (elapsed time only — no SLA thresholds applied yet, see §7) · Status.

Status pill states: OPEN (amber) · IN_PROGRESS (blue) · PENDING_APPROVAL (violet) · RESOLVED (green) · REOPENED (red).

Row click → issue detail drawer (§6.1): running case-note activity log, assignee, linked facility/equipment, and contextual actions:

Row state	Actions
`OPEN`	Assign · Add case note · Start (→ In Progress)
`IN_PROGRESS`	Reassign · Add case note · Submit resolution for approval (→ Pending Approval)
`PENDING_APPROVAL`	Approve resolution (→ Resolved) · Send back (→ In Progress)
`RESOLVED`	View record · Reopen (→ Reopened, logged)

Badges: DUPLICATE (merge/link), ORPHANED (assignee off-boarded / contractor lapsed).

Filing & evidence: the PM can File issue directly. The file-issue form accepts photos and video — Take photo/video (device camera via capture on mobile/tablet reporters; file picker on desktop) or Upload (image/*,video/*, multiple). Attached media persists on the issue and surfaces as an Evidence thumbnail grid in the drawer (§6.1); case notes likewise support image/video attachments (reporter-side).

5.4 Requests (equipment + cross-department)

Requests routed to the PM for a decision (FR-11, FR-17, FR-18). Tabs (with counts): All · Equipment · Cross-department · Decided. Cross-department requests are labelled by requesting department so the PM can apply the right handling (FR-17).

Columns: Request · Type · Requesting facility/department · Requester · Submitted · Status. Actions: Approve · Deny (comment required) · Reassign · Add case note · for out-of-scope cross-dept requests, Redirect / Decline with reason (§4.2). Equipment approvals flow into §5.5’s provisioning states.

5.5 Equipment

Facility-grouped inventory (FR-9 – FR-12). Columns: Item · Facility · Type/Spec · Condition · Install date · Linked issues. Condition pills: GOOD (green) · NEEDS_REPAIR (amber) · OUT_OF_SERVICE (red) · RETIRED (grey).

Add equipment (primary) — direct inventory add capturing type, specification, install date, condition (FR-10); used when provisioning a new/renovated facility, bypassing the request flow.
New-equipment requests appear under the Requests queue (§5.4), not here (FR-11).
Marking an item OUT_OF_SERVICE while it is tied to an open issue warns rather than silently allowing the issue to close (edge); OUT_OF_SERVICE equipment counts against the facility’s Health.
Classification & filtering: Add-equipment captures a Category (Mechanical · Electrical · Furniture · Plumbing · Other) and a Sub-type that cascades from the chosen category. The inventory is filterable by Category and Facility alongside the condition tabs; Category / Sub-type also show on the equipment detail drawer.

5.6 Contractors

Contractors engaged per facility (FR-15, FR-16). Columns: Company / individual · Trade / specialty · Facility assignment(s) · Contact · Engagement status. A contractor can be the responsible party on an issue (FR-16). Same contractor across multiple sites rolls up correctly in both per-facility and portfolio views (edge). The energy team is listed as contractors whenever engaged (assumption). Lapsed-engagement + still-assigned surfaces as ORPHANED.

5.7 SOPs & Standards

The PM’s authoring surface (FR-22 – FR-24, §4.4). This is authored/published/referenced content, not a request/approval workflow. Tabs: SOPs · Design System · Material Specs · Spatial Playbooks. Columns: Title · Category → Subdivision · Version · Published · Author · Linked facilities/projects.

Author, publish, and version any SOP (FR-22); only the PM (Super Admin) can edit/publish — other roles get read access per permission (FR-24).
Design system, material specs and spatial playbooks are structured, browsable references (not static PDFs), linkable from facility / equipment / issue records (FR-23).
Updating a material spec shows which facilities/projects reference it so the PM understands change impact (§4.4).
The dashboard clearly indicates when an SOP has been updated or deleted; superseded versions remain referenceable for in-flight work.
Documents: each SOP/standard can carry attached documents (PDF · DOC · DOCX · PNG · JPG) uploaded in the authoring dialog (§6.2). The row shows an attachment count and the files reload when the standard is edited.

5.8 Settings

PM preferences, alert configuration (channel: in-app / email · frequency · severity threshold — FR-27), role permissions (the PM can set permissions for other roles — FR-28), and access to the audit trail (FR-29). Multiple Super Admins editing the same configurable parameter need conflict handling (edge).

6. Detail & action overlays

The queues share two overlays. Confirmations on web use centered .dlg modals; detail opens on row click as a drawer (per Atlas web canon — never pinned open by default).

6.1 Issue detail drawer

Opened on any issue row. Shows the case-note activity log (immutable, timestamp + author per entry), facility + linked records (equipment), assignee, severity, and the contextual state actions from §5.3. Adding a case note or changing state appends to the log; nothing overwrites history. If the issue was filed with photos/video, they show in an Evidence thumbnail grid above the log (image previews; video tiles).

6.2 SOP authoring & versioning

Opened from New SOP / Edit (§5.7). Captures title, main category + area/location subdivision, body content, document attachments (PDF · DOC · DOCX · PNG · JPG), and on save publishes a new version (superseding but not deleting the prior). Publishing makes the SOP immediately read-visible to permitted roles; the impact panel lists referencing facilities/projects.

7. SLA & Notifications (PM-relevant)

Alerts are configurable by the PM as Super Admin (channel, frequency, severity threshold — FR-27). No acknowledgment/resolution SLAs are defined yet — alerts are event-based, not SLA-timer-based, and the Age columns show elapsed time only. SLAs by severity are a later decision (§11).

Milestone	Behaviour
High-severity issue filed	Real-time alert to the PM so it can be actioned before it escalates (FR-25)
Equipment / personnel request submitted	Real-time alert; lands in the Requests queue (FR-25)
Cross-department request submitted	Real-time alert, labelled by requesting department (FR-25)
Issue resolved	Alert to the PM for awareness even when resolved by someone else (FR-25, edge)
Facility not reporting condition > X days	STALE flag + dashboard callout; drops the facility out of Healthy
Weekly digest	Summary of open issues + requests across the portfolio, on a configurable day/time (FR-26)
Multi-facility outage / mass event	Alerts batched/grouped so the PM isn’t flooded with redundant notifications (edge)

8. Permissions

The Facilities PM holds Admin (Super Admin) — the highest privilege in Atlas — with full read/write across all Facilities data and configuration, including setting permissions for other roles (FR-28). All Super Admin configuration changes (permissions, SOP publishing, design-standard updates) are logged in an audit trail (FR-29).

Surface / action	PM (Super Admin) access
Overview / Facilities directory	Full read, all regions
Facility Issues	Full read/write; assign, reassign, approve resolution, resolve, reopen
Requests (equipment + cross-dept)	Full read/write; approve, deny, redirect/decline
Equipment	Full read/write; direct add, condition edits, approve requests
Personnel (within a facility) / Contractors	Full read/write; add, edit, assign
SOPs & Standards	Author / publish / version (exclusive to the PM)
Settings / permissions	Configure all roles; access audit trail

Other roles are scoped down (Facility Manager → cluster; Station Manager → single station; Department Requester → own submissions; Location Acquisition Manager → case reports + projects + read SOPs) and specified in the companion PRDs (§12).

9. Data Model (relevant entities & fields)

facility — id, name, location/address, region, type (retrofit_station / bau / charge_swap / office / experience_centre / workshop), status, condition_summary, health (healthy / needs_attention, derived), last_reported_at (drives the STALE flag).
issue (case) — id, facility_id, issue_status (OPEN → IN_PROGRESS → PENDING_APPROVAL → RESOLVED / REOPENED), severity, assignee, reporter, created/updated timestamps, resolution_note, duplicate_of (nullable), media (filed photos/video, reporter-side), case_notes (1:many, immutable).
case_note — id, issue_id, author, body, attachments (images/video — reporter-side), created_at. Immutable; edits create a new entry.
request — id, type (equipment / cross_department), requesting_facility_id or requesting_department, requester, status (SUBMITTED / PM_REVIEW / APPROVED / DENIED / REDIRECTED), approver, decision_note.
equipment — id, facility_id, type/spec, category (mechanical / electrical / furniture / plumbing / other), sub_type (cascades from category), condition (GOOD / NEEDS_REPAIR / OUT_OF_SERVICE / RETIRED), install_date, provisioning_state (REQUESTED / APPROVED / BACKORDERED / RECEIVED / IN_INVENTORY), condition_history (1:many), linked_issue_ids.
personnel — id, name, role, facility_assignments (many), contact_info, status (active / offboarded). Surfaced within the Facility Record.
contractor — id, company/individual, trade, facility_assignments (many), engagement_status, contact_info.
sop / design_standard — id, title, category, subdivision (area or location type), version, published_date, author, superseded_by (nullable), documents (attached files: PDF/DOC/DOCX/image), linked_facilities/projects.
alert — id, type, severity, recipient, channel (in-app / email), status (sent / read), related_entity.
audit_log — id, actor, action, entity, before/after, timestamp (every status change, reassignment, approval/denial, and SOP/standard publish).

10. Out of Scope (this PRD)

Invoicing and the invoice-approval chain to the VP — deferred; not part of the PM flow in this version. (Request approve/deny and the issue-resolution approval gate remain, as they are intrinsic to Requests and Issues.)
Full specification of the Facility Manager, Station Manager, Location Acquisition Manager and Department Requester personas — referenced only; see the companion PRDs (§12).
Contractor-facing access to Atlas — contractors are managed records, not platform users, in this scope.
Mobile-specific requirements — assume responsive web unless a companion flow states otherwise.
Data migration from any legacy tool/spreadsheet (see §11).
Reporting/analytics beyond the Overview cards and CSV export.

11. Open Questions & Assumptions

Open questions

Should the interacting personas (Facility Manager, Station Manager, Location Acquisition Manager) get their own full PRDs, or be appended to this document? (This PRD assumes separate companion PRDs — §12.)
Issue SLAs — acknowledgment/resolution SLAs by severity do not exist yet. Until defined, Age columns show elapsed time only and Facility Health uses issue presence, not SLA breach. Define these to enable SLA-timer alerts and tiered health.
Should SOPs/design standards support formal sign-off/acknowledgment tracking (e.g. “Station Manager X confirmed reading SOP Y”)? (The Station Manager intake explicitly asks for a per-SOP “read” acknowledgment.)
Is there an existing system (legacy tool, spreadsheets) Atlas is replacing, and is data migration in scope?
The STALE window (X days without a condition report) and the exact Facility Health tiering/thresholds are placeholders — confirm the values.

Assumptions

“Admin” for this persona is treated as full Super Admin, consistent with the final-decision authority described in intake.
Weekly digest is sent regardless of whether issues are open or resolved (covers both).
Equipment requests and direct inventory adds are two distinct flows (one requires approval, one does not).
Contractors are purely managed records except the energy team, who are listed as contractors whenever engaged.
All Super Admin actions are reversible/correctable (e.g. reopen a resolved issue), given the PM’s final-decision authority.

12. Companion PRDs — interacting personas (planned)

The Facilities PM module depends on, but does not own, four interacting personas. Each is a planned companion flow under products/atlas/flows/; until built, their behaviour is simulated so the PM flow is demonstrable end-to-end.

Persona	Relationship to this PRD	Planned flow
Facility Manager	Cluster/region admin (View + Edit within cluster); reviews, escalates and resolves; forwards equipment requests to the PM	`facilities-manager`
Station Manager	Single-station View (SOPs) + Edit (reports, issues, requests); files issues with images/video, maintains equipment logs, submits weekly reports, acknowledges SOPs	`facilities-station-manager`
Location Acquisition Manager	Sources sites against PM-published requirement SOPs; map dashboard of facilities + earmarked/surveyed areas; files SOP-tied case reports (with drafts); tracks accepted locations as Projects through to handover	`facilities-location-scout`
Department Requester	Submits cross-department requests that route into the PM’s queue	(cross-dept)

End of PRD. Specifies the Atlas Facilities PM (Super Admin) flow ahead of the prototype; the interactive flow at products/atlas/flows/facilities-pm/index.html will be built to match.

PRD