6.3 Capture Point-in-Time Record of Rejected Request (MVP)

**Priority (MoSCoW):** Must
**Persona:** Registry Analyst
**Value:** Ensure that when a filing request is finalized (Approved or Rejected), the system stores the complete request exactly as submitted, so there is a reliable historical record of what was filed at that moment.

---

## User Story
As a **registry analyst**, I want the system to **capture the filing request as-is whenever I approve or reject it**, so that **there is a permanent point-in-time record for audit, history, and accountability**.

## Context
- **Where:** Filing request detail screen.
- **Before:** Analyst has chosen Approve or Reject.
- **After:** Filing request is locked; captured “as-is” state is stored and cannot be altered.
- **Policy fit (BA to confirm):**
- Manufactured Home Act — s.8: Registrar may receive or refuse to file; decision must be recorded.
**How this story meets it:** Preserves evidence of registrar’s decision.

## UX/UI Link (Design-owned)
no designs needed

## MVP Boundary (story-level; PO-owned)
- **In:** Lock and capture the full filing request state at decision (Approve or Reject).
- **Out:** Advanced versioning, diff tools, or public access to captured records.

---

## Acceptance Criteria (PO-owned; user-observable)
- [ ] When a filing request is Approved, the system stores the request “as-is” at that moment.
- [ ] When a filing request is Rejected, the system stores the request “as-is” at that moment.
- [ ] Captured records are immutable and staff-only.
- [ ] Filers cannot edit captured records — only resubmit with a new request if rejected.
- [ ] **Accessibility:** Staff can navigate captured record with keyboard, visible focus, and AT announcements.
- [ ] **Unavailable:** If capture cannot complete, display plain-language, non-blocking 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
- [x] Ticket reviewed with Design (labels/states aligned; Design confirms readiness)
- [ ] UX/UI link pasted (Design)

---
### Business and Validation Rules

#### Business Rules

- Point‑in‑time capture: The system stores the full request state exactly as submitted when staff approves or rejects the filing. The captured record is immutable and staff‑only. Filers cannot edit the captured record, they submit a new request if rejected.
- Approval prerequisites: Staff approves only when all required documents are present and valid, submission data matches the existing registration, and payment is authorized or ready to process.
- Approval outcomes: On approval, the system finalizes the registration, generates a verification statement, stores it in DRS, sends the verification to the QS by email, processes payment if not previously collected, and removes the submission from the active queue as Completed.
- Rejection prerequisites: Staff rejects when the submission is incomplete, contains errors, the documents are invalid or outdated, or the submission does not comply with policy or legislation.
- Rejection outcomes: On rejection, staff selects a reason from a template or writes an explanation. The system generates a rejection letter, stores it in DRS, emails the QS with the reason and resubmission instructions, does not process payment or initiates refund if pre‑paid, and marks the submission as Rejected and archived.
- Payment rules: Rejected submissions are **never** charged. Refunds are initiated when payment was collected before rejection. If payment fails post‑approval, the submission remains in Payment Pending until resolved.
- Notification rules: The QS receives email notifications for all status changes, including approved, rejected, and pending. Staff receives a notification when the QS resubmits or updates a pending submission.
- Communication logging: All outbound communications and relevant notes are logged and accessible within the submission record.
- Accessibility for staff: Staff must navigate the captured record with keyboard, visible focus, and assistive technology announcements.
- Capture failure behavior: If capture is unavailable, the system displays a plain‑language, non‑blocking message for staff.

#### Validation Rules

- Data validation rules enforce the prerequisites and outcomes above.
- Required documents presence: Before approval, the system validates the presence of all required documents. Missing documents block approval and prompt staff to reject or request updates.
- Document validity: Documents must be current and meet legal requirements. Invalid or outdated documents block approval and require rejection or correction.
- Data consistency: Submission fields must match the existing registration records. Mismatches block approval and surface errors for staff review.
- Payment readiness: Approval requires a valid payment state: pre‑authorized, collected, or ready to process. If payment is not in a valid state, approval is blocked or set to Payment Pending until resolved.
- Rejection reason requirement: On rejection, a reason must be selected from a template or provided as a custom explanation. The reason and timestamp are mandatory in the log.
- DRS storage checks: On approval or rejection, the verification statement or rejection letter must be generated and stored in DRS, with a storage confirmation recorded in the submission log.
- Immutable capture lock: After decision, the captured as‑is request is locked. Any attempt to edit the captured record fails validation and directs the filer to submit a new request.
- Notification delivery: Status changes must queue and send email notifications to the QS. Failures are logged and retried. Staff resubmission updates must trigger staff notifications.
- Accessibility checks: Captured record views must pass keyboard navigation and focus visibility checks. Screen reader announcements are required for key actions.
- Capture failure handling: If the capture step fails, display a clear, non‑blocking message and log the incident for follow‑up.

