System Requirements Document for law-enforcement-hr

1. Introduction

law-enforcement-hr is an all-in-one law enforcement HR software product: a single administrative system of record where one HR Administrator maintains the agency's personnel, equipment, vehicles, and other agency records through add, edit, and delete operations. The product is built and designed page by page, beginning with the admin dashboard, which is the administrative landing workspace from which every record area is entered.

The audience is the HR Administrator of a law enforcement agency — the sole named actor — who needs one disciplined, official-feeling workspace where all HR and asset records are kept accurate and current. The product's intent is centralized record management: not a consumer tool, not a marketing surface, but institutional infrastructure whose information must be codified, legible, and impossible to misread.

2. System Overview

law-enforcement-hr is delivered as a first-party web application with custom UI and application-owned identity. The HR Administrator reaches a public Landing surface that introduces the product and its centralized administrative record-management purpose, then establishes access through Login (first access is established through an invitation or provisioning boundary), and works inside a protected administrative area: the admin dashboard, the Personnel, Equipment, Vehicles, and Other Records workspaces, and the focused New Personnel, New Equipment, New Vehicle, and New Other creation/editing workspaces.

The accepted behavior is narrow and exact: the HR Administrator can add, edit, and delete personnel records, equipment records, vehicle records, and other (unspecified additional category) records. The admin dashboard is the first page built and the administrative entry point to those record areas. No other human actors, roles, or permission tiers are established by the source; the HR Administrator is the sole active human persona.

2a. Product Interpretation and Delivery Boundary

Delivery ownership. The product is a first-party application with custom UI. All record-management work — browsing, creating, editing, and deleting personnel, equipment, vehicle, and other records — is performed inside the application's own pages. There is no provider-owned or external-destination surface for record management, and no headless-only delivery: the accepted work is human-facing administrative interaction.

Access ownership. Record data is durable and must remain bound to the correct administrator across sessions, so the application owns identity. The public Landing surface is anonymously reachable and introduces the product. Login is the returning-verification boundary and is itself anonymously reachable — it cannot own the interaction that establishes access to itself. First access is established through an invitation or provisioning boundary outside the protected area; the protected destinations (admin dashboard, Personnel, New Personnel, Equipment, New Equipment, Vehicles, New Vehicle, Other Records, New Other) require login. Application identity and session continuity establish who the administrator is; they do not establish differentiated permissions, because the source names exactly one administrative actor with one undivided set of record-management capabilities.

Current boundary. Current scope is: the Landing surface, Login, the admin dashboard, and the four record families (Personnel, Equipment, Vehicles, Other Records) each with a revisitable list workspace and a focused create/edit workspace. The page-by-page build begins with the admin dashboard.

Future boundary. The source states the build proceeds page by page beginning with the admin dashboard; that is a sequencing constraint on the current build, not a commitment to any specific later capability. No additional record categories, roles, modules, reporting, or integrations are accepted as current requirements. "Others" is preserved as an explicit current record family with unspecified category contents, not as license to invent specific adjacent modules.

2b. Source Content Inventory

Not applicable — no reference directive in this project declares content_source authority, so no source content inventory is rendered.

2c. Page Content and Component Coverage

Landing

• Information / state: Anonymous public entry. Product identity "LAW ENFORCEMENT HR" as the wordmark; a one-line statement of the product's purpose (all-in-one law enforcement HR record management for personnel, equipment, vehicles, and other agency records); the four record families presented as a colour-coded legend (Personnel / Equipment / Vehicles / Other Records) so the product's scope is readable before access.
• Primary action: Enter Login ("Sign in").
• Supporting actions: None beyond entry; no signup, no self-service account creation, no marketing CTA stack.
• Domain entities: None persisted; the four record-family categories are presented as legend entries only.
• Component responsibilities: Full-bleed black command bar carrying the wordmark; a four-block wayfinding strip (red / yellow / green / slate) naming the four record families; a schematic line diagram of the four categories radiating from a central "Records" node drawn in 2px black strokes with each branch in its category colour; a single bordered rectangular entry control to Login.
• States: Loading — static content, no spinner required. Empty — not applicable (no data surface). Success — page renders fully; entry control is reachable. Error — if the application shell fails to load, a plain ruled error band with a retry control. Recovery — retry reloads the Landing surface.

Login

• Information / state: Anonymous access boundary. Credential fields for the returning HR Administrator; a short statement that first access is established by invitation or provisioning from the agency, not by self-service signup.
• Primary action: Submit credentials to verify identity and enter the protected administrative area.
• Supporting actions: Return to Landing; recover from a failed verification attempt.
• Domain entities: Administrator identity (credential pair); session continuity.
• Component responsibilities: Ruled credential form with 2px black top rule; labelled inputs with zero radius; a single red primary submit button; an inline error band for failed verification; a muted note describing the invitation/provisioning boundary.
• States: Loading — submit control shows a pending state while verification runs. Empty — fields render empty with labels and no placeholder-as-label substitution. Success — verification succeeds and the administrator lands on the admin dashboard. Error — invalid credentials render an inline red error band above the form with the fields preserved for correction; an unprovisioned identity renders a distinct message directing the administrator to the agency's invitation/provisioning contact. Recovery — the administrator corrects credentials and resubmits, or returns to Landing.

admin dashboard

