System Requirements Document for insurance-claims-myclaim

1. Introduction

MyClaim is a private, personal insurance-claims organizer. It exists so that a single person in the middle of an insurance claim — starting with auto claims — can keep every claim, document, contact, deadline, and event in one calm, legible place instead of scattered across email threads, phone photos, and paper folders.

The product is a data-driven CRUD application with file uploads, real screens, a real database, authentication, and file storage. It is not a marketing site and not a mockup. Its audience is a non-expert claimant doing paperwork late at night on a phone, who needs to feel that nothing has been lost.

MyClaim is explicitly a personal organizer. It does not file claims with insurers and does not replace official insurer portals. It records and organizes what the claimant already knows and already holds.

The data model is designed so that auto claims are supported first, while the same structure can later hold home, travel, disability, and property claims.

2. System Overview

MyClaim is a single-user-scoped web application. A person creates an account, signs in, and then works only with their own claims, contacts, documents, and timeline events. Every record belongs to exactly one account, and no user can see or edit another user's records.

The current delivery covers:

• Claims — the central record, with claim number, type, insurance company, status, dates, policy number, deductible, claim amount, notes, primary contact, next deadline, and next action.
• Contacts — adjusters, brokers, lawyers, repair shops, and other people or businesses attached to exactly one claim, with company, role, phone, email, preferred contact method, and last contacted date.
• Documents — uploaded PDF and image files attached to exactly one claim, with derived file name, type, upload date, source, and category.
• Timeline — dated events attached to exactly one claim, with event type, notes, a follow-up flag, an optional follow-up date, and an optional related contact.
• Authentication — required accounts, email/password sign-in at minimum, optional Google/Apple OAuth where available, per-user data isolation, and a simple log out action.

A claim is the hub. When a claimant opens a claim, they see that claim's related contacts, documents, and timeline events together, along with its deadlines and important dates.

2a. Product Interpretation and Delivery Boundary

MyClaim is delivered as a first-party application with its own screens, its own database, and its own file storage. Access to the working area is private: a person must have an account and be signed in before any claim, contact, document, or timeline record is visible or editable. The application is never public and never read-only.

Identity is application-owned. Because the source establishes an independently using claimant with no invitation or provisioning boundary, first use is self-service enrollment, and returning use is verification of that same account. The anonymous entry surface explains what MyClaim is and directs the person to sign in or create an account; the sign-in and sign-up surfaces are themselves reachable without an account, because a protected destination cannot own the interaction that grants access to itself.

Data ownership is strict and simple: each account sees and edits only its own records. There is no shared workspace, no team, and no differentiated role or permission tier in the current scope.

The following are outside the current delivery boundary and remain outside it:

• MyClaim does not file claims with insurers.
• MyClaim does not replace official insurer portals.
• MyClaim is not a public or read-only application.

Home, travel, disability, and property claims are supported by the data model's claim type field, but auto claims are the first target. The source states that screens and navigation will be defined in a later prompt; the current scope is the data model and authentication, delivered through the working screens described in this document.

2b. Source Content Inventory

Not applicable. No reference directive in this project declares a content_source, so no source content inventory is produced.

2c. Page Content and Component Coverage

Landing

• Information and state: Anonymous entry surface. Explains that MyClaim is a private personal insurance-claims organizer for people managing their own claims — organizing claims, storing claim-related documents, tracking deadlines and important dates, managing contacts such as adjusters, brokers, lawyers, and repair shops, and keeping a timeline of events per claim. States plainly that MyClaim does not file claims with insurers and does not replace official insurer portals.
• Primary actions: Go to sign in; go to create an account.
• Supporting actions: None beyond the two entry paths.
• Domain entities: None displayed; no claim, contact, document, or timeline data is reachable here.
• Component responsibilities: Paper-ground band with the MyClaim wordmark in VT323; a short plain-language description of the four things the app holds (claims, contacts, documents, timeline) presented as labelled drawer cards with pixel pictograms; a single accent-orange primary action; a muted line naming the insurer-portal boundary.
• States: Loading — not applicable, the surface is static. Empty — not applicable. Success — not applicable. Error — not applicable. Recovery — not applicable.

Login

• Information and state: Anonymous identity-access surface for returning verification. Email and password fields. Where available, Google and Apple OAuth options are offered here alongside email/password.
• Primary actions: Sign in with email and password.
• Supporting actions: Continue with Google; continue with Apple (only where available); navigate to create an account.
• Domain entities: The account being verified. No claim, contact, document, or timeline data is shown before verification succeeds.
• Component responsibilities: Outlined form card with 2px black outline and hard offset shadow; labelled email and password fields in Work Sans; ink-black primary button with white label that depresses 2px on press; OAuth buttons rendered as outlined rectangles, not pills; link to the sign-up surface.
• States: Loading — submit button shows a pending state while credentials are checked. Empty — fields start blank with visible labels. Success — on valid credentials the person is taken into their own claims area. Error — invalid credentials show an inline message that does not reveal whether the email exists; the form remains filled except the password. Recovery — the person can retry, switch to OAuth, or go to create an account.

Sign Up

• Information and state: Anonymous identity-access surface for first-use self-service enrollment. Collects the minimum needed to establish an account with email and password. Where available, Google and Apple OAuth enrollment is offered here.
• Primary actions: Create the account.
• Supporting actions: Continue with Google; continue with Apple (only where available); navigate to sign in.
• Domain entities: The account being created. No claim, contact, document, or timeline data exists for the account yet.
• Component responsibilities: Outlined form card matching the login surface; labelled fields in Work Sans; ink-black primary button; OAuth rectangles; link back to sign in; inline validation messaging.
• States: Loading — submit button shows a pending state while the account is created. Empty — fields start blank with visible labels. Success — the account is established and the person arrives in their own empty claims area, which shows the empty-drawer state. Error — an already-used email or a rejected password shows an inline message and preserves entered values. Recovery — the person can correct the field, retry, or switch to sign in.

Claims

• Information and state: Authenticated browse and management destination for the signed-in person's own insurance claims. Lists each claim with its claim number, claim type, insurance company, status, date opened, next deadline, and next action. Live count of claims is shown on the drawer label. Empty state is a large pixel illustration of an empty drawer with the message that no claims exist yet.
• Primary actions: Create a new claim; open an existing claim.
• Supporting actions: Edit a claim; delete a claim; filter or scan by status; sign out.
• Domain entities: Claims, with their claim type, status, insurance company, dates, deductible, claim amount, policy number, notes, primary contact, next deadline, and next action.
• Component responsibilities: Left filing rail listing the four entity drawers with pixel icons and live counts, collapsing to a 56px icon strip below 1024px and to a bottom tab bar at 375px; claim rows or cards with 2px outlines and hard offset shadows; square pixel status badges — Open (ink), In Review (mustard), Negotiating (slate blue), Closed (teal); accent-orange deadline bar carrying the nearest next deadline as a live day counter in VT323; ink-black primary button for creating a claim.
• States: Loading — claim list shows a pending state while records are fetched. Empty — empty-drawer pixel illustration with a prompt to create the first claim. Success — the created or edited claim appears in the list with its status badge and deadline. Error — a failed load or failed delete shows an inline message and leaves the list intact. Recovery — retry the action; the person can reopen the claim or recreate it.

