PRD

RECHAJ — MocX Smart Technologies Inc.

Facilities — Location Acquisition Manager Module

Product Requirements Document — Engineering

Status	v1.1 — revised. Renames the persona from Location Scout, resolves three open questions (access scope, stage-advance authority, naming), fixes duplicated FR numbering. See §5.
Date	July 2026
Prepared by	Product Team (Facilities)
Owners	Facilities Product Manager (TBD) · Office of the CPO
Scope	Atlas (web) — the Location Acquisition Manager persona only. One of the companion PRDs referenced from the Facilities PM PRD §12.
Source of truth	This PRD for requirements; the interactive flow + design.md for design. Where they diverge on a requirement, this document wins.
Classification	CONFIDENTIAL

Implementation status. The flow implements every requirement below. See the PRD traceability table in design.md for where each FR lives.

1. Personas

1.1 Location Acquisition Manager

Role	Facility sourcing, research and estate development
Responsibilities	Looks for buildings, property and land that match our search criteria for new facilities; afterwards handles financial management (lease terms and agreements), regulatory compliance, and managing our relationships with the landlord/letting agency.
Design ownership	N/A
Process ownership	N/A
Scope	Region-scoped — a Location Acquisition Manager sees the locations and projects in their own region.
Reports to	Facilities Product Manager and VP of Facilities only.

Access level

• View — SOPs (the requirement standards the PM publishes); a project’s stage.
• Edit — Case Reports and their case notes/attachments; the lease and landlord record on projects in their region.
• This persona has no Issues queue and no Requests surface. The data model treats Issue / Case Report as a single entity (§3.1), and Case Reports is the only surface for it.

Naming. This persona was first specced as Location Scout, then renamed Estate Manager, and is now Location Acquisition Manager. The remit covers sourcing and development — an accepted location becomes a Project the role carries through to handover, including the lease and the landlord relationship — so the label has widened over time to say so. Through every rename the implemented flow deliberately keeps the slug facilities-location-scout so existing links keep resolving; the slug is the stable id, the name is only the label.

2. Functional Requirements

2.1 Dashboards & Summary Views

User stories

• As the Location Acquisition Manager, I want a single dashboard (map) showing locations of all our facilities, so I can plan for possible areas of expansion.
• As the Location Acquisition Manager, I want to see requirements for proposed facilities, so it can guide me in my search.
• As the Location Acquisition Manager, I want to see updates on submitted reports, so I can proceed with next steps.
• As the Location Acquisition Manager, I want to be able to see all the properties in my region, so I can see what stage in the facility lifecycle it is in.

Requirements

• FR-1: Dashboard shows a location plan containing all our facilities, areas earmarked for expansion, and already surveyed areas.
• FR-2: Tabs with reports and requirements for new facilities.
• FR-3: Status-labelled facility lifecycle.

Edge cases

• Empty states (e.g. no areas at a selected lifecycle stage) must be explicit, not indistinguishable from a loading or broken state.

2.2 Standard Operating Procedures

User stories

• As the Location Acquisition Manager, I want to view all the requirements for any new proposed facility, so I can tailor my search to match these descriptions.
• As the Location Acquisition Manager, I want each SOP to have a tag, so I can identify which SOP is for what location and attach case notes to that SOP.

Requirements

• FR-4: SOPs should be filed as Location, then subdivided into Retrofit Station, Battery Assembly Unit, Charge-Swap Station, Office, Experience Centre.
• FR-5: SOPs can be filtered based on subdivisions.

Edge cases

• Empty states (e.g. a location subdivision with no published SOP) must be explicit, not indistinguishable from a loading or broken state.

2.3 Case Reports

User stories

• As the Location Acquisition Manager, I want to file reports based on SOPs set out by the Product Manager, so I can inform them on developments relating to search requirements set out in the SOP.
• As the Location Acquisition Manager, I want to attach videos, images and text to each case note.

Requirements

• FR-6: Each case note supports text plus image and video attachments, captured on device or uploaded.
• FR-7: Each case report/note should be tied to an SOP.

Edge cases

• Case notes that have been uploaded but not submitted should carry an explicit draft status.

2.4 Projects

User stories

• As the Location Acquisition Manager, I want a tab called projects where I can see all locations accepted by the PM, and monitor them through the lifecycle.
• As the Location Acquisition Manager, I want to see the stage where my updated locations are on the projects tab, so I can monitor their progress.
• As the Location Acquisition Manager, I want to add lease and landlord information to each project, so I can be updated on when the lease is due and have that record on file.
• As the Location Acquisition Manager, I want to add a date reminder for when the lease is due, to aid with financial planning.