• Information / state: Protected administrative landing workspace and the first page of the build. Full-bleed black command bar with the wordmark, agency name, and current date/shift; a four-block wayfinding strip showing live counts for Personnel, Equipment, Vehicles, and Other Records; a numbered section rail (01 Personnel, 02 Equipment, 03 Vehicles, 04 Other Records); a main column of ruled tabular record blocks beginning with Personnel.
• Primary action: Navigate into a record family (Personnel, Equipment, Vehicles, or Other Records) via the wayfinding strip or the numbered section rail.
• Supporting actions: Jump to a numbered section within the dashboard; open a record family's focused create workspace from its block.
• Domain entities: Personnel records, equipment records, vehicle records, other records — surfaced here as counts and as ruled table rows (name, ID, assignment, status) with the row's category colour as an 8px left marker.
• Component responsibilities: Command bar (wordmark, agency name, date/shift); wayfinding strip (four equal colour blocks, each with a 48px tabular count and uppercase label, each a live navigation target); numbered section rail with 2px black rules between entries; ruled white record panels with 2px black top rules; per-row EDIT and DELETE labelled bordered controls flush right.
• States: Loading — the four category bars draw their width from 0 to full over 400ms with linear ease, then stop; counts and rows resolve. Empty — a record family with no records shows its block with a zero count and a ruled empty row stating no records exist yet, with a bordered "ADD" control into that family's create workspace. Success — counts and rows render; navigation targets are live. Error — a failed count or row load renders a ruled error band in place of the affected block with a retry control; other blocks remain usable. Recovery — retry reloads the affected block; navigation to other families remains available. With prefers-reduced-motion, the bar draw is removed and bars render at full width.

Personnel

• Information / state: Protected, revisitable personnel-record workspace. Ruled table of personnel records with columns for name, ID, assignment, and status; each row carries the red personnel category marker on its left edge; a record count and table caption in muted type.
• Primary action: Open a personnel record for editing.
• Supporting actions: Delete a personnel record; navigate to New Personnel to add a record; return to the admin dashboard.
• Domain entities: Personnel record (name, ID, assignment, status).
• Component responsibilities: 2px black top rule and section header; ruled table with 1px horizontal rules between rows; 8px red left marker per row widening to 14px on hover; flush-right bordered EDIT and DELETE text controls; in-place red confirmation band for delete.
• States: Loading — table skeleton of ruled rows while records resolve. Empty — ruled empty state stating no personnel records exist, with a bordered "ADD PERSONNEL" control into New Personnel. Success — rows render with markers and controls. Error — a ruled error band replaces the table with a retry control. Recovery — retry reloads the table; the administrator can also navigate away and return.

New Personnel

• Information / state: Protected focused workspace for creating and editing a personnel record. Ruled form fields for the personnel record's attributes (name, ID, assignment, status); a mode indicator distinguishing create from edit.
• Primary action: Save the personnel record (create or update).
• Supporting actions: Cancel and return to Personnel; on edit, delete the record from this workspace.
• Domain entities: Personnel record (name, ID, assignment, status).
• Component responsibilities: 2px black top rule and section header; labelled inputs with zero radius and 2px black focus rings offset 2px; a single red primary save button; a bordered cancel control; inline validation bands; on edit, a bordered DELETE control opening the in-place red confirmation band.
• States: Loading — on edit, fields populate from the existing record with a pending state on the form. Empty — create mode renders empty labelled fields. Success — save persists the record and returns to Personnel with the record visible in the table. Error — validation failures render inline bands naming the offending field and preserve entered values; a persistence failure renders a ruled error band with a retry control and preserves entered values. Recovery — correct the field or retry the save; cancel returns to Personnel without persisting.

Equipment

• Information / state: Protected, revisitable equipment-record workspace. Ruled table of equipment records with columns for item name, ID, assignment, and status; each row carries the yellow equipment category marker on its left edge; a record count and table caption in muted type.
• Primary action: Open an equipment record for editing.
• Supporting actions: Delete an equipment record; navigate to New Equipment to add a record; return to the admin dashboard.
• Domain entities: Equipment record (item name, ID, assignment, status).
• Component responsibilities: 2px black top rule and section header; ruled table with 1px horizontal rules; 8px yellow left marker per row widening to 14px on hover; flush-right bordered EDIT and DELETE text controls; in-place red confirmation band for delete.
• States: Loading — table skeleton of ruled rows. Empty — ruled empty state stating no equipment records exist, with a bordered "ADD EQUIPMENT" control into New Equipment. Success — rows render with markers and controls. Error — ruled error band replaces the table with a retry control. Recovery — retry reloads the table; navigation away and back remains available.

New Equipment

• Information / state: Protected focused workspace for creating and editing an equipment record. Ruled form fields for the equipment record's attributes (item name, ID, assignment, status); a mode indicator distinguishing create from edit.
• Primary action: Save the equipment record (create or update).
• Supporting actions: Cancel and return to Equipment; on edit, delete the record from this workspace.
• Domain entities: Equipment record (item name, ID, assignment, status).
• Component responsibilities: 2px black top rule and section header; labelled inputs with zero radius and 2px black focus rings offset 2px; a single red primary save button; a bordered cancel control; inline validation bands; on edit, a bordered DELETE control opening the in-place red confirmation band.
• States: Loading — on edit, fields populate from the existing record. Empty — create mode renders empty labelled fields. Success — save persists the record and returns to Equipment with the record visible. Error — validation failures render inline bands naming the offending field and preserve entered values; a persistence failure renders a ruled error band with a retry control and preserves entered values. Recovery — correct the field or retry the save; cancel returns to Equipment without persisting.

Vehicles

• Information / state: Protected, revisitable vehicle-record workspace. Ruled table of vehicle records with columns for vehicle identifier, ID, assignment, and status; each row carries the green vehicle category marker on its left edge; a record count and table caption in muted type.
• Primary action: Open a vehicle record for editing.
• Supporting actions: Delete a vehicle record; navigate to New Vehicle to add a record; return to the admin dashboard.
• Domain entities: Vehicle record (vehicle identifier, ID, assignment, status).
• Component responsibilities: 2px black top rule and section header; ruled table with 1px horizontal rules; 8px green left marker per row widening to 14px on hover; flush-right bordered EDIT and DELETE text controls; in-place red confirmation band for delete.
• States: Loading — table skeleton of ruled rows. Empty — ruled empty state stating no vehicle records exist, with a bordered "ADD VEHICLE" control into New Vehicle. Success — rows render with markers and controls. Error — ruled error band replaces the table with a retry control. Recovery — retry reloads the table; navigation away and back remains available.

New Vehicle