Claim Details

• Information and state: Focused workspace for one selected claim. Renders as a physical file folder with tab-stacks across the top: Overview, Contacts, Documents, Timeline. The active tab merges into the panel below by losing its bottom border. Overview is a two-column ruled spec sheet — label in muted small caps on the left, value in ink on the right, hairline rules between rows — showing claim number, claim type, insurance company, status, date opened, date closed, policy number, deductible amount, claim amount, notes, primary contact, next deadline, and next action. A full-bleed accent-orange ruled bar spans the viewport carrying the next deadline as a live day counter in VT323. The Contacts, Documents, and Timeline tabs each show that claim's related records.
• Primary actions: Edit the claim; add a contact; upload a document; add a timeline event.
• Supporting actions: Switch tabs; open a related contact, document, or timeline event; delete a related record; sign out.
• Domain entities: One claim together with its many contacts, many documents, and many timeline events, plus its primary contact relationship.
• Component responsibilities: File-folder card with 2px black outline and hard 3px offset shadow; tab-stack header; ruled spec-sheet rows with monospace VT323 readouts for deductible and claim amount; pixel claim-type icon at 48px; square status pixel-badge; accent-orange deadline bar; per-tab content panels; pixel event dots colour-coded by event type with accent-orange follow-up flags on the Timeline tab.
• States: Loading — the claim and its related records show a pending state while fetched. Empty — each tab has its own empty state: no contacts yet, no documents yet (paperclip illustration), no timeline events yet. Success — added or edited related records appear immediately in their tab and the drawer counts update. Error — a failed load or failed related-record action shows an inline message within the affected tab and leaves the rest of the claim intact. Recovery — retry within the tab; the person can navigate back to the claims list and reopen the claim.

Claim Form

• Information and state: Focused create and edit destination for a claim's specified fields: claim number (optional), claim type (Auto, Home, Travel, Disability, Property), insurance company, status (Open, In Review, Negotiating, Closed), date opened, date closed (optional), policy number (optional), deductible amount (optional), claim amount (optional), notes (optional), primary contact (optional, chosen from the claim's contacts), next deadline (optional), and next action (optional).
• Primary actions: Save the claim.
• Supporting actions: Cancel and return without saving; choose a primary contact from the claim's existing contacts.
• Domain entities: Claims, and the Contacts relationship used for primary contact.
• Component responsibilities: Ruled spec-sheet form layout with muted small-caps labels on the left and ink values on the right; Work Sans inputs at 15–16px; VT323 monospace readouts for deductible and claim amount; pixel claim-type selector; square status pixel-badge selector; ink-black save button that depresses 2px; outlined cancel button.
• States: Loading — an existing claim's values show a pending state while fetched for editing. Empty — a new claim form starts blank with visible labels and no required-value errors until submit. Success — the claim is saved and the person returns to the claim's details or the claims list with the new values visible. Error — a failed save shows an inline message and preserves every entered value. Recovery — correct the field and save again, or cancel without losing the rest of the claim.

Contacts

• Information and state: Authenticated browse and management destination for the signed-in person's own contacts, each linked to exactly one claim. Lists name, company, role (Adjuster, Broker, Lawyer, Repair Shop, Other), phone, email, preferred contact method (Phone, Email, Text), last contacted date, and the claim each contact belongs to. Live count shown on the drawer label. Empty state uses a pixel person illustration.
• Primary actions: Add a contact; open a contact.
• Supporting actions: Edit a contact; delete a contact; scan by role; sign out.
• Domain entities: Contacts and their claim relationship.
• Component responsibilities: Filing rail with the Contacts drawer label, pixel person icon, and live count; contact cards with 2px outlines and hard offset shadows; role chips drawn from the small secondary code palette (teal, mustard, slate blue) used only as category chips; accent-orange follow-up flag where a related timeline event requires follow-up; ink-black primary button for adding a contact.
• States: Loading — contact list shows a pending state while records are fetched. Empty — pixel person illustration with a prompt to add the first contact. Success — the added or edited contact appears with its role chip and claim link. Error — a failed load or failed delete shows an inline message and leaves the list intact. Recovery — retry the action.

Contact Form

• Information and state: Focused create and edit destination for a contact's specified fields: name, company (optional), role (Adjuster, Broker, Lawyer, Repair Shop, Other), phone (optional), email (optional), preferred contact method (Phone, Email, Text, optional), last contacted date (optional), and the claim the contact belongs to.
• Primary actions: Save the contact.
• Supporting actions: Cancel and return without saving; choose the owning claim.
• Domain entities: Contacts and the Claims relationship that links each contact to exactly one claim.
• Component responsibilities: Ruled spec-sheet form layout; Work Sans inputs; pixel role selector; claim selector limited to the signed-in person's own claims; ink-black save button; outlined cancel button.
• States: Loading — an existing contact's values show a pending state while fetched for editing. Empty — a new contact form starts blank with visible labels. Success — the contact is saved and appears in the contacts list and on its claim. Error — a failed save shows an inline message and preserves entered values. Recovery — correct the field and save again, or cancel.

Documents

• Information and state: Authenticated document workspace for the signed-in person's own uploaded files, each linked to exactly one claim. Renders as a grid of file cards, each with a real thumbnail of the uploaded PDF or image, the derived file name, the document type (Estimate, Police Report, Settlement Offer, Receipt, Photo, Other), the upload date, the source (User, Adjuster, Repair Shop, Lawyer), the category (Estimate, Medical, Photos, Correspondence, Other), and the claim it belongs to. Live count shown on the drawer label. Empty state uses a pixel paperclip illustration.
• Primary actions: Upload a document; open a document.
• Supporting actions: Delete a document; scan by type or category; sign out.
• Domain entities: Documents and their claim relationship.
• Component responsibilities: Filing rail with the Documents drawer label, pixel paperclip icon, and live count; white 2px-outlined file cards with hard offset shadows so the person's own paperwork is the only photography in the product; coloured category chips from the secondary code palette; upload control; file cards slide in from the upload button as a 6-frame stagger, removed under reduced motion.
• States: Loading — document grid shows a pending state while records and thumbnails are fetched. Empty — pixel paperclip illustration with a prompt to upload the first document. Success — the uploaded file appears as a card with its thumbnail, type chip, and upload date, and the drawer count updates. Error — an unsupported file type, an oversized file, or a failed upload shows an inline message and leaves the grid intact. Recovery — retry the upload with a supported PDF or image.

