Owner-validation: ask-on-mismatch, accept-grows-identity, family-transfer two-sided

Superseded by 2026-07-11-user-identity-entry-model — the accept-grows / two-sided-transfer flow is retained. Module renamed owner-validation.ts → identity-matcher.ts; the prior three "pending" statuses (pending_owner_confirmation | pending_family_transfer | pending_entity_confirmation) collapse into one pending_identity_confirmation.

Decision

Every parsed document must demonstrably belong to the uploading workspace member via PAN / IFSC / account-number / email / name / TAN matching. On mismatch, ask the user to confirm. Accept-flow grows the user's account list. Family transfer is two-sided: uploader proposes, recipient must accept.

Why

Per the source-of-truth rule and the new pricing-reset assumptions, every parsed document must demonstrably belong to the workspace member who uploaded it — otherwise rollups poison cleanly. Per-PAN matching against PAN / IFSC / account-number / email / name / TAN is the floor; user confirmation handles ambiguity.

Impact

• New module apps/functions/src/parser/owner-validation.ts.
• Identity matched against users/{uid} profile (PAN, name, email, phone) and against every existing account_id the user has previously confirmed.
• New document statuses: pending_owner_confirmation, pending_family_transfer, rejected_owner_denied, rejected_transfer_denied.
• Callables confirmOwnership, denyOwnership, requestFamilyTransfer, acceptFamilyTransfer, denyFamilyTransfer.
• Accept-flow grows the user's account list with the new attributes; deny auto-deletes after a 7-day grace.
• Family transfer is two-sided — uploader proposes, recipient must accept; transfer queue lives on Pro Family workspaces.
• Affects inbox-document-types, pillar-inbox, tier-pro-family.

Status

Superseded by 2026-07-11-user-identity-entry-model.

Sources

• .context/wiki/decisions/* § "2026-05-31 — Owner-validation: ask-on-mismatch, accept-grows-identity, family-transfer two-sided"