• Information / state: Protected focused workspace for creating and editing a vehicle record. Ruled form fields for the vehicle record's attributes (vehicle identifier, ID, assignment, status); a mode indicator distinguishing create from edit.
• Primary action: Save the vehicle record (create or update).
• Supporting actions: Cancel and return to Vehicles; on edit, delete the record from this workspace.
• Domain entities: Vehicle record (vehicle identifier, ID, assignment, status).
• Component responsibilities: 2px black top rule and section header; labelled inputs with zero radius and 2px black focus rings offset 2px; a single red primary save button; a bordered cancel control; inline validation bands; on edit, a bordered DELETE control opening the in-place red confirmation band.
• States: Loading — on edit, fields populate from the existing record. Empty — create mode renders empty labelled fields. Success — save persists the record and returns to Vehicles with the record visible. Error — validation failures render inline bands naming the offending field and preserve entered values; a persistence failure renders a ruled error band with a retry control and preserves entered values. Recovery — correct the field or retry the save; cancel returns to Vehicles without persisting.

Other Records

• Information / state: Protected, revisitable workspace for additional agency record categories. Ruled table of other records with columns for record name, ID, category, and status; each row carries the slate category marker on its left edge; a record count and table caption in muted type.
• Primary action: Open an other record for editing.
• Supporting actions: Delete an other record; navigate to New Other to add a record; return to the admin dashboard.
• Domain entities: Other record (record name, ID, category, status).
• Component responsibilities: 2px black top rule and section header; ruled table with 1px horizontal rules; 8px slate left marker per row widening to 14px on hover; flush-right bordered EDIT and DELETE text controls; in-place red confirmation band for delete.
• States: Loading — table skeleton of ruled rows. Empty — ruled empty state stating no other records exist, with a bordered "ADD RECORD" control into New Other. Success — rows render with markers and controls. Error — ruled error band replaces the table with a retry control. Recovery — retry reloads the table; navigation away and back remains available.

New Other

• Information / state: Protected focused workspace for creating and editing a record in an additional agency category. Ruled form fields for the record's attributes (record name, ID, category, status); a mode indicator distinguishing create from edit.
• Primary action: Save the other record (create or update).
• Supporting actions: Cancel and return to Other Records; on edit, delete the record from this workspace.
• Domain entities: Other record (record name, ID, category, status).
• Component responsibilities: 2px black top rule and section header; labelled inputs with zero radius and 2px black focus rings offset 2px; a single red primary save button; a bordered cancel control; inline validation bands; on edit, a bordered DELETE control opening the in-place red confirmation band.
• States: Loading — on edit, fields populate from the existing record. Empty — create mode renders empty labelled fields. Success — save persists the record and returns to Other Records with the record visible. Error — validation failures render inline bands naming the offending field and preserve entered values; a persistence failure renders a ruled error band with a retry control and preserves entered values. Recovery — correct the field or retry the save; cancel returns to Other Records without persisting.

3. Functional Requirements

FR-1 — Product delivery. As the HR Administrator, I should have an all-in-one law enforcement HR software product that centralizes personnel, equipment, vehicle, and other agency records in one administrative system, so that I do not maintain these records across separate tools. (provenance: explicit)

• Trigger: the administrator opens the product.
• Observable result: a single application containing the admin dashboard and the four record families.
• Access state: the product's public entry is anonymously reachable; record management requires login.
• Failure/recovery: if the application shell fails to load, a ruled error band with a retry control is shown.
• Continuation: the administrator proceeds to Landing, then Login, then the admin dashboard.

FR-2 — Add personnel records. As the HR Administrator, I should be able to add personnel records, so that new personnel are captured in the system of record. (provenance: explicit)

• Trigger: the administrator opens New Personnel from Personnel or from the admin dashboard.
• Input: personnel attributes entered into the ruled form (name, ID, assignment, status).
• Observable result: the saved record appears as a ruled row in the Personnel table with its red category marker.
• Access state: login required.
• Failure/recovery: validation failures render inline bands naming the offending field and preserve entered values; a persistence failure renders a ruled error band with a retry control and preserves entered values.
• Continuation: the administrator returns to Personnel, or adds another record.

FR-3 — Edit personnel records. As the HR Administrator, I should be able to edit personnel records, so that personnel information stays accurate and current. (provenance: explicit)

• Trigger: the administrator selects EDIT on a personnel row, or opens a record from Personnel.
• Input: revised personnel attributes in the ruled form.
• Observable result: the updated values render in the Personnel table row.
• Access state: login required.
• Failure/recovery: validation failures render inline bands and preserve entered values; a persistence failure renders a ruled error band with a retry control and preserves entered values.
• Continuation: the administrator returns to Personnel with the updated row visible.

FR-4 — Delete personnel records. As the HR Administrator, I should be able to delete personnel records, so that records no longer applicable are removed from the system of record. (provenance: explicit)

• Trigger: the administrator selects DELETE on a personnel row or in the edit workspace.
• Observable result: the row is replaced in place by a full-width red confirmation band containing the record name in white uppercase and two bordered actions; confirming removes the record and the table re-renders without it.
• Access state: login required.
• Failure/recovery: cancelling the confirmation band restores the row unchanged; a persistence failure renders a ruled error band with a retry control and the row remains.
• Continuation: the administrator continues working in Personnel.

FR-5 — Add equipment records. As the HR Administrator, I should be able to add equipment records, so that agency equipment is captured in the system of record. (provenance: explicit)

• Trigger: the administrator opens New Equipment from Equipment or from the admin dashboard.
• Input: equipment attributes entered into the ruled form (item name, ID, assignment, status).
• Observable result: the saved record appears as a ruled row in the Equipment table with its yellow category marker.
• Access state: login required.
• Failure/recovery: validation failures render inline bands naming the offending field and preserve entered values; a persistence failure renders a ruled error band with a retry control and preserves entered values.
• Continuation: the administrator returns to Equipment, or adds another record.

FR-6 — Edit equipment records. As the HR Administrator, I should be able to edit equipment records, so that equipment information stays accurate and current. (provenance: explicit)

• Trigger: the administrator selects EDIT on an equipment row, or opens a record from Equipment.
• Input: revised equipment attributes in the ruled form.
• Observable result: the updated values render in the Equipment table row.
• Access state: login required.
• Failure/recovery: validation failures render inline bands and preserve entered values; a persistence failure renders a ruled error band with a retry control and preserves entered values.
• Continuation: the administrator returns to Equipment with the updated row visible.