Timeline

• Information and state: Authenticated browse and management destination for the signed-in person's own claim events, each linked to exactly one claim. Renders as a vertical ruled spine with pixel event dots colour-coded by event type. Each entry shows the date, event type (Called Adjuster, Vehicle Inspection, Submitted Documents, Received Offer, Email Sent, Other), notes, whether follow-up is required, the follow-up date, the related contact, and the claim it belongs to. Events with requires_follow_up carry an accent-orange pixel flag. Live count shown on the drawer label. Empty state uses a pixel clock illustration.
• Primary actions: Add a timeline event; open a timeline event.
• Supporting actions: Edit an event; delete an event; toggle the follow-up flag; set a follow-up date; attach a related contact; sign out.
• Domain entities: Timeline events, their claim relationship, and their optional contact relationship.
• Component responsibilities: Filing rail with the Timeline drawer label, pixel clock icon, and live count; vertical ruled spine with colour-coded pixel event dots; accent-orange follow-up flags; ruled spec-sheet detail rows; ink-black primary button for adding an event.
• States: Loading — timeline entries show a pending state while records are fetched. Empty — pixel clock illustration with a prompt to add the first event. Success — the added or edited event appears on the spine with its dot colour and follow-up flag. Error — a failed load or failed save shows an inline message and leaves the spine intact. Recovery — retry the action.

3. Functional Requirements

FR-1 — Working MVP with real screens, database, authentication, and file storage As a Claim Owner, I should use a working MyClaim MVP that is a data-driven CRUD app with file uploads, real screens, a real database, authentication, and file storage, so that I am managing real records rather than viewing a marketing site or mockup.

• Provenance: explicit
• Lifecycle: Trigger — the Claim Owner opens the application. Input — their own claim data and files. Observable result — records persist in a real database and uploaded files persist in real file storage. Access state — authenticated for all working screens. Failure/recovery — a failed persistence operation surfaces an inline error and preserves entered values. Continuation — the Claim Owner continues working with the persisted records.
• Acceptance: Claims, contacts, documents, and timeline events survive a reload; uploaded PDFs and images are retrievable after upload.

FR-2 — Organize insurance claims As a Claim Owner, I should organize my insurance claims in one place, so that I can see and manage every claim I am handling.

• Provenance: explicit
• Lifecycle: Trigger — the Claim Owner opens the claims area. Input — claim records. Observable result — a list of the Claim Owner's own claims with their key facts. Access state — authenticated. Failure/recovery — a failed load shows an inline message and leaves the list intact. Continuation — the Claim Owner opens a claim to work on it.
• Acceptance: The Claim Owner can create, view, edit, and delete their own claims.

FR-3 — Store claim-related documents As a Claim Owner, I should store claim-related documents against the right claim, so that my paperwork is not lost.

• Provenance: explicit
• Lifecycle: Trigger — the Claim Owner uploads a file. Input — a PDF or image file. Observable result — the file is stored and appears as a document card with its thumbnail, type, and upload date. Access state — authenticated. Failure/recovery — an unsupported type or failed upload shows an inline message and leaves the grid intact. Continuation — the Claim Owner opens or deletes the document later.
• Acceptance: Uploaded PDFs and images are attached to exactly one claim and remain retrievable.

FR-4 — Track deadlines and important dates As a Claim Owner, I should track deadlines and important dates, so that I do not miss something that matters.

• Provenance: explicit
• Lifecycle: Trigger — the Claim Owner sets a next deadline on a claim or a follow-up date on a timeline event. Input — dates. Observable result — the next deadline is carried on the accent-orange deadline bar as a live day counter, and follow-up events carry an accent-orange pixel flag. Access state — authenticated. Failure/recovery — a failed save shows an inline message and preserves the entered date. Continuation — the Claim Owner returns and reads the remaining days.
• Acceptance: The next deadline and follow-up dates are visible on the claim and its timeline.

FR-5 — Manage contacts As a Claim Owner, I should manage contacts such as adjusters, brokers, lawyers, and repair shops, so that I know who to reach and how.

• Provenance: explicit
• Lifecycle: Trigger — the Claim Owner adds or edits a contact. Input — name, company, role, phone, email, preferred contact method, last contacted date, and owning claim. Observable result — the contact appears with its role chip and claim link. Access state — authenticated. Failure/recovery — a failed save shows an inline message and preserves entered values. Continuation — the Claim Owner opens the contact or attaches it to a timeline event.
• Acceptance: Each contact is linked to exactly one claim and is visible from that claim.

FR-6 — Keep a timeline of events for each claim As a Claim Owner, I should keep a timeline of events for each claim, so that I have a dated record of what happened.

• Provenance: explicit
• Lifecycle: Trigger — the Claim Owner adds a timeline event. Input — date, event type, notes, follow-up flag, optional follow-up date, and optional related contact. Observable result — the event appears on the vertical ruled spine with a colour-coded pixel dot. Access state — authenticated. Failure/recovery — a failed save shows an inline message and preserves entered values. Continuation — the Claim Owner edits the event or sets a follow-up.
• Acceptance: Each timeline event is linked to exactly one claim and is visible from that claim.

FR-7 — Claims entity with the specified fields As a Claim Owner, I should have a Claims entity with id (auto), claim_number (text, optional), claim_type (text; examples: Auto, Home, Travel, Disability, Property), insurance_company (text), status (text or enum; examples: Open, In Review, Negotiating, Closed), date_opened (date), date_closed (date, optional), policy_number (text, optional), deductible_amount (number, optional), claim_amount (number, optional), notes (long text, optional), primary_contact_id (relationship to Contacts, optional), next_deadline (date, optional), and next_action (text, optional), so that each claim holds the facts I need.

• Provenance: explicit
• Lifecycle: Trigger — the Claim Owner creates or edits a claim. Input — the listed fields. Observable result — the claim stores and displays those values. Access state — authenticated. Failure/recovery — a failed save shows an inline message and preserves entered values. Continuation — the Claim Owner returns to the claim later.
• Acceptance: Every listed field is present, optional fields may be left empty, and id is generated automatically.

FR-8 — Contacts entity with the specified fields As a Claim Owner, I should have a Contacts entity with id (auto), name (text), company (text, optional), role (text; examples: Adjuster, Broker, Lawyer, Repair Shop, Other), phone (text, optional), email (text, optional), preferred_contact_method (text; examples: Phone, Email, Text, optional), last_contacted_date (date, optional), and claim_id (relationship to Claims), so that each contact holds the details I need.

