Release gates SHADOW

We do not ship trust as a promise. We ship it as a test.

26 criteria, each with a binary answer. 4 are green with an automated probe behind them today. 18 have no probe written yet, and 1 cannot pass until something else is built. 3 are failing right now, and we would rather name them: gate 13 (single-reader), gate 14 (cutover-hygiene), gate 22 (recording-absence).

Every one of them, including the red.

This is the full registry rather than a flattering subset. A criterion with no probe is shown as having no probe, because an untested assertion and a passing test are different things and only one of them is evidence. The count in the sentence above is the length of the registry, computed at build time, not a number somebody typed.

01no probeA sentinel in one tenant appears in zero prompts built for another, both directions

02no probeConstructing an audience without tenant and brand raises; zero callers of the old path

03passresolve() and the upsert filing target agree for every endpoint, merges followed

04passNo child row references a merged-away person; a named merged case keeps all its endpoints

05no probeScripted calls as three named real customers are greeted warm and by name

06no probeTen spoofed-ID calls per brand elicit zero cross-brand names, facts or operator notes

07no probeA decline blocks through telnyx_send and lead_dispatch, across tenants, and on store error

08no probeExactly one consent-gated callback block per built prompt; zero for a declined number

09no probeA planted CHANGEME, a written clock time or a brand canary fails the build

10no probeA number learned by voice reaches the Google contact; a payment identifier never does

11no probeRenders in under a second behind operator auth; the public probe gets 401 and no contact data

12no probeAn unapproved external send returns queued with an action_log row; no send verb in any client tool list

13failZero references to the ledger directory outside the customerledger package

14failSeven consecutive days of zero writes to the old contacts.db; every ledger row brand stamped

15passZero operator-visibility rows in any client store; every field traces to that client

16no probeTwo interleaved calls on different tenants' DIDs each build prompts with only their own data

17no probeA tenant restored from last night's snapshot passes that tenant's probes

18blockedMutating a consent_events row fails verify and names it; a logged erasure verifies clean; head matches the RFC 3161 token

19no probeEvery call row carries a caller number where the carrier supplied one, resolved or explicitly unknown

20no probeFrom any call the person card opens behind tenant auth; the public probe gets 401 and no transcript

21no probeZero mid-word fragment boundaries and no duplicated greeting, against the known-bad Suplay fixture

22failZero recording artifacts and zero recording configuration for any tenant

23no probeA GET, a forged token, another person's token and an unticked POST all leave the log byte-identical

24no probeThe wording rendered on every capture surface is the string record_sms_consent writes

25no probeClosing or skipping a consent prompt writes no record at all, neither grant nor decline

26passMutating a field_observations row fails verify and names it; re-stamping is idempotent; absence is not an observation

the count is len(GATES), not a number in this sentence | reproduce with ledgerctl.py gates | measured 2026-09-02

A blocked gate, read closely SHADOW

Blocked is not failing, and it is not passing either.

Two of the criteria above are blocked, which means the probe runs and correctly refuses to go green because the thing it tests does not exist yet. The clearest example is the anchor criterion. Its probe confirms that mutating a stored consent row is detected and named, and that a logged erasure still verifies clean, both of which hold. Then it stops, because the rest of the criterion asks for an RFC 3161 anchor and no signed token is issued or stored anywhere.

So the chain is tamper detectable and it is not tamper proof, and the gate stays amber rather than green until a head digest leaves this machine. A criterion that quietly passed on the half that worked would be worse than no criterion, because it would retire the question.

gate 18 BLOCKED | gate 15 PASS | measured 2026-09-02

Why publish the failures

A gate that cannot fail is decoration.

The previous version of this website carried a gate count that was correct when it was written and wrong within days, load bearing in the headline the entire time. That is the ordinary way this goes: somebody writes a true number into a page, the product moves, and nothing connects the two again.

So the number is computed, the states are measured, and a build that would publish a green count while something is red does not produce a page at all. The cost of that choice is that you are reading about our failures on our own marketing site. We think that is the cheaper side of the trade.

How the record holds Why this exists