Workers-Comp FNOL Copilot

Every workers'-compensation claim begins with a First Notice of Loss — the moment an injured employee, their supervisor, and HR must capture what happened and how serious it is. In most employers and TPAs today that process is slow, inconsistent, and scattered across phone calls, paper forms, email threads, and siloed systems, driving delayed care routing, adjuster rework, compliance risk, and a poor experience for workers already reporting an injury under stress.

Build a purpose-built intake and triage layer — not a generic chatbot, not a full claims system — that lets injured workers, supervisors, HR, safety, and downstream TPAs converge on one canonical incident record, while keeping structured fields, validation, and triage scoring rule-based and explainable even where AI assists the conversation.

• Multi-party workflow: injured workers, supervisors, HR, safety, and TPAs each need different screens, permissions, and obligations
• Injury, medical, and employment data demand tenant isolation, auditability, and guardrails against AI overreach (no medical or legal advice)
• Workers report from the floor, not a desk — drafts must survive connectivity gaps and sync safely
• FNOL must leave the building as a canonical JSON payload to carrier/TPA systems with idempotency, retries, and full submission history

A mobile-first PWA where deterministic intake graphs guide injured workers step-by-step, with an optional empathetic AI batch chat that extracts multiple fields per message; supervisors contribute via secure invite links without full account setup. An HR/operations portal adds structured verification, completeness scoring, rule-based triage tiers, an incident inbox, and FNOL submission readiness, backed by Supabase Postgres, Auth, RLS, Edge Functions, and Storage with a shared TypeScript domain layer.

• Next.js PWA for mobile-first worker and supervisor intake
• Supabase Postgres with row-level security on every tenant table, Auth, Edge Functions for privileged writes, and private attachment storage
• Shared TypeScript domain layer with Zod schemas so triage rules, completeness logic, and FNOL payload builders have a single source of truth
• Append-only audit events and per-account integration configs for notification orchestration

• Triage scoring, validation, and completeness gates stay rule-based and explainable — AI phrases the questions, but never scores the injury
• Treated multi-tenant row-level security as a first-migration design choice, not pre-launch hardening
• Gave supervisors a secure invite-link path instead of requiring full account provisioning, to keep the pilot frictionless
• Ran a pre-deployment security review that hardened tenant assignment, scoped incident reads, protected internal APIs, and idempotent completion paths

• The conversation is UI; the incident record is truth — every critical value must map to typed fields, validation, review screens, and audit logs
• Empathy and control are not opposites — plain-language batch guidance for workers and auditable triage reasoning for operators can both be first-class
• Multi-tenant security is a design choice, not a final hardening step — account scoping and RLS belong in the first migration
• Duplicated triage rules and payload builders are a compliance and maintenance risk — regulated workflows need a single source of truth
• Pilot realism accelerates adoption — running real worker/supervisor/HR identities end-to-end exposed auth, notification, and retry gaps early