• Provenance: explicit
• Lifecycle: Trigger — the Claim Owner creates or edits a contact. Input — the listed fields. Observable result — the contact stores and displays those values. Access state — authenticated. Failure/recovery — a failed save shows an inline message and preserves entered values. Continuation — the Claim Owner returns to the contact later.
• Acceptance: Every listed field is present, optional fields may be left empty, and id is generated automatically.

FR-9 — Documents entity with the specified fields As a Claim Owner, I should have a Documents entity with id (auto), file (file attachment supporting PDFs and images), file_name (text, derived from file), type (text; examples: Estimate, Police Report, Settlement Offer, Receipt, Photo, Other), upload_date (date, auto-set to today), source (text; examples: User, Adjuster, Repair Shop, Lawyer, optional), category (text; examples: Estimate, Medical, Photos, Correspondence, Other, optional), and claim_id (relationship to Claims), so that each document holds the details I need.

• Provenance: explicit
• Lifecycle: Trigger — the Claim Owner uploads a file. Input — a PDF or image plus its type, source, and category. Observable result — the document stores the file, derives file_name from the file, and sets upload_date to today automatically. Access state — authenticated. Failure/recovery — an unsupported type or failed upload shows an inline message and leaves the grid intact. Continuation — the Claim Owner opens or deletes the document later.
• Acceptance: PDFs and images are accepted, file_name is derived from the uploaded file, and upload_date is set to today without manual entry.

FR-10 — Timeline entity with the specified fields As a Claim Owner, I should have a Timeline entity with id (auto), date (date), event_type (text; examples: Called Adjuster, Vehicle Inspection, Submitted Documents, Received Offer, Email Sent, Other), notes (long text), requires_follow_up (boolean, default false), follow_up_date (date, optional), contact_id (relationship to Contacts, optional), and claim_id (relationship to Claims), so that each event holds the details I need.

• Provenance: explicit
• Lifecycle: Trigger — the Claim Owner adds or edits a timeline event. Input — the listed fields. Observable result — the event stores and displays those values, with requires_follow_up defaulting to false. Access state — authenticated. Failure/recovery — a failed save shows an inline message and preserves entered values. Continuation — the Claim Owner returns to the event later.
• Acceptance: Every listed field is present, requires_follow_up defaults to false, and id is generated automatically.

FR-11 — One-to-many relationships from Claim As a Claim Owner, I should have one Claim linked to many Contacts, many Documents, and many Timeline events, so that everything about a claim lives under that claim.

• Provenance: explicit
• Lifecycle: Trigger — the Claim Owner adds a contact, document, or timeline event. Input — the owning claim. Observable result — the record is stored under that claim and counted in the claim's drawer counts. Access state — authenticated. Failure/recovery — a failed link shows an inline message and preserves entered values. Continuation — the Claim Owner views the claim and sees all three collections.
• Acceptance: A claim can hold multiple contacts, multiple documents, and multiple timeline events.

FR-12 — Each Contact, Document, and Timeline event linked to exactly one Claim As a Claim Owner, I should have each Contact, Document, and Timeline event linked to exactly one Claim, so that records never drift between claims.

• Provenance: explicit
• Lifecycle: Trigger — the Claim Owner creates a contact, document, or timeline event. Input — the owning claim. Observable result — the record belongs to exactly one claim. Access state — authenticated. Failure/recovery — a missing or invalid claim link blocks the save with an inline message. Continuation — the record appears only under its own claim.
• Acceptance: No contact, document, or timeline event exists without exactly one owning claim.

FR-13 — See related records when viewing a Claim As a Claim Owner, I should see a claim's related Contacts, Documents, and Timeline events when I view that claim, so that I have the whole file in front of me.

• Provenance: explicit
• Lifecycle: Trigger — the Claim Owner opens a claim. Input — the selected claim. Observable result — the claim's contacts, documents, and timeline events are visible from that claim's tabs. Access state — authenticated. Failure/recovery — a failed load of one collection shows an inline message within that tab and leaves the rest of the claim intact. Continuation — the Claim Owner opens a related record or adds a new one.
• Acceptance: All three related collections are reachable from the claim view.

FR-14 — Require user accounts to access the app As a Claim Owner, I should have to sign in with a user account before I can access the app, so that my claims stay private.

• Provenance: explicit
• Lifecycle: Trigger — the Claim Owner opens a protected destination. Input — account credentials. Observable result — protected content is available only after verification. Access state — anonymous until verified, authenticated afterwards. Failure/recovery — invalid credentials show an inline message that does not reveal whether the email exists. Continuation — the Claim Owner retries, switches to OAuth, or creates an account.
• Acceptance: No claim, contact, document, or timeline data is reachable without an authenticated account.

FR-15 — Email/password login at minimum, with Google/Apple OAuth if available As a Claim Owner, I should sign in with email and password at minimum, and with Google or Apple OAuth where available, so that I can get into my own claims the way that suits me.

• Provenance: explicit
• Lifecycle: Trigger — the Claim Owner reaches the sign-in surface. Input — email and password, or an OAuth provider. Observable result — successful verification grants access to the Claim Owner's own records. Access state — anonymous entry, authenticated after success. Failure/recovery — a failed attempt shows an inline message and preserves the entered email. Continuation — the Claim Owner retries or uses another offered method.
• Acceptance: Email/password sign-in works; Google and Apple OAuth are offered where available.

FR-16 — Each user sees and edits only their own records As a Claim Owner, I should see and edit only my own Claims, Contacts, Documents, and Timeline events, so that my claim file stays mine.

• Provenance: explicit
• Lifecycle: Trigger — the Claim Owner browses or edits any record. Input — their authenticated account. Observable result — only records belonging to that account are listed, opened, or modified. Access state — authenticated. Failure/recovery — an attempt to reach another account's record is refused and the Claim Owner is returned to their own records. Continuation — the Claim Owner continues working within their own data.
• Acceptance: No record belonging to another account is visible or editable.

FR-17 — Simple Log out action As a Claim Owner, I should have a simple Log out action, so that I can end my session on a shared or borrowed device.

• Provenance: explicit
• Lifecycle: Trigger — the Claim Owner chooses Log out. Input — the log out action. Observable result — the session ends and protected content is no longer reachable. Access state — authenticated before, anonymous after. Failure/recovery — if the session cannot be ended, an inline message is shown and the Claim Owner can retry. Continuation — the Claim Owner returns to the anonymous entry surface.
• Acceptance: After logging out, protected destinations require verification again.

FR-18 — The app is not public or read-only As a Claim Owner, I should use a private personal organizer that is not public and not read-only, so that my records are both protected and fully editable by me.