#### System Behaviors

- One‑click approval with a confirmation prompt. The action triggers document generation, DRS storage, payment processing, and notification dispatch.
- Rejection uses templates with editable fields, supports attaching annotated documents or notes, and logs reason plus timestamp.
- Submissions move to Completed on approval and to Rejected and archived on rejection.

### Error wording
Capture not completed:
_The system could not save the filing request at this time. Your decision has not been finalized. Please try again or contact support if the issue continues_
Capture unavailable:
_The system cannot save the filing request right now. Your decision is still in progress. You can continue working or try again later._

### Constraints / NFRs
**Minimal Storage Footprint**
- The system must store captured filing requests efficiently to minimize storage usage.
- No advanced versioning or diff tools are included in scope.

**Immutable Record**
- Once a filing request is captured at the point of decision (Approve or Reject), it must be locked and cannot be altered.
- Filers cannot edit captured records; they must submit a new request if changes are needed.

### 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)

**BA Prompts (things to think about)**
- Should both Approved and Rejected records be stored in the same format/location?
- Should supporting documents be locked alongside the request?
- Who can view captured records (all analysts, or just assigned)?
- What happens if two analysts attempt final decision simultaneously?
- How does this interact with the audit log (Story 6.4)?

---

### BA — Edge cases
| Edge case | What triggers it | What the user sees | Can they continue? |
|-----------|------------------|--------------------|--------------------|
| Capture fails | System error | “Could not save record of filing request. Please try again.” | No — analyst must retry decision |
| Record locked | Analyst or filer attempts to edit after decision | “This request is locked because it has been finalized.” | No |

---

### Acceptance Criteria
Happy path 1 (Approve)
Scenario: Analyst approves and the system captures and locks the request
Given all required documents are present and valid
And submission data matches the registration
And payment is authorized or ready to process
When the analyst selects Approve and confirms
Then the system captures the request as-is at decision time
And the captured record becomes immutable
And the registration is finalized
And a verification statement is generated and stored in DRS
And the QS receives the verification by email
And the submission status changes to Completed

Happy path 2 (Reject)
Scenario: Analyst rejects and the system captures and locks the request
Given the submission is incomplete, has errors, invalid documents, or policy noncompliance
When the analyst selects Reject and provides a reason
Then the system captures the request as-is at decision time
And the captured record becomes immutable
And a rejection letter is generated and stored in DRS
And the QS receives the rejection reason and resubmission instructions by email
And payment is not processed or a refund is initiated if pre-paid
And the submission status changes to Rejected and archived

Scenario: Captured record is viewable by staff only
Given the system captured the request
When a staff user opens the captured record
Then the system grants access
And the system denies access to non-staff users

Scenario: Capture is temporarily unavailable and the system shows an Unavailable message
Given the analyst attempts to capture the request
When the capture service is unavailable
Then the system displays a plain-language, non-blocking message labeled "Capture unavailable"
And the message states the decision is still in progress and the user can continue working or try again later
And the incident is logged for follow-up

Scenario: The system saves the full state of the request
Given the analyst makes a decision on the submission
When the system performs capture
Then the system stores all fields in the submission at decision time
And the system stores all attached documents with their identifiers in DRS
And the system records the decision timestamp, staff user ID, and decision type
And the system records notification events and delivery status
And any attempt to edit the captured record fails and prompts the filer to submit a new request

---

## Design — Prompts
- Confirm placement or access path for captured record.
- Ensure accessibility basics (keyboard path, focus, AT announcements).
- Paste design link above.