FR-7 — Delete equipment records. As the HR Administrator, I should be able to delete equipment records, so that equipment no longer applicable is removed from the system of record. (provenance: explicit)

• Trigger: the administrator selects DELETE on an equipment row or in the edit workspace.
• Observable result: the row is replaced in place by a full-width red confirmation band containing the record name in white uppercase and two bordered actions; confirming removes the record and the table re-renders without it.
• Access state: login required.
• Failure/recovery: cancelling the confirmation band restores the row unchanged; a persistence failure renders a ruled error band with a retry control and the row remains.
• Continuation: the administrator continues working in Equipment.

FR-8 — Add vehicle records. As the HR Administrator, I should be able to add vehicle records, so that agency vehicles are captured in the system of record. (provenance: explicit)

• Trigger: the administrator opens New Vehicle from Vehicles or from the admin dashboard.
• Input: vehicle attributes entered into the ruled form (vehicle identifier, ID, assignment, status).
• Observable result: the saved record appears as a ruled row in the Vehicles table with its green category marker.
• Access state: login required.
• Failure/recovery: validation failures render inline bands naming the offending field and preserve entered values; a persistence failure renders a ruled error band with a retry control and preserves entered values.
• Continuation: the administrator returns to Vehicles, or adds another record.

FR-9 — Edit vehicle records. As the HR Administrator, I should be able to edit vehicle records, so that vehicle information stays accurate and current. (provenance: explicit)

• Trigger: the administrator selects EDIT on a vehicle row, or opens a record from Vehicles.
• Input: revised vehicle attributes in the ruled form.
• Observable result: the updated values render in the Vehicles table row.
• Access state: login required.
• Failure/recovery: validation failures render inline bands and preserve entered values; a persistence failure renders a ruled error band with a retry control and preserves entered values.
• Continuation: the administrator returns to Vehicles with the updated row visible.

FR-10 — Delete vehicle records. As the HR Administrator, I should be able to delete vehicle records, so that vehicles no longer applicable are removed from the system of record. (provenance: explicit)

• Trigger: the administrator selects DELETE on a vehicle row or in the edit workspace.
• Observable result: the row is replaced in place by a full-width red confirmation band containing the record name in white uppercase and two bordered actions; confirming removes the record and the table re-renders without it.
• Access state: login required.
• Failure/recovery: cancelling the confirmation band restores the row unchanged; a persistence failure renders a ruled error band with a retry control and the row remains.
• Continuation: the administrator continues working in Vehicles.

FR-11 — Add other records. As the HR Administrator, I should be able to add records in additional agency categories, so that agency records outside personnel, equipment, and vehicles are also captured in the system of record. (provenance: explicit)

• Trigger: the administrator opens New Other from Other Records or from the admin dashboard.
• Input: record attributes entered into the ruled form (record name, ID, category, status).
• Observable result: the saved record appears as a ruled row in the Other Records table with its slate category marker.
• Access state: login required.
• Failure/recovery: validation failures render inline bands naming the offending field and preserve entered values; a persistence failure renders a ruled error band with a retry control and preserves entered values.
• Continuation: the administrator returns to Other Records, or adds another record.

FR-12 — Edit other records. As the HR Administrator, I should be able to edit records in additional agency categories, so that those records stay accurate and current. (provenance: explicit)

• Trigger: the administrator selects EDIT on an other-record row, or opens a record from Other Records.
• Input: revised record attributes in the ruled form.
• Observable result: the updated values render in the Other Records table row.
• Access state: login required.
• Failure/recovery: validation failures render inline bands and preserve entered values; a persistence failure renders a ruled error band with a retry control and preserves entered values.
• Continuation: the administrator returns to Other Records with the updated row visible.

FR-13 — Delete other records. As the HR Administrator, I should be able to delete records in additional agency categories, so that records no longer applicable are removed from the system of record. (provenance: explicit)

• Trigger: the administrator selects DELETE on an other-record row or in the edit workspace.
• Observable result: the row is replaced in place by a full-width red confirmation band containing the record name in white uppercase and two bordered actions; confirming removes the record and the table re-renders without it.
• Access state: login required.
• Failure/recovery: cancelling the confirmation band restores the row unchanged; a persistence failure renders a ruled error band with a retry control and the row remains.
• Continuation: the administrator continues working in Other Records.

FR-14 — Admin dashboard as the administrative entry point. As the HR Administrator, I should land on the admin dashboard after verification and be able to enter any record family from it, so that all record management starts from one administrative workspace. (provenance: explicit)

• Trigger: successful verification, or navigation back to the dashboard.
• Observable result: the command bar, the four-block wayfinding strip with live counts, the numbered section rail, and the first record table render; each wayfinding block and rail entry is a live navigation target.
• Access state: login required.
• Failure/recovery: a failed count or row load renders a ruled error band in place of the affected block with a retry control while other blocks remain usable.
• Continuation: the administrator enters Personnel, Equipment, Vehicles, or Other Records.

FR-15 — Page-by-page build beginning with the admin dashboard. As the HR Administrator, I should receive the product built and designed page by page, beginning with the admin dashboard, so that the administrative entry point is established first and the remaining record workspaces follow it. (provenance: explicit)

• Trigger: the build proceeds.
• Observable result: the admin dashboard is the first page designed and created; the remaining pages follow in the page-by-page sequence.
• Access state: not applicable to the build sequence itself.
• Failure/recovery: not applicable.
• Continuation: subsequent pages are added in sequence.

FR-16 — Public product introduction. As a visitor, I should be able to reach a public Landing surface that introduces the all-in-one law enforcement HR software and its centralized administrative record-management purpose, so that I understand what the product is before establishing access. (provenance: required_inference)

• Trigger: the visitor opens the product's public address.
• Observable result: the Landing surface renders the wordmark, the product purpose, the four record families as a colour-coded legend, and a single bordered entry control to Login.
• Access state: none — anonymously reachable.
• Failure/recovery: if the application shell fails to load, a plain ruled error band with a retry control is shown.
• Continuation: the visitor enters Login.