• Provenance: explicit
• Lifecycle: Trigger — any attempt to reach the application. Input — none. Observable result — the application is never exposed as a public or read-only surface, and the Claim Owner's own records remain editable. Access state — authenticated for all working screens. Failure/recovery — not applicable. Continuation — the Claim Owner continues editing their own records.
• Acceptance: No public or read-only view of claim data exists.

FR-19 — MyClaim does not file claims with insurers or replace insurer portals As a Claim Owner, I should use MyClaim only as my own organizer, so that I understand it does not file claims with insurers and does not replace official insurer portals.

• Provenance: explicit
• Lifecycle: Trigger — the Claim Owner uses the application. Input — none. Observable result — the application records and organizes the Claim Owner's own information and performs no filing with an insurer. Access state — authenticated for working screens. Failure/recovery — not applicable. Continuation — the Claim Owner files anything official through their insurer's own portal.
• Acceptance: No capability submits a claim to an insurer or acts as an insurer portal.

FR-20 — Data model ready for later claim types As a Claim Owner, I should have a data model that supports auto claims first and can later hold home, travel, disability, and property claims, so that the same organizer keeps working as my claims change.

• Provenance: explicit
• Lifecycle: Trigger — the Claim Owner records a claim. Input — the claim type. Observable result — the claim type accepts Auto, Home, Travel, Disability, and Property. Access state — authenticated. Failure/recovery — not applicable. Continuation — the Claim Owner records further claims of any supported type.
• Acceptance: The claim type field accepts all five named types without schema change.

FR-21 — Self-service enrollment before protected work As a Claim Owner, I should be able to create my own account before accessing protected work, so that I can start using MyClaim without an invitation or provisioning step.

• Provenance: required_inference
• Lifecycle: Trigger — the Claim Owner has no account and chooses to create one. Input — the minimum account details, or an available OAuth provider. Observable result — an account is established and the Claim Owner arrives in their own empty claims area. Access state — anonymous entry surface, authenticated after enrollment. Failure/recovery — an already-used email or rejected password shows an inline message and preserves entered values. Continuation — the Claim Owner creates their first claim.
• Acceptance: A new account can be created without an invitation and immediately owns its own empty record set.

FR-22 — Returning verification before private records As a Claim Owner, I should verify my returning account before reaching my private claims and related records, so that my records stay bound to me.

• Provenance: required_inference
• Lifecycle: Trigger — the Claim Owner returns and reaches the sign-in surface. Input — email and password, or an available OAuth provider. Observable result — the Claim Owner's own claims, contacts, documents, and timeline events become reachable. Access state — anonymous entry surface, authenticated after verification. Failure/recovery — a failed attempt shows an inline message and preserves the entered email. Continuation — the Claim Owner resumes work on their own records.
• Acceptance: Private records are reachable only after successful verification of the owning account.

FR-23 — Records associated with the authenticated Claim Owner As a Claim Owner, I should have my Claims, Contacts, Documents, and Timeline records associated with my authenticated account, so that per-user isolation actually holds.

• Provenance: required_inference
• Lifecycle: Trigger — the Claim Owner creates any record. Input — their authenticated account. Observable result — the record is bound to that account and to no other. Access state — authenticated. Failure/recovery — a record that cannot be bound is not saved, and an inline message is shown. Continuation — the Claim Owner sees the record only within their own account.
• Acceptance: Every claim, contact, document, and timeline event carries an owning account, and queries are scoped to it.

FR-24 — PDF and image attachment support As a Claim Owner, I should attach PDFs and images to my documents, so that I can store the paperwork I actually receive.

• Provenance: required_inference
• Lifecycle: Trigger — the Claim Owner uploads a file. Input — a PDF or image. Observable result — the file is stored and rendered as a thumbnail card. Access state — authenticated. Failure/recovery — an unsupported file type or failed upload shows an inline message and leaves the grid intact. Continuation — the Claim Owner opens the document later.
• Acceptance: PDF and image files upload successfully and are retrievable.

FR-25 — End the authenticated session As a Claim Owner, I should be able to end my authenticated session, so that no one else can continue in my account.

• Provenance: required_inference
• Lifecycle: Trigger — the Claim Owner chooses Log out. Input — the log out action. Observable result — the session ends and protected content is no longer reachable. Access state — authenticated before, anonymous after. Failure/recovery — if the session cannot be ended, an inline message is shown and the Claim Owner can retry. Continuation — the Claim Owner returns to the anonymous entry surface.
• Acceptance: After the session ends, protected destinations require verification again.

4. User Personas

Claim Owner

Product context. The Claim Owner is a person managing their own insurance claims, starting with auto claims. They are not an insurance professional. They are handling paperwork in the middle of a stressful event, often late at night on a phone, and their dominant feeling is anxiety about losing track of something. They use MyClaim as a private filing cabinet for their own claim file — nothing here is shared, and nothing here is filed with an insurer.

Primary goal. To keep every claim, document, contact, deadline, and event in one place so that nothing is lost and nothing is missed.

Distinct accepted responsibilities.

• Organize insurance claims, including creating, viewing, editing, and deleting their own claims.
• Store claim-related documents by uploading PDFs and images against the right claim.
• Track deadlines and important dates, including a claim's next deadline and a timeline event's follow-up date.
• Manage contacts — adjusters, brokers, lawyers, repair shops, and others — with their company, role, phone, email, preferred contact method, and last contacted date.
• Keep a timeline of events for each claim, with event type, notes, follow-up flag, follow-up date, and an optional related contact.
• Maintain their own account: create it on first use, verify it on return, and log out when finished.

Relevant inputs and decisions.

• Which claim a new contact, document, or timeline event belongs to — every one of them is linked to exactly one claim.
• Which contact is the claim's primary contact.
• The claim's status: Open, In Review, Negotiating, or Closed.
• The claim's type: Auto, Home, Travel, Disability, or Property.
• Whether a timeline event requires follow-up, and if so, on what date.
• The document's type, source, and category.
• The contact's role and preferred contact method.

Interactions with other accepted participants. The Claim Owner is the only active human persona in this product. The adjuster, broker, lawyer, and repair shop appear as contacts the Claim Owner records and manages; they do not sign in, and they do not act in the application. The Claim Owner's own uploaded documents are the only other content in the product, and they are the Claim Owner's own files.

Observable success. The Claim Owner opens MyClaim and immediately sees the claim number, claim type, status, insurance company, next deadline, and next action for the claim they are working on, with the remaining days counted on the accent-orange deadline bar. They can reach that claim's contacts, documents, and timeline from the same view, and they can see at a glance which timeline events still need follow-up. Their records persist across sessions and remain visible only to them.

Constraints carried from the source. The Claim Owner must have an account to access the app, sees and edits only their own records, and can log out. MyClaim does not file claims with insurers and does not replace official insurer portals.

