Phase 3 Slice 10 staging table for the fuzzy-match orphans mig 090
produces (design §3.I + m's Q10 ruling). Each legacy deadline that
the matcher can't uniquely bind to a deadline_rule logs here with
the full candidate list so a legal-review pass can hand-link the
ambiguous tail without rerunning the match.
Schema:
- deadline_id FK to paliad.deadlines (ON DELETE CASCADE).
- title + project_id + proceeding_code denormalised so the admin
orphan-review UI groups + filters without re-joining.
- reason text CHECK in ('no_match', 'ambiguous', 'no_project',
'manual_unbound'). Mig 090 writes the first two; the editor
surface (Slice 11) may add the others.
- candidate_count + candidate_rule_ids carry the full list of
plausible rules so the legal-review UI can render "pick one"
chips from the matcher's actual output.
- resolved_at + resolved_rule_id flip when an editor binds the
row via the admin UI; the matching paliad.deadlines.rule_id
UPDATE happens at the same time. Both rows hold so the staging
table doubles as an audit trail of the legal-review pass.
Indexes:
- deadline_id for the per-deadline lookup the admin UI uses.
- unresolved_at DESC for the "open orphans" list (the only one
the legal-review UI typically lists).
RLS: admin-only read. The orphan list contains real deadline titles
+ project ids, so non-admins must not see it. Service-layer surfaces
(Slice 11) gate further.
Mig 089 ships the table; mig 090 does the fuzzy-match backfill +
populates this table. Numbering reflects the dependency order (the
backfill SELECTs INTO this table, so the table must exist first).