FR-17 — Returning verification through Login. As the HR Administrator, I should be able to verify my identity through Login and return to my durable records, so that personnel, equipment, vehicle, and other records remain bound to me across sessions. (provenance: required_inference)

• Trigger: the administrator submits credentials on Login.
• Input: credential pair.
• Observable result: verification succeeds and the administrator lands on the admin dashboard with their records available.
• Access state: Login is anonymously reachable; the protected destinations require login.
• Failure/recovery: invalid credentials render an inline red error band above the form with fields preserved for correction; an unprovisioned identity renders a distinct message directing the administrator to the agency's invitation/provisioning contact.
• Continuation: the administrator corrects credentials and resubmits, or returns to Landing.

FR-18 — First-use identity establishment through invitation or provisioning. As the HR Administrator, I should have my first access established through an agency invitation or provisioning boundary, so that my identity exists before I verify through Login. (provenance: required_inference)

• Trigger: the agency issues an invitation or provisions the administrator's identity.
• Observable result: the administrator's identity exists and can be verified through Login.
• Access state: this boundary is outside the protected area; Login cannot own the interaction that establishes access to itself.
• Failure/recovery: an administrator who has not been provisioned sees the distinct unprovisioned message on Login and is directed to the agency's invitation/provisioning contact.
• Continuation: the administrator proceeds to Login.

4. User Personas

HR Administrator

Product context. The HR Administrator is the sole named actor of law-enforcement-hr and the only active human persona. They work inside a single administrative system of record for one law enforcement agency, maintaining four record families — personnel, equipment, vehicles, and other agency records — from one administrative workspace. Their working context is institutional and procedural: the records they hold are the agency's authoritative account of its people and its assets, so the interface must read as official, codified, and impossible to misread rather than as a consumer tool.

Primary goal. A single administrative workspace where all law enforcement HR and asset records are maintained, with records that stay accurate and current through add, edit, and delete operations.

Distinct accepted responsibilities. The HR Administrator owns the complete lifecycle of four record families: adding, editing, and deleting personnel records; adding, editing, and deleting equipment records; adding, editing, and deleting vehicle records; and adding, editing, and deleting records in additional agency categories. They also own the administrative entry point itself — the admin dashboard is their landing workspace and the origin of every record-management task. No other actor shares or divides these responsibilities; the source establishes no second role, no approval chain, and no differentiated permission tier.

Relevant inputs and decisions. The administrator supplies record attributes through ruled forms (name or item name or vehicle identifier or record name, ID, assignment or category, and status) and decides when a record is created, corrected, or removed. Deletion is a deliberate decision made against an in-place confirmation band that names the record, so the administrator confirms the specific record rather than a generic prompt.

Interactions with other accepted participants. There are no other accepted human participants in the current product. The administrator's only non-self interaction is with the agency's invitation or provisioning boundary, which establishes their identity before first verification; after that, all accepted work is performed by the administrator alone.

Observable success. Saved records appear as ruled rows in the correct record family's table with that family's category colour marker; edited values render in place; deleted records disappear from the table after confirmation; the dashboard's wayfinding counts reflect the current state of each record family. The administrator can leave and return, verify through Login, and find their records intact.

5. Core User Flows

Flow 1 — First access and returning verification (HR Administrator)

1. The agency issues an invitation or provisions the HR Administrator's identity. (Owner: invitation/provisioning boundary — outside the protected area.)
2. The administrator opens the product's public address and lands on Landing, which renders the wordmark, the product purpose, the four record families as a colour-coded legend, and a single bordered entry control. (Owner: Landing.)
3. The administrator selects the entry control and arrives at Login. (Owner: Login.)
4. The administrator enters their credentials and submits. (Owner: Login.)
5. Observable result: verification succeeds and the administrator lands on the admin dashboard, where the command bar, the four-block wayfinding strip with live counts, the numbered section rail, and the first record table render. (Owner: admin dashboard.)
6. Failure/recovery: if the credentials are invalid, an inline red error band appears above the form with the fields preserved; the administrator corrects and resubmits. If the identity has not been provisioned, a distinct message directs the administrator to the agency's invitation/provisioning contact.
7. Continuation: the administrator proceeds to any record family from the wayfinding strip or the numbered section rail.

Flow 2 — Add a personnel record (HR Administrator)

1. The administrator is on the admin dashboard after verification. (Owner: admin dashboard.)
2. The administrator selects the Personnel block in the wayfinding strip or entry 01 in the numbered section rail and arrives at Personnel, where the ruled personnel table renders with its red category markers. (Owner: Personnel.)
3. The administrator selects the bordered "ADD PERSONNEL" control and arrives at New Personnel in create mode with empty labelled fields. (Owner: New Personnel.)
4. The administrator enters the personnel attributes (name, ID, assignment, status) and selects the red save button. (Owner: New Personnel.)
5. Observable result: the record is persisted and the administrator returns to Personnel, where the new record appears as a ruled row carrying its red category marker; the dashboard's Personnel count reflects the addition on next view. (Owner: Personnel.)
6. Failure/recovery: validation failures render inline bands naming the offending field and preserve entered values; a persistence failure renders a ruled error band with a retry control and preserves entered values. Cancelling returns to Personnel without persisting.
7. Continuation: the administrator adds another record or returns to the dashboard.

Flow 3 — Edit a personnel record (HR Administrator)

1. The administrator is on Personnel with the ruled table rendered. (Owner: Personnel.)
2. The administrator selects the bordered EDIT control on the target row and arrives at New Personnel in edit mode with the record's values populated. (Owner: New Personnel.)
3. The administrator revises the attributes and selects the red save button. (Owner: New Personnel.)
4. Observable result: the updated values render in the Personnel table row. (Owner: Personnel.)
5. Failure/recovery: validation failures render inline bands and preserve entered values; a persistence failure renders a ruled error band with a retry control and preserves entered values. Cancelling returns to Personnel with the row unchanged.
6. Continuation: the administrator edits another record or returns to the dashboard.

