6.4— Capture Audit Log of Approve/Reject Decisions (MVP)

**Priority (MoSCoW):** Must
**Persona:** Registry Analyst (staff-only)
**Value:** Ensure accountability by recording who made the decision, when, and what action was taken.

---

## User Story
As a **registry analyst**, I want the system to **automatically record who approved or rejected a filing request with a date and time stamp**, so that **there is an auditable history of final decisions**.

## Context
- **Where:** Filing request detail (staff-only).
- **Before:** Analyst has chosen Approve or Reject.
- **After:** The system records user ID, decision, and timestamp in an audit log. This record is not visible to filers.
- **Policy fit (BA to confirm):**
- Manufactured Home Act — s.8: Registrar may receive or refuse to file; decisions must be recorded.
**How this story meets it:** Provides evidence of registrar’s decision.

## UX/UI Link (Design-owned)
https://www.figma.com/design/rbiPKU4yAW8PqDDjFRBVKQ/Intake-Queue?node-id=2681-6069&t=gFl0H52GL9lPMPcK-4

## Sprints
|
---

## MVP Boundary (story-level; PO-owned)
- **In:** Capture user ID, decision (Approved/Rejected), and timestamp.
- **Out:** Advanced reporting, change history viewer, or public visibility of audit records.

---

## Acceptance Criteria (PO-owned; user-observable)
- [ ] When a filing is Approved or Rejected, the system records:
- [ ] Analyst ID (who made decision)
- [ ] Decision taken (Approve/Reject)
- [ ] Timestamp (date + time)
- [ ] Audit record is staff-only (not visible to filer).
- [ ] **Accessibility:** Audit information is accessible to staff via keyboard, visible focus, AT announcement.
- [ ] **Unavailable:** If audit log cannot load, display plain-language, non-blocking “Unavailable” message (BA wording).

---

## BA Section (Required before Dev)
*(BA responsible, Design consulted — SM enforces DoR)*

### Definition of Ready — BA gate
- [x] **BA — please cover completed** (rules, errors, edge cases, authoritative sources, policy refs)
- [x] Edge cases table filled
- [x] Draft Gherkin (happy path + key errors)
- [x] Policy refs confirmed & linked in Context
- [ ] Ticket reviewed with Design (labels/states aligned; Design confirms readiness)
- [ ] UX/UI link pasted (Design)

---

### Business and Validation Rules

**BUSINESS RULES**
1. Decision Recording
- When a filing request is approved or rejected, the system must record:
- Analyst ID (who made the decision)
- Decision taken (Approve or Reject)
- Timestamp (date and time)
- This record must be immutable and stored in an audit log.
2. Visibility
- Audit records are staff-only and must not be visible to filers (the QS).
3. Compliance
- Decisions must comply with the Manufactured Home Act, which requires registrar decisions to be recorded.
4. Approval Actions
- Approval finalizes the registration.
- A verification statement must be generated and stored in the DRS.
- Payment must be processed if not already collected.
- Submission status changes to "Completed" and is removed from the active queue.
- The QS must be notified via email.
5. Rejection Actions
- Rejection requires a reason (template or custom).
- A rejection letter must be generated and stored in DRS.
- QS must be notified with the reason and resubmission instructions in accordance with provisions in policy.
- Refunds must be issued if pre-paid.
- Submission status changes to "Rejected" and is archived.
6. Communication
- All notifications (approval, rejection, pending) must be sent to QS.
- Staff must be notified when QS resubmits or updates a pending submission.
- All communication must be logged within the submission record.

**VALIDATION RULES**
1. Approval Preconditions
- All required documents must be present, complete, and valid.
- Submission information must match existing MHR registration.
- Payment must be pre-authorized or ready for processing.
2. Rejection Preconditions
- Submission is incomplete or contains errors.
- Supporting documents are invalid, outdated, or non-compliant.
- Submission does not meet MHR policies or legislation.
3. System Behavior
- Approval must trigger:
- Generation and storage of verification documents.
- Payment processing.
- Notification dispatch.
- Rejection must trigger:
- Logging of rejection reason and timestamp.
- Generation and storage of rejection letter.
- Notification dispatch.
4. Audit Log Accessibility
- Audit information must be accessible to staff via keyboard navigation, visible focus, and assistive technology announcements.

### **ERROR MESSAGES**
If Audit Log Fails to Save
- _“The decision could not be recorded due to a system error. A retry may be required.”_
- _“The audit record was not created. No changes have been applied.”_
- _“The decision was not finalized because the audit entry could not be saved.”_