Requirements

• FR-8: Locations accepted by the PM/VP should be moved to the projects tab.
• FR-9: Location Acquisition Managers can attach lease agreements and other information to projects in their region.
• FR-10: Each project’s status/stage is one of Leased, Design, Construction, Handover.
• FR-11: Only the PM or VP can advance a project’s stage. The Location Acquisition Manager’s view of stage is read-only — the UI must not offer a stage-advance or handover sign-off action to this persona, consistent with Process ownership: N/A (§1.1). The Location Acquisition Manager can still report upward (flag a delay, send a progress update).

Edge cases

• A project accepted but with no lease record filed yet must show an explicit “not recorded” state, never a blank field.
• A lease inside its renewal window, or already past expiry, must be visibly flagged so a renewal is not missed.
• Because stage is read-only (FR-11), a project whose stage has stalled still needs a route for the Location Acquisition Manager to raise it: reporting upward, not editing the stage.
• Empty states (e.g. no projects at a selected stage) must be explicit, not indistinguishable from a loading or broken state.

3. Technical & Data Requirements

3.1 Core data entities

Entity	Key attributes
Issue / Case Report	ID, reporter, case notes (1:many), attachments (image/video/text), status (draft/submitted/reviewed), SOP (type; subdivision)
SOP	ID, title, SOP (type; subdivision), version, published date
Alert / Notification	ID, type, severity, recipient, channel, status (sent/read), related entity
Project	ID, source location, region, target facility type, SOP, current stage, accepted date, accepted by (PM/VP), target handover
Stage	ID, name (Leased | Design | Construction | Handover), order, entered date, set by (PM/VP only — FR-11)
Lease	ID, project, landlord, letting agent, start date, expiry date, rent, signed agreement (document), renewal reminder date

4. Open questions

The first three are recorded as decided; 4 to 6 still need product input.

#	Question	Status
1	Persona name — Location Scout vs a name that covers development	Resolved. Renamed to Location Acquisition Manager; flow slug stays facilities-location-scout.
2	Does this persona need an Issues queue and a Requests surface, or only Case Reports?	Resolved. Case Reports only. Issue/Case Report is a single entity; no separate Issues or Requests surface.
3	Who can advance a project stage, and is handover sign-off a distinct step?	Resolved. Only the PM/VP advance a stage (FR-11); read-only for the Location Acquisition Manager. Whether handover needs its own sign-off step sits in the PM/VP’s process.
4	Alert/Notification is a listed entity (§3.1) but no requirement says where notifications surface for this persona, and the FR-9 renewal reminder needs somewhere to fire.	Open. Needs a home (Notifications page, email, or both). Should be specced with the fleet-wide Atlas notifications shell, which is also an outstanding shell-parity gap.
5	Regulatory compliance is named in §1.1 responsibilities but has no functional requirement behind it.	Open. Needs requirements, or an explicit statement that it sits outside Atlas for now.
6	Does the Location Acquisition Manager keep visibility of a project after handover, given they still hold the lease and landlord relationship?	Open. The lease outlives the project, so the record needs an owner and a surface post-handover.

5. Revision note

v1.0 → v1.1, so prior references can be reconciled:

• Persona renamed Location Scout → Location Acquisition Manager, with the rationale in §1.1.
• Access level was truncated (View (SOPs, ) + Edit (Reports, Issues and Request)) and is now explicit, resolving open question 2: Case Reports only, plus the lease record on projects.
• FR numbering fixed. FR-3 previously appeared in both §2.1 and §2.2, and §2.3’s FR-5/FR-6 repeated §2.2’s requirements verbatim (a copy-paste). §2.2’s requirements are now FR-4 and FR-5, and the duplicates are removed. FR-8, FR-9 and FR-10 are unchanged, since they are referenced downstream.
• FR-6 added (§2.3) for case-note attachments — present in the user stories but with no requirement behind it.
• FR-11 added (§2.4) for stage-advance authority, resolving open question 3.
• §2.4 Edge Cases was an empty heading and is now populated; edge cases were added to §2.1 and §2.3 for consistency.
• Section numbering fixed — the document jumped §2 → §4 with a §5.1 nested inside. Technical & Data Requirements is now §3.
• §3.1 entities extended — added Lease (required by FR-9 but previously absent) and Project. The Stage entity listed its four values as attributes; it now describes the entity, including set by (PM/VP only).

See also

• The flow this specifies: ./index.html · design notes ./design.md
• The PM this persona reports to: ../facilities-pm/PRD.md §12
• The VP this persona also reports to: ../facilities-vp/index.html
• All Atlas personas / flows: ../README.md