9.1 — Document AI runs on uploaded MHR documents (MVP)

**Priority (MoSCoW):** Must
**Persona:** Registry Analyst
**Value:** Ensure that every uploaded document in an MHR filing request is automatically checked for authenticity, so analysts can trust that tampering detection has been performed before review.

---

## User Story
As a **registry analyst**,
I want **Document AI to automatically scan every uploaded MHR document**,
So that **I can be confident each filing request includes documents that have been validated for authenticity**.

## Context
- **Where:** Document Registry Service (DRS), at the point of upload for MHR filing requests.
- **Purpose:** Build analyst confidence that uploaded documents are validated as part of the MHR workflow.
- **Flow:** Filer uploads → Document AI runs → Result stored for later display in analyst view.
- **Policy fit (BA to confirm):**
- Manufactured Home Regulation — s.3: Registrar may require proof of information contained in a record.
**How this story meets it:** AI validation supports proof requirements by checking integrity of uploaded documents.

## UX/UI Link (Design-owned)
_TBD — Design to paste after BA review is complete._

## Sprints
| Role (icon + text) | Forecasted (PO-planned) | Actual (post-planning) |
|:-------------------|:-------------------------------|:-------------------------------|
| 🧭 PO | Sprint __ (________–________) | Sprint __ (________–________) |
| 📌 BA | Sprint __ (________–________) | Sprint __ (________–________) |
| 🎨 Design | Sprint __ (________–________) | Sprint __ (________–________) |
| 💻 Dev | Sprint __ (________–________) | Sprint __ (________–________) |

---

## MVP Boundary (story-level; PO-owned)
- **In:**
- Trigger Document AI automatically on every uploaded MHR document.
- Secure storage of original documents in DRS (unaltered).
- Store AI result (flag/score) internally for later display.
- **Out:**
- Showing results to analysts (covered in 9.2).
- Visual tampering heatmaps or highlights (future).

---

## Acceptance Criteria (PO-owned; user-observable)
- [ ] Every MHR document uploaded through DRS is processed by Document AI.
- [ ] Original documents are preserved in DRS with no alteration.
- [ ] AI validation result (flag/score, timestamp) is stored against the document record.
- [ ] **Accessibility:** Process is invisible to filer; no impact on upload flow.
- [ ] **Unavailable:** If AI service is unavailable, upload still succeeds with a plain-language log entry (“Validation service temporarily unavailable; document stored unvalidated”).

---

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

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

---

**BA — please cover**
- [ ] Business & validation rules (plain language)
- [ ] Error wording users should see + edge cases (incl. **Unavailable**)
- [ ] **Unavailable wording:** plain-language, non-blocking message
- [ ] Data & authoritative sources (e.g., FOIPPA-compliant storage)
- [ ] Constraints/NFRs (performance, availability, audit) if relevant
- [ ] Check with Design on accessibility basics (Design owns the HOW)
- [ ] Policy references (MHA/MHR Reg/FOIPPA) if applicable — see below

**Policy references (BA to confirm)**
- Manufactured Home Act — s.8: Registrar may require supporting documents. Link: https://www.bclaws.gov.bc.ca/civix/document/id/complete/statreg/03075_01
- Manufactured Home Regulation — s.3: Proof of information in a record may be required. Link: https://www.bclaws.gov.bc.ca/civix/document/id/complete/statreg/96_2004
- FOIPPA — s.30.1: Personal information must be stored and accessed only in Canada unless permitted by regulation. Link: https://www.bclaws.gov.bc.ca/civix/document/id/complete/statreg/96165_00

**BA Prompts (things to think about)**
- What is the **minimum validation output** we need to store (flag only, or flag + score)?
- What should be logged if the Document AI service fails or times out?
- Do we need to differentiate between **AI unavailable** vs. **AI flagged tampering**?
- Which authoritative source governs whether a document is valid if AI is inconclusive?
- Should analysts be able to see the raw AI score later, or just a binary flag?

---

### BA — Edge cases
| Edge case | What triggers it | What the user sees | Can they continue? |
|-----------|------------------|--------------------|--------------------|
| AI unavailable | AI service is down or times out | “Validation service temporarily unavailable; document stored unvalidated.” (staff log) | Yes |
| False positive | AI flags tampering where none exists | Stored as “Flagged” internally; surfaced to analyst in 9.2 | Yes |
| False negative | AI fails to detect tampering | Stored as “Validated” internally; surfaced to analyst in 9.2 | Yes (analyst can still review manually) |

---

### BA — Gherkin (to draft before Dev)
- [ ] **Happy path:** Uploaded document is processed, AI returns result, result stored.
- [ ] **AI unavailable:** Upload still succeeds, status logged as “unvalidated.”
- [ ] **Tampering flagged:** Upload succeeds, AI result stored as “Flagged.”

---

No source files, tests, or entry points are named. Start by locating the Document Registry Service upload flow and the document-record persistence boundary, then confirm the Document AI integration and failure handling requirements with the unfinished BA and design sections. Done means every MHR upload is stored unaltered, receives a persisted AI result or unvalidated status, and does not block upload.

Written by the indexing model from the issue text.