If Audit Log Fails to Display
- _“The audit history is currently unavailable. Other functions remain unaffected.”_
- _“The decision record could not be loaded. A refresh or later attempt may be necessary.”_
- _“The audit log could not be displayed. This does not prevent ongoing work.”_

### Constraints
Immutability
- Once an audit record is created, it cannot be modified or deleted.
- Any attempt to alter must be rejected at the API and UI level.

Access Control
- Audit logs must be visible only to authorized staff.
- Filers must never see audit entries.

Mandatory Fields
- Analyst ID, decision action, and timestamp are required for every audit entry.
- Records missing any of these fields must not be saved.

### Edge cases
| Edge case | What triggers it | What the user sees | Can they continue? |
|-----------|------------------|--------------------|--------------------|
| Audit log cannot save | System error at time of decision | Plain-language “Audit record could not be saved. Please try again.” | No — analyst must retry decision |
| Audit log cannot load | Connectivity issue | “Audit records Unavailable — you can continue working.” | Yes |

---
### Non-Functional Requirements (NFRs)

Availability
- System should display a non-blocking “Unavailable” message if audit log fails to load.
- Other staff actions must remain unaffected during downtime.

Security
- All audit data must be encrypted at rest and in transit.
- Sensitive identifiers must be masked in staff view where applicable.

Accessibility
- Audit log must support keyboard navigation, visible focus, and screen reader announcements.

Compliance
- Must meet BC Manufactured Home Act Section 8 requirement to record decisions.
- Retention policy: Audit records must be stored for a minimum of 7 years (or as per corporate policy).

Reliability
- System must ensure idempotent writes (e.g., double-click or retry does not create duplicates).
- In case of partial failure (e.g., payment succeeds but audit write fails), system must raise an incident and lock the submission for review.

Auditability
- Each audit entry must include correlation IDs for traceability across UI and backend processes.

### Acceptance Criteria
Scenario: Create audit record after decision (Happy Path)
Given an analyst is authenticated
And a filing request is open
When the analyst confirms Approve or Reject
Then the system creates an audit record
And the audit record includes analyst ID
And the audit record includes decision action
And the audit record includes timestamp
And the audit record is immutable

Scenario: Restrict audit log visibility to staff
Given a user attempts to view the audit log
When the user is not staff
Then the audit log is not displayed
And the system shows an access denied message

Scenario: Display message when audit log cannot load
Given staff attempts to view the audit log
And the audit log fails to load
Then the system displays the message "Audit history is unavailable"
And the message is non-blocking
And staff can continue other tasks

Scenario: Validate mandatory fields in audit record
Given the system creates an audit record
When any of the fields (analyst ID, decision action, timestamp) is missing
Then the system rejects the record
And the system logs an error for review

### BA Notes
**Concurrency**
This should not be an issue since the business rules from epic 5 enforces read-only status for non-assignees. It should therefore not be possible for 2 analysts to approve/reject a ticket at the same time.

**Compliance Statement: Audit Logging Requirement**
Under Section 8 of the BC Manufactured Home Act, the registrar is authorized to receive or refuse to file a document, and decisions must be recorded. This legislative requirement establishes the need for an auditable record of filing decisions to ensure accountability and transparency. To comply with this provision, the system must capture and store an immutable audit entry for each filing decision. Each audit entry must include:

- Registrar or analyst identifier (who made the decision)
- Decision outcome (Approve or Reject)
- Timestamp (date and time of decision)

Audit records must be retained in a secure, staff-only log and remain inaccessible to filers.
The audit log must support accessibility standards for staff and provide clear fallback messaging if unavailable.
This feature ensures that the registrar’s decision-making process is documented in accordance with statutory obligations and supports operational integrity.

### Policy references
- Manufactured Home Act — s.8 & 10: Registrar may receive or refuse; record must show decision. [Link](https://www.bclaws.gov.bc.ca/civix/document/id/complete/statreg/00_03075_01#section8)
- Manufactured Home Regulation — s.3: Proof of information in records submitted. [Link](https://www.bclaws.gov.bc.ca/civix/document/id/complete/statreg/441_2003#section3)

---

## Design — Prompts
- Confirm exact placement of audit log visibility.
- Ensure accessibility basics (keyboard path, focus, AT announcements).
- Paste design link above.