5. Core User Flows

Flow 1 — First use: create an account and record the first claim

1. The Claim Owner opens MyClaim and lands on Landing, which explains that MyClaim is a private personal insurance-claims organizer and states that it does not file claims with insurers or replace insurer portals.
2. The Claim Owner chooses to create an account and arrives at Sign Up.
3. The Claim Owner enters the minimum account details, or continues with Google or Apple where available, and submits.
4. Observable result: the account is established and the Claim Owner arrives in their own Claims area, which shows the empty-drawer state because no claims exist yet.
5. The Claim Owner chooses to create a claim and arrives at Claim Form.
6. The Claim Owner enters the claim's facts — claim number, claim type (for example Auto), insurance company, status, date opened, and any of date closed, policy number, deductible amount, claim amount, notes, next deadline, and next action — and saves.
7. Observable result: the claim appears in Claims with its status pixel-badge and its next deadline carried on the accent-orange deadline bar.
8. Continuation: the Claim Owner opens the claim to add its contacts, documents, and timeline events.

Flow 2 — Returning use: verify the account and resume work

1. The Claim Owner returns to MyClaim and arrives at Login.
2. The Claim Owner enters their email and password, or continues with Google or Apple where available, and submits.
3. Observable result: the Claim Owner's own claims become reachable and their records are exactly as they left them.
4. Failure and recovery: if the credentials are rejected, an inline message appears that does not reveal whether the email exists, the entered email is preserved, and the Claim Owner can retry, switch to an available OAuth method, or go to Sign Up.
5. Continuation: the Claim Owner opens the claim they are working on.

Flow 3 — Open a claim and read the whole file

1. From Claims, the Claim Owner opens a claim and arrives at Claim Details.
2. The claim renders as a file folder with tab-stacks across the top: Overview, Contacts, Documents, Timeline. The active tab merges into the panel below by losing its bottom border.
3. On Overview, the Claim Owner reads the ruled spec sheet — claim number, claim type, insurance company, status, date opened, date closed, policy number, deductible amount, claim amount, notes, primary contact, next deadline, and next action — with deductible and claim amount set as monospace readouts.
4. Observable result: the accent-orange deadline bar spans the viewport carrying the next deadline as a live day counter, so the Claim Owner can see at a glance how many days remain.
5. The Claim Owner switches to the Contacts, Documents, and Timeline tabs and sees that claim's related records in each.
6. Failure and recovery: if one collection fails to load, an inline message appears within that tab and the rest of the claim stays intact; the Claim Owner can retry within the tab or return to Claims and reopen the claim.
7. Continuation: the Claim Owner edits the claim, or adds a contact, document, or timeline event.

Flow 4 — Edit a claim's facts and deadlines

1. From Claim Details, the Claim Owner chooses to edit the claim and arrives at Claim Form with the claim's current values loaded.
2. The Claim Owner changes the fields that have moved on — for example the status from Open to In Review, the next deadline, or the next action — and saves.
3. Observable result: the updated values appear on Claim Details, the status pixel-badge changes colour to match the new status, and the deadline bar reflects the new next deadline.
4. Failure and recovery: if the save fails, an inline message appears and every entered value is preserved; the Claim Owner can correct the field and save again, or cancel without losing the rest of the claim.
5. Continuation: the Claim Owner returns to the claim's tabs.

Flow 5 — Record a contact for a claim

1. From Claim Details or Contacts, the Claim Owner chooses to add a contact and arrives at Contact Form.
2. The Claim Owner enters the contact's name, company, role (Adjuster, Broker, Lawyer, Repair Shop, or Other), phone, email, preferred contact method, and last contacted date, and selects the claim the contact belongs to.
3. The Claim Owner saves.
4. Observable result: the contact appears in Contacts with its role chip and claim link, and appears under that claim's Contacts tab; the drawer count updates.
5. Failure and recovery: if the save fails, an inline message appears and entered values are preserved; the Claim Owner can correct the field and save again.
6. Continuation: the Claim Owner can set this contact as the claim's primary contact, or attach it to a timeline event.

Flow 6 — Upload a document to a claim

1. From Claim Details or Documents, the Claim Owner chooses to upload a document.
2. The Claim Owner selects a PDF or image file and sets its type (Estimate, Police Report, Settlement Offer, Receipt, Photo, or Other), source (User, Adjuster, Repair Shop, or Lawyer), and category (Estimate, Medical, Photos, Correspondence, or Other), and confirms the claim it belongs to.
3. The Claim Owner submits the upload.
4. Observable result: the file appears as a white 2px-outlined card with a real thumbnail of the uploaded PDF or image, the file name derived from the file, the upload date set to today, a coloured category chip, and a hard offset shadow; the drawer count updates. The card slides in from the upload button as a 6-frame stagger, which is removed under reduced motion.
5. Failure and recovery: if the file type is unsupported or the upload fails, an inline message appears and the grid stays intact; the Claim Owner can retry with a supported PDF or image.
6. Continuation: the Claim Owner opens the document later, or deletes it if it was uploaded in error.

Flow 7 — Log a timeline event and flag a follow-up

1. From Claim Details or Timeline, the Claim Owner chooses to add a timeline event.
2. The Claim Owner enters the date, event type (Called Adjuster, Vehicle Inspection, Submitted Documents, Received Offer, Email Sent, or Other), and notes, optionally attaches a related contact, and turns on the follow-up flag with a follow-up date where something must be chased.
3. The Claim Owner saves.
4. Observable result: the event appears on the vertical ruled spine with a colour-coded pixel dot for its event type; if follow-up is required, it carries an accent-orange pixel flag and its follow-up date; the drawer count updates.
5. Failure and recovery: if the save fails, an inline message appears and entered values are preserved; the Claim Owner can correct the field and save again.
6. Continuation: the Claim Owner returns to the timeline to see which events still need chasing.

Flow 8 — Review what is due across claims

1. From Claims, the Claim Owner scans their own claims with their status pixel-badges and next deadlines.
2. Observable result: the accent-orange deadline bar carries the nearest next deadline as a live day counter in VT323, so the Claim Owner can read the remaining days without opening anything.
3. The Claim Owner opens the claim that needs attention and arrives at Claim Details.
4. On the Timeline tab, the Claim Owner identifies the events carrying accent-orange follow-up flags.
5. Continuation: the Claim Owner acts on the deadline outside MyClaim — for example by calling the adjuster — and then records the outcome as a new timeline event.

Flow 9 — End the session

1. From any authenticated screen, the Claim Owner chooses Log out.
2. Observable result: the session ends and the Claim Owner returns to the anonymous entry surface; protected content is no longer reachable.
3. Failure and recovery: if the session cannot be ended, an inline message appears and the Claim Owner can retry.
4. Continuation: the Claim Owner signs in again later through Login.

