`docs/00-thesis-and-guardrails.md`

71 lines
# Thesis & Guardrails

## The thesis in one paragraph

MissingMoney is a government-partnered public-service data platform, not a lead-gen
site. It aggregates unclaimed-property records supplied by participating jurisdictions,
lets consumers search free, and routes them to the state (or supports a state-approved
claim). The defensible replication is a **B2G platform**: obtain authorized state feeds
under data-use agreements, normalize into a common NAUPA-aligned schema, provide national
masked search + state-specific claim routing, and earn revenue from **government**
participation, implementation, white-label, and workflow modules — never from claimants.

## The central challenge is institutional, not technical

NAUPA reporting formats give a national *structural* standard, but they do not grant a
right to obtain or republish any state's data. The platform needs either a master NAUPA
relationship or individual state agreements. Public-records requests can supplement, but
records supplied to third parties may be incomplete, delayed, redacted, or licensed on
terms that forbid unrestricted republication. Engineering can build a national index in
~12 months; it should NOT be represented as a complete national service until data
rights, participation, refresh schedules, masking policies, and claim routes are in force.

## The hard line: what the automated loop will NEVER do autonomously

These are **human-gated** — they draft to `~/.claude/yolo-queue/pending-approval/`, they
do not execute:

- Acquire, download, or ingest any **real** state or NAUPA feed.
- **Scrape** any state portal for bulk data (crawling is limited to availability
  monitoring or a written-permission integration).
- Sign, send, or negotiate any **LOI, data-use agreement, or contract**.
- Retain counsel, buy insurance/bonds, or commit **spend**.
- **Deploy** to any server, change **DNS**, or expose anything publicly.
- **Send** anything to a state, a list, or a claimant.

## What the loop CAN own (reversible, local, $0)

- Scaffolding and evolving the software prototype against **synthetic** data.
- The data model, ingestion adapters, masking rules, search, claim state-machine,
  provenance/lineage, fraud-signal stubs.
- Living planning docs: the state-acquisition matrix, architecture, roadmap, budget,
  privacy/data-broker analysis, and the regulatory matrix.
- Local tests that prove each increment works.

## Revenue architecture (government-first)

| Stream | Buyer | Basis | Risk |
|---|---|---|---|
| Annual platform participation | State / NAUPA | fixed / population / volume tier | low–moderate |
| Feed onboarding & migration | State | one-time implementation | low |
| White-label state search portal | State | annual software + support | low |
| Claim-workflow module | State | annual or per-claim | moderate (needs explicit authority) |
| Identity & document verification | State | pass-through + margin | moderate (privacy/biometric) |
| Analytics & outreach | State | subscription / project | moderate |
| Authorized partner API | Gov / regulated institution | usage tiers | moderate |

**Excluded at launch:** selling claimant leads, ads against owner names, charging
consumers for search, contingent recovery %, buying claims. These create finder-law
exposure and conflict with the state agencies that are the real customer. State finder-fee
caps vary (CA ~10%, FL ≤30%, IL ~10%, TX ≤10%, NY restricted) — the platform avoids the
category entirely at launch.

## Liability allocation

| Responsibility | Owner |
|---|---|
| Accuracy of source records | Supplying jurisdiction (with contractual correction) |
| Accuracy of normalization/display | Platform |
| Identity proofing / evidence collection | Platform or approved vendor under state rules |
| Entitlement determination & payment | **State**, unless expressly delegated |