Flow 4 — Delete a personnel record (HR Administrator)

1. The administrator is on Personnel with the ruled table rendered. (Owner: Personnel.)
2. The administrator selects the bordered DELETE control on the target row. (Owner: Personnel.)
3. Observable result: the row is replaced in place by a full-width red confirmation band containing the record name in white uppercase and two bordered actions, keeping the table's rhythm intact. (Owner: Personnel.)
4. The administrator confirms the deletion. (Owner: Personnel.)
5. Observable result: the record is removed and the table re-renders without it; the dashboard's Personnel count reflects the removal on next view. (Owner: Personnel.)
6. Failure/recovery: cancelling the confirmation band restores the row unchanged; a persistence failure renders a ruled error band with a retry control and the row remains.
7. Continuation: the administrator continues working in Personnel or returns to the dashboard.

Flow 5 — Add, edit, or delete an equipment record (HR Administrator)

1. The administrator is on the admin dashboard and selects the Equipment block or entry 02 in the numbered section rail, arriving at Equipment with the ruled equipment table and its yellow category markers. (Owner: Equipment.)
2. To add: the administrator selects the bordered "ADD EQUIPMENT" control, arrives at New Equipment in create mode, enters the equipment attributes (item name, ID, assignment, status), and saves. Observable result: the record appears as a ruled row in Equipment with its yellow marker. (Owner: New Equipment → Equipment.)
3. To edit: the administrator selects EDIT on a row, arrives at New Equipment in edit mode with values populated, revises them, and saves. Observable result: the updated values render in the Equipment table row. (Owner: New Equipment → Equipment.)
4. To delete: the administrator selects DELETE on a row; the row is replaced in place by the full-width red confirmation band naming the record; confirming removes it and the table re-renders without it. (Owner: Equipment.)
5. Failure/recovery: validation failures render inline bands naming the offending field and preserve entered values; persistence failures render a ruled error band with a retry control and preserve entered values; cancelling a delete restores the row unchanged.
6. Continuation: the administrator continues in Equipment or returns to the dashboard.

Flow 6 — Add, edit, or delete a vehicle record (HR Administrator)

1. The administrator is on the admin dashboard and selects the Vehicles block or entry 03 in the numbered section rail, arriving at Vehicles with the ruled vehicle table and its green category markers. (Owner: Vehicles.)
2. To add: the administrator selects the bordered "ADD VEHICLE" control, arrives at New Vehicle in create mode, enters the vehicle attributes (vehicle identifier, ID, assignment, status), and saves. Observable result: the record appears as a ruled row in Vehicles with its green marker. (Owner: New Vehicle → Vehicles.)
3. To edit: the administrator selects EDIT on a row, arrives at New Vehicle in edit mode with values populated, revises them, and saves. Observable result: the updated values render in the Vehicles table row. (Owner: New Vehicle → Vehicles.)
4. To delete: the administrator selects DELETE on a row; the row is replaced in place by the full-width red confirmation band naming the record; confirming removes it and the table re-renders without it. (Owner: Vehicles.)
5. Failure/recovery: validation failures render inline bands naming the offending field and preserve entered values; persistence failures render a ruled error band with a retry control and preserve entered values; cancelling a delete restores the row unchanged.
6. Continuation: the administrator continues in Vehicles or returns to the dashboard.

Flow 7 — Add, edit, or delete an other record (HR Administrator)

1. The administrator is on the admin dashboard and selects the Other block or entry 04 in the numbered section rail, arriving at Other Records with the ruled table and its slate category markers. (Owner: Other Records.)
2. To add: the administrator selects the bordered "ADD RECORD" control, arrives at New Other in create mode, enters the record attributes (record name, ID, category, status), and saves. Observable result: the record appears as a ruled row in Other Records with its slate marker. (Owner: New Other → Other Records.)
3. To edit: the administrator selects EDIT on a row, arrives at New Other in edit mode with values populated, revises them, and saves. Observable result: the updated values render in the Other Records table row. (Owner: New Other → Other Records.)
4. To delete: the administrator selects DELETE on a row; the row is replaced in place by the full-width red confirmation band naming the record; confirming removes it and the table re-renders without it. (Owner: Other Records.)
5. Failure/recovery: validation failures render inline bands naming the offending field and preserve entered values; persistence failures render a ruled error band with a retry control and preserve entered values; cancelling a delete restores the row unchanged.
6. Continuation: the administrator continues in Other Records or returns to the dashboard.

Flow 8 — Read the dashboard as a control board (HR Administrator)

1. The administrator lands on the admin dashboard after verification. (Owner: admin dashboard.)
2. On load, the four category bars draw their width from 0 to full over 400ms with a linear ease, then stop; with prefers-reduced-motion, the draw is removed and the bars render at full width. (Owner: admin dashboard.)
3. The administrator reads the wayfinding strip left to right: red Personnel, yellow Equipment, green Vehicles, slate Other Records, each with a 48px tabular count and uppercase label. (Owner: admin dashboard.)
4. Observable result: the administrator can see at a glance how many records exist in each family and can select any block or numbered rail entry to enter that family. (Owner: admin dashboard.)
5. Failure/recovery: a failed count or row load renders a ruled error band in place of the affected block with a retry control while the other blocks remain usable.
6. Continuation: the administrator enters the record family that needs attention.

6. Visuals Colors and Theme

Muse and headline. Massimo Vignelli — Systematic command clarity. The design language is the design of authority through codified information: strict columns, a Helvetica-class grotesque, and primary colours used as a wayfinding language rather than decoration. This is infrastructure, closer to transit signage and civic wayfinding than to SaaS marketing.

Colour tokens — light mode (authoritative, from the creative direction):

Every hue is a legend entry; no colour is used decoratively. Category colours appear as flat coded bands, rules, and 8px line markers — never as gradients. No blue or indigo anywhere — no #2563EB, #3B82F6, #4F46E5, or any blue-family action colour.

