VIEWER-TRUTH

Finish the collapse, then the blockers, then the create path, then triage. Re-read 2026-09-02: the identity-fusion cohort is no longer unsized — it is measured (zero confirmed splits, judge = veto-not-proposer), so the head of the queue is the two owner rulings that measurement bought (#3416 re-scope-or-close; wave-3 build-or-not) and the free-but-expiring pairing window before Regina's WhatsApp onboarding. The client lane (#3148) and the missing detector (#3162) — which finished ADR-142 and stopped an 18th expression — both closed (08-29/08-31), as did the detector-bypass follow-up (#3176, 08-31) and the identity-substrate tail (#3424, #3446, #3489, all by 08-31). Remaining: the four uncensused questions that block calling done (#3173, #3174, #3172, #3179), ordered so #3174 unblocks #3172; the tier-claim residue (#3270 only — #3265 and #3267 both closed); then live-bug triage, ordered by whether exposure is live (#3276 blanks a Mizo surface, #3243 halves Regina's audience) before silent or latent defects.

Deliberately ignored: priority labels alone (all but three are p1, so the label cannot order them); filing order and age (#1314 is the oldest, filed 2026-05, and sorts last); how cheap or well-understood a fix looks; and the severity a body asserts before exposure was measured.

2026-08-29→31 — ADR-142's last two lanes, the detector hardening, and the identity-substrate tail all closed. Finish-the-collapse: #3148 (client viewer resolution disagreed with the server) closed 2026-08-29 — client/services/viewer.ts now calls the current_viewer_person_id RPC instead of bridging through provenance_person_ids itself. #3162 (17 expressions, no detector) closed 2026-08-31 after independent re-verification of all five acceptance bullets: one accessor per lane, a cross-lane parity test, the duplicate find_person_node_ids_by_user_ids gone, and the viewer-resolution-single-reader check.py rule live in CI. Detector hardening: #3176 (4 bypasses) closed the same day — split/concatenated literals, the receiver-name gate, getattr indirection and the PostgREST alternates all now fire, each with an armed test. The identity-substrate tail: #3424 (alias index missing tenant_id) closed 2026-08-31 — tenant-scoped index live in prod plus a choke-point boundary guard on every add_alias call; its residue census #3446 closed 2026-08-27 as measured-no-damage (zero confirmed lost alias rows across all 9 tenants). #3489 (dedup ignored deterministic identity signal) closed 2026-08-31 — shipped as a partition gate consulting email/JID/domain/address identifiers plus graph-relationship corroboration, verified reachable against Regina's live, unpaused tenant. The tier-claim ruling shipped: #3265 (create-with-no-person tier loss) closed 2026-08-19 — the console now finds-or-creates the identity row through the ADR-084 single writer rather than refusing the tier or losing it to the reconciler; its concurrent-create race split to #3270, still open. Every one of these went through the same verification discipline: triage proposed 26 closures fleet-wide and an adversarial critic re-derived each p0/p1 verdict independently rather than accepting it, holding 13.

The 2026-08-20→25 wave — from “unrun detector” to a measured answer. PR #3530 (another session, 08-22) unioned provenance_person_ids onto merge survivors in both consolidation write paths — a permanent, non-self-healing identity drop on every merge that had ever run; the detector's under-count fell with it (invisible 459 → 217, multi-identity nodes 0 → 18). PR #3538 (08-23) made the detector runnable at Regina scale (chunked exact KNN over the query_ids seam) and re-labelled its fusion counters after #3530 falsified their docstring. The owner-gated judge run followed: 8 pairs, 8 LLM calls, one same verdict — confirmed false positive (“yasmine el-daly” vs “[email protected]”, cosine 0.833 — a surname embedding-matched an email local-part), which also filed #3546. The strategic finding stands on its own: the judge is a reliable VETO and a poor PROPOSER. The jid-minting sub-fleet then took the WhatsApp half (see the note block above; #3555/#3561/#3566 merged, #3572 open, Regina still 0 JIDs, the pairing window unexpired).

The spine is merged and live. W0 stop-loss (PR #3103) stopped disconnect+merge from deleting a user's identity. W1 the spine (PR #3122) built viewer_bindings — one row per (tenant, account), composite FK, ON DELETE RESTRICT, one reconciler — and backfilled 10 rows. W2 the resolver (PR #3152) minted current_viewer_person_id(), repointed 7 SQL functions and 2 Python sites, shipped the platform resolvability console, and carried the disclosure fix. Verified from the database, not run metadata.

W2 carried a cross-user disclosure fix — W1's reconciler counted its refusal over a de-duplicated set and its warning over the raw one, so an account bridging two nodes would bind while the log said it had not.

The census, run after W2 merged (#3162): 17 expressions on main, 3 of 12 corrected, no cross-lane detector — get_viewer_person_id is mocked in every test touching it, which is how every lane looked closed from inside itself. The real-DB parity test shipped in the sweep below.

The choke-point sweep (PR #3169, merged 2026-08-08) found three defects in its own code, all one shape — a repoint carried the new source over and left behind a guarantee the old code had: a dropped runaway-page bound, a dropped sort order (one concurrent insert silently drops an account from the recipient list), and a roster field needing a different id space that broke every tier edit (0 of 4,978 nodes carry a shared id). The gate itself could be silenced by a string literal — the suppression token matched the raw line.

The four uncensused questions, now measured: display NAME (now 5-6 implementations, #3173); suppression scope (ruled per-viewer, #3177); access TIER — the reconciler is live (PR #3249 → 7dfedb9e7, pg_cron PR #3258 → ff097766a, hourly at :26), the write gap that fed the drift closed (PR #3272 for #3234), re-measured 0 of 14 diverging; identity subsumption (the reverse join, #3174).

“The nine ways a user arrives” was the wrong unit, and it undercounted (re-derived 2026-08-18). Journeys are stories, and stories do not enumerate — which is why nobody could say whether nine was all of them. What decides whether one human becomes two people is not which story they lived but which key their connector can hand the resolver, and there is exactly ONE resolver: find_or_create_person_by_alias, a six-rung ladder — group alias → cross-group alias → email → canonical name → first-name prefix → base name. An earlier trace read WhatsApp and email ingest as separate mechanisms; they are not. slices/node/materializer.py routes every PERSON intent through that same ladder. The split is not caused by different code. It is caused by which rungs are reachable.

Two key-spaces, declared per source type in slices/message/model.py: email-authoritative — gmail, maildir, exchange, google_calendar, exchange_calendar — and name-resolved with no email — whatsapp, whatsapp_live. (slack is neither — its key is the Slack user id, not an email — so it is NOT counted below.) For a human present in one of each, the email rung is measured never to fire: WhatsApp identities are 99.7% email-less on production (1,145 of 1,149) while gmail and maildir identities are ~100% email-bearing. 🛑 Measured, not structural. _get_sender_emails reads from_address/from_email off raw_metadata for ANY message and never consults the source type — the partition is a fact about what each PARSER populates (grep confirms the WhatsApp connector writes neither field, 0 occurrences), not an invariant anything enforces. A parser change moves this silently, and no detector would fire. The only bridge left is exact canonical_name — an LLM-merged pushName against an email display name — and for the 115 WhatsApp identities whose name IS a phone number, no rung can match at all. So the countable unit is connector PAIRS that guarantee a split: 2 × 5 = 10. The nine journeys covered exactly ONE of them (WhatsApp × Gmail, the old journey 3).

Why the duplicate census looks clean and is not: 2 name-duplicates and 2 email-duplicates out of 5,137 identities, and zero identities spanning two source types. That reads as health; it is an artifact of the detector. A split pair shares no key, so no census the system can currently run can see it. Live today: only gmail/maildir and whatsapp/whatsapp_live currently MINT person identities in production, so 4 of the 10 pairs are live and the rest are latent. exchange and slack have no production sources at all; google_calendar does have sources and ingests messages, but resolves zero persons, so it cannot split anyone and is not counted among the four. The concentration risk is Regina: 3,865 maildir identities and no WhatsApp — maildir is the single largest identity producer on the fleet and appeared in none of the nine journeys. The day a second connector lands there, thousands split at once.

What the arrival paths actually are: 7 live production routes to an auth.users row, and 3 produce a zero-binding user unconditionally — Mizo form signup, Mizo Google-OAuth signup, and admin-create-without-a-person. Every ordinary product signup starts unbound. POST /api/identity/link is live, registered and rate-limited with no caller in any frontend — and that is a regression, not a gap: commit 456d5d7c7 (“delete the legacy enterprise web app and every live reference to it”, PR #2889, 2026-07-31) removed the one call site, which lived only in the deleted app; no equivalent was added to client/.

What this re-derivation CLOSED: the old “merge two people” family (journeys 5, 9) is largely fixed and this page said otherwise. ADR-142's viewer_bindings hardened all three delete paths, the dedup merge now re-points bindings onto the survivor, and the node prune excludes bound nodes — converting what was silent corruption into DENIAL rather than EXPOSURE, deliberately. What it did NOT close: nodes_v2 still upserts on (tenant_id, node_type, lower(canonical_name)), so two different humans sharing one name in a tenant still become ONE node. That is the exposure direction, and its only defence is application-layer “decline to bind either” — not a constraint the database enforces. Unresolved: google_calendar has 2,766 ingested messages across 3 tenants and attributes zero persons, though its resolver is wired unconditionally.

Cron delivery is now observed (#3259, PR #3394, merged 2026-08-17). Both halves of the check had shipped and neither had ever taken effect: the middleware ran on every internal request but only UPDATEs cron_route_heartbeats, the rows are CREATED by a sweep, and nothing scheduled the sweep — so every arrival matched no row, production showed 0 heartbeat rows, and that read as a healthy fleet. The issue was CLOSED with no state:not-in-effect label, which is why it looked finished. The PR carried the migration and its route-census test, and scheduled the sweep hourly at :19; it fired at 20:19:01Z and created a heartbeat row for each of the 15 POSTing jobs — the 14 already scheduled, plus the sweep itself. Registration is not arrival: a row exists for a route from the moment it is censused, and carries an arrival only once that job next fires — so at the first pass the two longest-period jobs, the 03:00 nightly and the 12-hourly Exchange renewal, had no arrival simply because neither was due yet. An empty arrival on a long-period route is not evidence of silence until its own period has elapsed, which is the distinction the sweep's grace window encodes. The tier reconciler above POSTs its own route, so it is now watched by this. Residual, filed: the sweep's unreadable finding class is dropped before Sentry (#3393) — dormant while every scheduled job stays parseable.

What this report does not claim: W2 made no production account newly resolvable — re-measured 14 linked, 10 bound, 4 unresolvable, unchanged, and all ten that resolve already resolved before it. An earlier version said Regina went from zero to one resolvable; that was true only of the bridge, not the serving path. And the zeros are two different zeros — the latent measure (no node fuses two linked identities, no account bridges to two nodes) is the load-bearing one, and it is exactly the precondition for both the disclosure defect and the client divergence.