6. Visuals Colors and Theme

The creative direction is authoritative for this section. The muse is Susan Kare, and the headline is "Charming clarity: a claims file that feels like a well-labelled drawer." The register is a private filing cabinet, not a fintech dashboard: calm, legible, unglamorous, trustworthy.

Colour tokens — light mode

Secondary code palette, used only as document/contact category chips and timeline event dots, never as decoration:

Status pixel-badges are small squares, not pills: Open (ink #1B1B1B), In Review (mustard #C9A227), Negotiating (slate blue #3A5A8C), Closed (teal #2E6F5E).

No gradients anywhere. Every fill is flat. The forbidden indigo/blue-on-white SaaS template — #0057FF, #2563EB, #6366F1 and neighbours — is not used.

Typography

• Headings: VT323. Used at large sizes for the claim number, deadline counters, and section titles. Terminal-crisp, monospaced, all-caps for labels, tracking 0.02em, never below 20px so the pixel grid stays legible.
• Body: Work Sans (400/500/600) for all reading text — form fields, notes, contact details, timeline entries — at 15–16px with 1.55 line-height.
• Numbers that matter: deductible, claim amount, and days remaining are set in VT323 at display scale so they read as instrument readouts.
• Scale: 1.25 modular on a 16px base — 16 / 20 / 25 / 31 / 39 / 49 / 61. Display sizes use clamp(): claim-number hero 34px mobile → 61px desktop; section titles 22px → 25px; body 15px → 16px; metadata 13px.

Shape language

• Chunky 2px black outlines on every card, panel, and button, with 6px radii — a drawn, physical feel, not a soft-SaaS feel.
• Cards sit on the paper ground with a hard 3px offset shadow, no blur, so they look like index cards lifted off a desk.
• Iconography is the centrepiece: 24px pixel-grid pictograms for each entity and event type — a car for Auto, a house for Home, a phone for "Called Adjuster", a paperclip for Documents, a clock for deadlines, a person for Contacts — each drawn on a strict 24×24 grid with 2px strokes.
• No pill buttons. Buttons are rectangles with 2px outlines and a 2px press-down offset.

Layout

• A filing-cabinet layout. A left rail lists the four entity types as drawer labels with pixel icons and live counts; it collapses to a 56px icon strip below 1024px and becomes a bottom tab bar with the same pixel icons at 375px.
• The main column is a single 12-column grid on a 1080px max measure.
• Claim detail pages are tab-stacks (Overview / Contacts / Documents / Timeline) rendered as physical file tabs along the top edge of the card, the active tab joined to the panel below by removing its bottom border.
• Overview is a two-column ruled spec sheet: label in muted small caps on the left, value in ink on the right, hairline rules between rows.
• Documents render as a grid of file cards with a real thumbnail, type chip, and upload date.
• Timeline is a vertical ruled spine with pixel event dots colour-coded by event type and follow-up flags in accent orange.
• Everything wraps to one column at 375px.

Imagery

No photography and no stock people. The visual world is pixel pictograms, drawn category chips, and the Claim Owner's own uploaded documents — real PDF and photo thumbnails in white card frames with 2px outlines. Empty states are large pixel illustrations on the paper ground: an empty drawer for "no claims yet", a paperclip for "no documents", a clock for "nothing due". Schematic diagrams — a claim as a hub with contacts, documents, and timeline radiating out — replace marketing imagery.

7. Signature Design Concept

The open drawer.

The first screen after login is not a marketing hero — it is the Claim Owner's own open drawer. A full-width paper-ground band holds the claim-number display type in VT323 set enormous at the left, clamp(34px, …, 61px), with the claim type pixel icon at 48px above it. To its right sits a ruled spec sheet of the four facts that matter: status pixel-badge, insurance company, next deadline, and next action — label in muted small caps on the left, value in ink on the right, hairline rules between rows.

Beneath the band, a single accent-orange bar spans the viewport width carrying the next deadline as a live counter — for example "14 days — inspection due" — pinned and always readable.

Below the fold, the three entity drawers — Contacts, Documents, Timeline — sit as three outlined cards with live counts and small pixel diagrams. They are deliberately not identical hover-lift tiles: each card's outline weight, chip colour, and icon differ by entity type, so the drawer structure is legible at a glance.

The composition is asymmetric — type block left, ruled data right — and could not be mistaken for a centred SaaS headline with a blue button. It recomposes only accepted content, states, and controls: the claim's own fields, its related collections, and the deadline counter.

8. Interaction Model & Motion Direction

Interaction Model: Static (direction) Motion Tempo: restrained Hero Dimensionality: flat

Landing Hero Motion Brief

• Focal subject: the Claim Owner's own open drawer — the claim-number display type in VT323 at the left, the claim type pixel icon at 48px above it, and the ruled spec sheet of status, insurance company, next deadline, and next action at the right, with the accent-orange deadline bar spanning the viewport beneath.
• Input → transformation → outcome thesis: the Claim Owner arrives with a claim already in progress; the drawer opens on their own facts and the deadline counter resolves to the days remaining, so the outcome is "nothing has been lost, and here is what is due."
• Motion vocabulary: restrained and frame-like. 120ms linear state changes. Buttons depress 2px on press. Checkboxes flip between two drawn states. File cards slide in from the upload button as a 6-frame stagger. Tab switches cut, they do not slide. One purposeful loop only: the deadline counter increments on load.
• Composed first frame: paper ground #F4F1E8; the claim-number type block at the left in ink #1B1B1B; the 48px claim type pixel icon above it; the ruled spec sheet at the right with muted #7A7568 labels and ink values; the full-bleed accent-orange #D94F2B deadline bar beneath, already carrying the day count; the three entity drawer cards below the fold, each with its own outline weight, chip colour, and icon.
• Reduced-motion state: prefers-reduced-motion removes the stagger and the counter animation entirely. The deadline bar shows the final day count as static text, file cards appear in place without sliding, and every readable label, number, and control remains whole and fully visible.

No 3D or WebGL scene is required or requested for this project; hero dimensionality is flat.

9. Non-Functional Requirements

NFR-1 — Private by default. The application requires user accounts to access it and is never public and never read-only. Provenance: explicit. Rationale: the source states this is a private personal organizer and explicitly forbids a public or read-only application.

NFR-2 — Per-user data isolation. Each user can only see and edit their own Claims, Contacts, Documents, and Timeline events. Provenance: explicit. Rationale: the source states this as a hard constraint, and it is the basis of the product's privacy promise.

NFR-3 — Real persistence. Claims, contacts, documents, and timeline events are stored in a real database, and uploaded files are stored in real file storage, so records survive reloads and sessions. Provenance: explicit. Rationale: the source requires a real database and file storage, not a mockup.

NFR-4 — PDF and image support. Document storage accepts PDF and image file attachments. Provenance: explicit. Rationale: the source specifies PDFs and images as the supported attachment types.

NFR-5 — Automatic values. A document's upload_date is auto-set to today, file_name is derived from the uploaded file, and a timeline event's requires_follow_up defaults to false. Provenance: explicit. Rationale: the source specifies these as automatic or defaulted values.

NFR-6 — Referential integrity. Each Contact, Document, and Timeline event is linked to exactly one Claim, and a Claim may have many of each. Provenance: explicit. Rationale: the source specifies these relationships directly.

NFR-7 — Readable text and controls at every viewport. Headlines, wordmarks, labels, numbers, card text, and controls stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling to fit, with no other element covering any part of them. Provenance: explicit (creative direction). Rationale: the direction requires this and it takes precedence over any cropping gesture, which is carried by imagery and decoration instead.

NFR-8 — Reduced-motion support. Under prefers-reduced-motion, the file-card stagger and the deadline counter animation are removed entirely, and a usable static arrangement is provided. Provenance: explicit (creative direction). Rationale: the direction specifies this behaviour.

NFR-9 — No gradients, no forbidden palette. Every fill is flat; the indigo/blue-on-white SaaS template is not used. Provenance: explicit (creative direction). Rationale: the direction forbids gradients and names the forbidden palette.

NFR-10 — Session termination. The application provides a way to end the authenticated session. Provenance: required_inference. Rationale: the source requires a simple Log out action, which is only meaningful if the session can actually be ended.

10. Tech Stack

The source does not name a technology stack. The following are coherent defaults, labelled as such.

• Frontend: React — a data-driven CRUD application with real screens, file uploads, and a filing-cabinet layout with a collapsible rail and tab-stacks. [Default — not specified by user]
• Backend: Python with FastAPI — a real database-backed API with authentication and file upload endpoints. [Default — not specified by user]
• Database: A relational store suited to the specified one-to-many relationships (Claims → Contacts, Documents, Timeline) with per-user scoping. [Default — not specified by user]
• File storage: Object or filesystem storage for uploaded PDFs and images, with thumbnails for the document grid. [Default — not specified by user]
• Authentication: Email/password at minimum, with Google and Apple OAuth where available, as the source specifies.
• Containerization: Docker and docker-compose for local and deployment parity. [Default — not specified by user]
• Orchestration: Kubernetes is not required by the source and is not included. [Default — not specified by user]

11. Assumptions and Constraints

Constraints (binding)

• User accounts are required to access the app.
• Each user can only see and edit their own Claims, Contacts, Documents, and Timeline events.
• The app is not public and not read-only; it is a private personal organizer.
• MyClaim does not file claims with insurers and does not replace official insurer portals.
• For now, the focus is the data model and authentication; screens and navigation were to be defined in a later prompt.
• The app is a data-driven CRUD application with file uploads, with real screens, a real database, authentication, and file storage — not a marketing site and not a mockup.
• Auto claims are the first target; the data model is designed so it can later support home, travel, disability, and property claims.

Assumptions

• A-1. The Claim Owner is the only active human persona. Adjusters, brokers, lawyers, and repair shops are recorded as contacts; they do not sign in and do not act in the application. (Source-backed: the source names these as contact roles, not as users.)
• A-2. Identity is application-owned and self-service, because the source establishes an independently using claimant with no invitation or provisioning boundary. (required_inference)
• A-3. The sign-in and sign-up surfaces are reachable without an account, because a protected destination cannot own the interaction that grants access to itself. (required_inference)
• A-4. Google and Apple OAuth are offered only where available; email/password is the guaranteed minimum. (Source-backed.)
• A-5. There is no differentiated permission tier, shared workspace, or team in the current scope. Every account has full control of its own records and no access to any other account's records. (Source-backed: the source specifies per-user isolation only.)
• A-6. The claim type field accepts Auto, Home, Travel, Disability, and Property as named examples; the field is text, so further values are not excluded. (Source-backed.)
• A-7. Status accepts Open, In Review, Negotiating, and Closed as named examples; the field is text or enum. (Source-backed.)
• A-8. Document type, source, and category, and contact role and preferred contact method, accept the named examples as values. (Source-backed.)
• A-9. Timeline event type accepts Called Adjuster, Vehicle Inspection, Submitted Documents, Received Offer, Email Sent, and Other as named examples. (Source-backed.)
• A-10. The visual direction in Sections 6–8 is authoritative for presentation and does not add product behaviour, personas, or destinations. (Source-backed: creative direction.)

12. Glossary

• Claim — The central record in MyClaim. Holds claim number, claim type, insurance company, status, dates, policy number, deductible amount, claim amount, notes, primary contact, next deadline, and next action. One claim has many contacts, many documents, and many timeline events.
• Claim Owner — The single active human persona: a person managing their own insurance claims, starting with auto claims, who signs in with their own account and sees only their own records.
• Claim type — The kind of claim: Auto, Home, Travel, Disability, or Property. Auto is the first target; the model is designed to hold the others later.
• Contact — A person or business attached to exactly one claim: an adjuster, broker, lawyer, repair shop, or other. Holds name, company, role, phone, email, preferred contact method, and last contacted date.
• Document — An uploaded PDF or image attached to exactly one claim. Holds the file, a file name derived from the file, a type, an upload date set to today, a source, and a category.
• Timeline event — A dated entry attached to exactly one claim. Holds the date, event type, notes, a follow-up flag defaulting to false, an optional follow-up date, and an optional related contact.
• Primary contact — The contact a claim designates as its main point of contact, referenced by the claim's primary_contact_id.
• Next deadline — The claim's next important date, carried on the accent-orange deadline bar as a live day counter.
• Follow-up flag — The requires_follow_up boolean on a timeline event. When true, the event carries an accent-orange pixel flag and may carry a follow-up date.
• Status — The claim's current state: Open, In Review, Negotiating, or Closed, shown as a square pixel-badge.
• Drawer — The filing-cabinet metaphor for the four entity types — Claims, Contacts, Documents, Timeline — listed in the left rail with pixel icons and live counts.
• Deadline bar — The full-bleed accent-orange ruled bar spanning the viewport on claim screens, carrying the next deadline as a live day counter in VT323.
• Spec sheet — The ruled label/value display used for claim facts: label in muted small caps on the left, value in ink on the right, hairline rules between rows.
• Pixel pictogram — A 24×24 pixel-grid icon drawn with 2px strokes, one per claim type, contact role, document type, and timeline event type, reused at 48px as an empty-state illustration.