Typography. Headings and body both use Archivo — a single family with a wide weight range. Section headers and the dashboard wordmark use 700/800 with tight tracking (-0.02em) on display sizes; all labels and table headers are uppercase with +0.08em tracking. Body and data use 400/500 at 15–16px. Numbers are tabular by default. No italic, no script, no second display face — hierarchy comes from weight, scale, and horizontal rules. Forbidden: Inter, Roboto, Arial, Helvetica, Poppins, Lato, and system-ui.

Type scale (1.333 modular): 64 / 48 / 32 / 24 / 18 / 16 / 14 / 12. Display headline clamp(40px, 7vw, 96px) mobile→desktop; section headers 32px desktop / 24px mobile; table headers 12px uppercase; body 16px; metadata 14px.

Shape language. Hard edges only — zero border-radius on panels, buttons, inputs, and table cells. Structure is expressed with 1px and 2px black rules: a 2px top rule on every section, 1px horizontal rules between table rows, and 8px solid colour bars as category markers beside each record group. Buttons are rectangles with a 2px black border and a flat fill. No shadows, no blur, no rounded chips. Icons are geometric pictograms drawn on a 24px grid with 2px strokes — square, circle, triangle, arrow.

Layout. A 12-column Unigrid on a 1280px container (24px gutters, 48px outer margins), collapsing to 6 columns at 768px and 1 column at 375px. The admin dashboard is a system board, not a card gallery: a full-width black command bar at top with the wordmark, agency name, and current shift; below it a colour-coded wayfinding strip of four category lines rendered as horizontal bars with counts; then a left rail of numbered sections (01 Personnel, 02 Equipment, 03 Vehicles, 04 Other Records) and a main column of tabular record blocks. Every record row is a ruled table row — name, ID, assignment, status — with the row's category colour as an 8px left marker. Actions sit flush right as small bordered rectangles labelled EDIT and DELETE, never icon-only. Sections are separated by full-bleed 2px black rules, not cards.

Imagery. No photography and no illustration for its own sake. The visual content is the system itself: ruled tables, numbered section markers, category colour bands, geometric pictograms (badge, radio, vehicle, file), and one schematic diagram in the dashboard header — a simple line map of the four record categories radiating from a central "Records" node, drawn in 2px black strokes with each branch in its category colour. Data is the imagery.

Readable text and controls. Headlines, wordmarks, labels, numbers, and controls stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling (for example font-size: clamp(...) with its mobile size) to fit, with no other element covering any part of them. Where the direction asks for a cropped or bleeding gesture, it is carried by imagery and decoration only.

7. Signature Design Concept

The command board. The dashboard first screen is not a hero in the marketing sense — it is a command board, and it is the product's signature composition.

