/made-id-reviewWhere it sits: the custodian (stage ③) never commits an uncertain identity link on its own — it writes a proposal. This stage is what a human does with those proposals: six review surfaces where a reviewer confirms a match, merges a duplicate, or mints a net-new company. Confirming is what turns a proposal into a canonical link (stage ⑤).
The scorer’s disposition decides who acts. Anything short of near-certain, or anything ambiguous, is a person’s call — the agent will not guess between two plausible companies.
| Disposition | When | Who acts |
|---|---|---|
| REVIEW | tier is None, or score < 0.50, or not the top candidate, or >1 candidate clears the floor (ambiguous) | Human — on the relevant review tab |
| AUTO_CONFIRM | top candidate is deterministic tier AND score ≥ 0.995 | Marks the proposal bulk-acceptable — a human still clicks (band-scoped accept) |
| PROPOSE | one clear candidate below the auto floor | Human confirms the single proposal |
| NEW_CANONICAL | no candidate at all | Human approves a mint (New Accounts) |
Propose-only. The only fully-automatic write in the whole system is Joe’s in-DB ≥0.999 auto-merge. Everything else — every match, every mint, every merge below 0.999 — waits for a click. Nothing is ever silently deleted.
er_decisions holds 1,919 recorded human decisions, the most recent on 2026-09-09 09:04 UTC. Account proposals were written the same morning at 08:30. Whatever is built next is an improvement to a working review process, not its introduction — which is why the plan preserves the live path rather than replacing it wholesale.
1,941 Salesforce accounts have no MADE-ID match (60% of 3,209) and 7,244 HubSpot contacts have no derived company (41% of 17,843). That is the real backlog — not the 6,694 rows sitting in the two abandoned match queues, which have had nothing enqueued since May/July 2026 and are stale inventory to retire.
Drain rate is therefore bounded by reviewer capacity, not by matching capability. How much reviewer time exists per week is one of the eight open questions for Made — see the plan (M-Q4). It is the single hardest ceiling on throughput, and no amount of engineering moves it.
Six surfaces are documented here, and a separate review bundle exists in the repository with its own proposal tables, confidence bands and rejection semantics. A file existing is not proof it is deployed, and two contact-proposal producers are still writing side by side. Before new review UI is built, one active path per operation gets chosen — preserving the live path that carries the 1,919 real decisions, and porting the better ideas into it rather than swapping wholesale.
Each tab is served by an Edge Function reading a specific queue/view; the reviewer’s action calls a specific RPC. This is the exact wiring.
| Tab | What the human resolves | Edge Function → reads | Action → RPC |
|---|---|---|---|
| Coverage | System health — feed freshness, resolver activity, queue depth; clear the easy exact matches | direct → v_er_key_coverage, v_er_loop_health | auto_confirm_exact_matches |
| Duplicates | Two canonical companies that are one firm → merge onto the senior made_id | made-id-review → v_match_queue_review | made_id_apply_review (merge / keep_separate / needs_review) |
| CRM Matching | Account proposals: a SFDC/HubSpot account → an existing company, or a net-new | made-id-census-review → er_identity_proposals | apply_er_identity_proposal (assign_external_id / create_canonical) |
| Contacts | Contact → identity + contact → account rollup (banded, bulk-acceptable) | made-id-contact-review → v_made_id_contact_match_queue | made_id_contact_apply_review (merged / rejected / accepted) |
| New Accounts | Mint a net-new company (human-approved) → MADE-ID + enrichment | made-id-new-accounts → v_orphan_candidates | create_company_from_orphan, decide_orphan_candidate, /enrich, /classify |
| Campaigns | SFDC ↔ HubSpot campaign crosswalk | made-id-campaign-review → campaign_dim_proposals | apply_campaign_dim_proposal |
When the Duplicates tab shows two canonical companies that are really one firm, the reviewer confirms a merge. The mechanic is deterministic and reversible.
Earliest made_id_assigned_at (NULLs last; tiebreak created_at) wins.
The loser takes the survivor’s made_id at confidence 1.0.
Every er_account_census + er_identity_map row is re-pointed loser → survivor.
The loser’s name becomes a learned alias; er_decisions records it.
Both physical companies rows remain — the merge re-points identity but there is no tombstone / FK re-point yet (preview_company_merge is read-only). A true physical merge (tombstone + merged_into_company_id) is on the roadmap; the anchor column already exists.
When a CRM row matches nothing, it becomes an orphan candidate; a human approves the mint on the New Accounts tab, and the record is enriched and given a MADE-ID.
No canonical match → er_orphan_candidates
bc_hub match check; classify primary_category
Clay firmographics ($0 if Hub-matched)
create_company_from_orphan
new companies row + made_id (stage ⑤)
Creation stages tracked: queued → clay_sent → clay_enriched → segmented → seeding → created (or needs_attention / error). Nothing is minted without a human decision.
Not every proposal needs a one-by-one decision. Proposals the scorer marked AUTO_CONFIRM (deterministic tier, ≥0.995, no rejection conflict) are bulk-acceptable: a reviewer accepts a whole band at once. This is how the one-time blitz drains — the near-certain by band, the genuinely ambiguous one at a time.
| Band | Reviewer action |
|---|---|
| Deterministic ≥0.995 | Band-scoped bulk-accept (made_id_bulk_accept_deterministic) — a single click clears many |
| Strong / single candidate | Reviewed individually — quick confirm/reject |
| Ambiguous / conflict | Always one at a time — the reviewer chooses; rejections are remembered (never re-proposed) |
Every rejection writes to er_negative_decisions so the same wrong pair is never proposed again — the reviewer’s effort makes the next run cheaper (see the Custodian’s Memory tab).