• Top edge: a full-bleed 96px black bar (#111111) carrying the wordmark LAW ENFORCEMENT HR in Archivo 800 uppercase, letterspaced, left-aligned at 96px scale on desktop (40px on mobile), with the agency name and date right-aligned in 14px muted-on-black.
• Directly beneath: a full-width wayfinding strip of four equal colour blocks — red #C8102E, yellow #E8B21C, green #1F6B4A, slate #3D5A6C — each holding a large tabular count (48px Archivo 700) and an uppercase category label. This strip is the page's primary navigation, not a legend.
• Below the strip: the grid opens — a numbered section rail (01 / 02 / 03 / 04) in Archivo 700 with 2px black rules between entries on the left, and the first record table (Personnel) occupying columns 4–12 as a ruled white panel with a 2px black top rule.
• No centred headline, no subtext, no button, no gradient. The composition is a colour-coded control surface read left to right like a station map.

The concept recomposes only accepted content, states, and controls: the four record families, their counts, their tables, and their add/edit/delete actions. It introduces no new behaviour, page, or destination.

8. Interaction Model & Motion Direction

Interaction Model: Static Motion Tempo: still Hero Dimensionality: flat

Landing Hero Motion Brief. The public entry's focal subject is the schematic line map of the four record categories radiating from a central "Records" node, drawn in 2px black strokes with each branch in its category colour, set beneath the full-bleed black command bar and the four-block wayfinding strip. The input→transformation→outcome thesis is: the visitor arrives at an anonymous surface → the four category branches and their colour blocks present the product's complete scope as a single readable system → the visitor understands what the product governs and selects the single bordered entry control to Login. Motion vocabulary is still-to-restrained: no decorative animation, no parallax, no scroll-linked depth. The composed first frame is the black bar with the wordmark, the four colour blocks in red / yellow / green / slate, and the schematic diagram fully drawn at rest. The reduced-motion state is identical to the composed first frame — the Landing surface carries no motion to remove.

Dashboard entrance. One purposeful entrance exists, on dashboard load: the four category bars draw their width from 0 to full over 400ms with a linear ease, then stop. Hover on a table row shifts its left colour marker from 8px to 14px instantly, with no easing. Delete opens a full-width red confirmation band that replaces the row in place — an instant state change, no bounce. Focus rings are 2px black offset 2px. With prefers-reduced-motion, the bar draw is removed and bars render at full width.

9. Non-Functional Requirements

NFR-1 — Institutional legibility. All record data must be presented in ruled tabular form with tabular figures and uppercase tracked table headers, so that add/edit/delete operations are legible at a glance. (provenance: creative direction — authoritative for presentation.) Rationale: the product is a records-of-record system; misreading a record is a material failure.

NFR-2 — Category coding consistency. The four record families must be consistently colour-coded across the wayfinding strip, the section rail, and the per-row left markers: Personnel red #C8102E, Equipment yellow #E8B21C, Vehicles green #1F6B4A, Other Records slate #3D5A6C. (provenance: creative direction.) Rationale: colour is a legend entry, not decoration; the legend must be legible in the table itself and not only in a key.

NFR-3 — No blue-family action colour. No blue or indigo may appear anywhere in the interface, including action colours. (provenance: creative direction — explicit prohibition.)

NFR-4 — Zero radius, no shadows, no gradients. Panels, buttons, inputs, and table cells use zero border-radius; no gradients, glassmorphism, frosted panels, soft shadows, or blurred surfaces are used. (provenance: creative direction — explicit prohibition.)

NFR-5 — Labelled destructive controls. EDIT and DELETE are always labelled text controls in bordered rectangles; icon-only destructive actions are not used. (provenance: creative direction — explicit prohibition.)

NFR-6 — Readable text and controls stay whole. At 375px, 768px, and 1280px, headlines, wordmarks, labels, numbers, and controls remain entirely inside the viewport and their container, wrapping or scaling to fit, with no other element covering any part of them. (provenance: creative direction — explicit constraint.)

NFR-7 — Reduced-motion compliance. With prefers-reduced-motion, the dashboard bar draw is removed and bars render at full width. (provenance: creative direction.)

NFR-8 — Durable record persistence. Personnel, equipment, vehicle, and other records persist across sessions and remain bound to the HR Administrator's identity, so that verification through Login returns the administrator to their records. (provenance: required_inference — indispensable for the accepted add/edit/delete lifecycle to be usable.)

NFR-9 — Single-actor access boundary. The protected destinations (admin dashboard, Personnel, New Personnel, Equipment, New Equipment, Vehicles, New Vehicle, Other Records, New Other) require login; Landing and Login are anonymously reachable. No differentiated permissions, role-based visibility, or permission controls are established, because the source names exactly one administrative actor with one undivided set of capabilities. (provenance: required_inference, bounded by the explicit single-actor constraint.)

NFR-10 — Failure visibility and recovery. Every data surface must render a visible ruled error band with a retry control on load or persistence failure, and must preserve entered values on validation or persistence failure, so that no administrative work is silently lost. (provenance: required_inference — indispensable for the accepted lifecycle to be recoverable.)

10. Tech Stack

• Frontend: React with custom UI. (provenance: delivery_shape.custom_ui = true; the creative direction's grid, typography, and motion requirements are implemented directly.)
• Backend: Python / FastAPI. (provenance: requires_backend_integration = true; the accepted add/edit/delete lifecycle requires server-side persistence.)
• Storage: A relational store appropriate to durable, tabular records with four record families and per-record identity. (provenance: required_inference — NFR-8 requires durable persistence bound to the administrator's identity.)
• Identity: Application-owned identity with an invitation/provisioning bootstrap and returning verification through Login. (provenance: delivery_shape.app_owned_identity = true.)
• Containerization: Docker / docker-compose for local and single-host deployment. (provenance: [Default — not specified by user].)
• Orchestration: Kubernetes is not included; the source establishes no deployment scale or orchestration requirement. (provenance: [Default — not specified by user].)

11. Assumptions and Constraints

Constraints (explicit, binding):

• Personnel, equipment, vehicle, and other record management is performed by the admin. (explicit)
• The build proceeds page by page, beginning with the admin dashboard. (explicit)
• The admin can add, edit, and delete personnel, equipment, vehicle, and other records. (explicit)
• No blue or indigo anywhere; no gradients, glassmorphism, frosted panels, soft shadows, or blurred surfaces; zero border-radius; no icon-only destructive actions; no photography of people, stock imagery, or decorative illustration; no Inter, Roboto, Arial, Helvetica, Poppins, Lato, or system-ui. (explicit, creative direction)
• The generic indigo/blue-on-white SaaS template is forbidden for this project. (explicit)

Assumptions (narrow, labeled):

• A-1. The HR Administrator is the sole active human actor; no second role, approval chain, or permission tier exists in the current scope. (Grounded in the explicit single-actor constraint.)
• A-2. "Others" is a current record family whose specific category contents are unspecified by the source; the Other Records and New Other workspaces therefore carry a category attribute rather than a fixed category taxonomy. (Grounded in the explicit "and others" requirement; no specific adjacent module is invented.)
• A-3. Record attribute sets (name, ID, assignment, status; and the category attribute for other records) are the minimum fields needed to make the accepted add/edit/delete lifecycle usable and are marked required_inference; the source does not enumerate fields. (required_inference)
• A-4. First access is established through an agency invitation or provisioning boundary rather than self-service signup, because Login cannot own the interaction that establishes access to itself and the source establishes no public signup. (required_inference)
• A-5. The page-by-page build sequence is a delivery constraint on the current build; it does not commit the product to any specific later capability. (Grounded in the explicit sequencing constraint.)

Explicit exclusions and future horizon:

• No additional record categories, roles, modules, reporting, analytics, scheduling, or third-party integrations are accepted as current requirements.
• No provider-owned or external-destination surface owns any accepted record-management behavior.
• No headless-only delivery: the accepted work is human-facing administrative interaction.

12. Glossary

• HR Administrator — The sole active human persona and the admin named in the source; owns the complete add/edit/delete lifecycle for personnel, equipment, vehicle, and other records.
• Record family — One of the four accepted categories of records: Personnel, Equipment, Vehicles, or Other Records.
• Personnel record — A record of an agency member, carrying name, ID, assignment, and status, coded red #C8102E.
• Equipment record — A record of an agency asset item, carrying item name, ID, assignment, and status, coded yellow #E8B21C.
• Vehicle record — A record of an agency vehicle, carrying vehicle identifier, ID, assignment, and status, coded green #1F6B4A.
• Other record — A record in an additional agency category, carrying record name, ID, category, and status, coded slate #3D5A6C.
• Admin dashboard — The protected administrative landing workspace and the first page of the page-by-page build; the origin of every record-management task.
• Wayfinding strip — The four-block colour-coded navigation strip on the admin dashboard, each block carrying a live count and an uppercase category label.
• Numbered section rail — The left rail of numbered sections (01 Personnel, 02 Equipment, 03 Vehicles, 04 Other Records) with 2px black rules between entries, doubling as jump navigation.
• Category marker — The 8px solid colour bar on the left edge of a record table row, widening to 14px on hover, carrying the row's record-family colour.
• Confirmation band — The full-width red #C8102E band that replaces a table row in place on delete, containing the record name in white uppercase and two bordered actions.
• Invitation / provisioning boundary — The agency-side boundary through which the HR Administrator's identity is first established, outside the protected area.
• Unigrid — The 12-column layout system (24px gutters, 48px outer margins) collapsing to 6 columns at 768px and 1 column at 375px.