Filed by the motir run MOTIR-2795 of 2026-08-17, which disproved the card it was dispatched to build. Correction already applied — MOTIR-2795 is re-scoped in place and MOTIR-2915 carries the carve-out. This card is the telemetry.
MOTIR-2795 was authored on 2026-08-12 from one run of pnpm reconcile:orgs, and it stated as measured fact that three motir-core identifiers did not exist in production motir-core — with a three-row table of ✗ marks — and concluded that "some motir-core that is not production has MOTIR_AI_URL pointed at the production motir-ai, and its tenants are being provisioned in the live service's tables." From that it drew four consequences (live tables accruing unowned tenants; billing identity mintable from outside production; the credit gate reachable; the failed jobs being luck rather than protection) and wrote four remediation steps, of which step 4 was "Decide this row's fate explicitly … enumerate what hangs off cmsq75zgc0000j3qz1916gfzt before removing anything … and say whether it is migrated or discarded."
Read 2026-08-17 off the platform, not off a config file — fly Machines API exec on the running production machines, each query issued against that machine's own DATABASE_URL so no credential moved:
organization cmsq73pcq00lbi3phqbh6kaf4 exists in production motir-core: "pantheonminima's Workspace", createdAt 2026-08-12T14:39:26.234Z, isMeta false, and organization_membership gives it an owner — pantheonminima@foxmail.com. The workspace and the project exist too, with a board, 7 board columns, 7 workflow statuses and 22 transitions.moooon holds exactly three apps — motir-ai, motir-gateway, motir-core. There is no non-production motir-core to be the submitter, and production motir-core's MOTIR_AI_URL is https://motir-ai.fly.dev.discovery jobs failed with errorJson.code = "out_of_credits"; all three PlanningRun rows are status: refused with 0 input and 0 output tokens; CreditTransaction and CreditLedger hold 0 rows for the org. The credit gate fired. Nothing was spent, metered or debited.checked 2 … UNKNOWN TO motir-core: (none).So the tenant was a real self-serve sign-up trying the AI planning surface, and step 4 would have deleted a live customer's billing entity and their project's mirror.
AMENDED 2026-08-17 (this card's own close-out): the gate named below is the WRONG ONE, and the correction is the whole finding. This paragraph originally opened "Gate 2's QUANTITY limb was satisfied in form and defeated in substance". Gate 2's QUANTITY limb did not exist when MOTIR-2795 was authored — it landed 993157c on 2026-08-17T00:07Z (MOTIR-2702), four days after 2026-08-12T15:00:23Z (git log origin/main -S 'the tool, the scope it was run at' -- prompts/ returns that one commit and no other). A gate that postdates the defect cannot be the gate that failed, and the diagnosis was retro-fitted onto it.
The gate that WAS loaded and did fall short is plan-rules/kind-leaf-deepen.md's THIRD LIMB — read the platform (0192e05, 2026-08-05T01:24Z, seven days before the defect; MANIFEST.md routes motir log-bug — the pass that filed MOTIR-2795 mid-run — through that pack). Its discharge is "a deployed-state assertion read from the PLATFORM'S OWN API — or, for a database, from ITS OWN CATALOG" and its tell is "the card's evidence for a RUNTIME property is a file in our own repo, and nothing reads the platform." The discharge was performed and the tell reads clean — something did read a platform. Every example the limb gives is addressed by a name the platform owns (fly status <app>, an environment listing for a named deployment, a catalog view on a connection you are already inside); CORE_DATABASE_URL is the case it does not reach, because there a config file did not make the assertion, it chose who would answer it. The neighbouring claim-vs-pointer gate knows the mechanism and names it in a parenthetical — grepped on origin/main (not a stale checkout) — but its subject is a code fact and its discharge is a git ref, so it reaches the source tree and not a database.
The original paragraph's substance below still holds, read against that limb instead: the card named a tool, a scope and a reading — pnpm reconcile:orgs, against production, with its verbatim output pasted in. That is exactly the three things the gate asks for, which is why it read as thoroughly verified; it is the most carefully evidenced card in the family. What the gate does not ask is whether the tool was pointed at the thing the criterion names, and a connection string supplied per-invocation is precisely where that goes wrong. "Measured in PRODUCTION" was a claim about CORE_DATABASE_URL, not a reading of it.
And the card printed its own disproof, two paragraphs apart. It recorded motir-ai's row as created 2026-08-12T14:41:12.636Z, and then — reaching for evidence that this was not a propagation lag — recorded that "motir-core production's newest Organization predates this by three weeks (cmru65ltx…, 2026-07-21)." Those two lines cannot both be true of one pair of databases: motir-core's row must exist before motir-ai mirrors it, so a core database whose newest organization is 22 days older than the mirror it is being compared against is, by that fact alone, not the database that produced the mirror. The sentence was written as corroboration and is a staleness detector. A single read of a system is one reading; the second reading that would have contradicted it was already on the page.
The third failure is one of direction, not of evidence. The remediation's terminal step deletes production rows, and the card's confidence budget was set by how interesting the diagnosis was rather than by how irreversible the remedy was. Nothing in the authoring asked the question a destructive step should force: what would I expect to see if this diagnosis were wrong, and have I looked for it? One SELECT against the right database — the very query the script already contains — was the whole cost.
A criterion that says "measured against production" is discharged by evidence that the thing which ANSWERED was production. Where a check reaches another system through a value supplied at invocation — a second connection string, a *_URL, a profile, a token — the identity of the responder is part of the reading, and a stale or sibling copy answers correctly-shaped and wrong. Name the witness: a row whose existence dates the database, a version, an id you can independently verify.
Corollary, for the authoring pass: when a card's own body contains two measurements of the same pair of systems, check them against each other before drawing a conclusion from either. Discovering a contradiction inside one's own evidence is the cheapest verification there is, and it was available here for free.
Corollary, for a card whose remedy DELETES: an irreversible step raises the standard of proof for the diagnosis that motivates it, above what a merely interesting diagnosis needs. Enumerating what hangs off a row before deleting it — which this card did require — protects against deleting more than intended; it does nothing about deleting the wrong row. Those need different checks, and the card had only the first.
motir-meta/notes.html #291 — filed by the same run as motir-meta PR #207 (branch docs/reconcile-read-answered-by-stale-core, merged 2026-08-17T17:32:41Z; no id in branch or title, this card referenced in the PR body — correct, since MOTIR-2795 and MOTIR-2915 ship in motir-ai).
⚠️ #291 inherited this card's wrong-gate attribution and was corrected in place by motir-meta PR #215 (open at close-out). Read the amended entry, not the merged original: its "why nothing caught it" half is the part a future rule gets written from, and it credited a gate that postdates the defect by four days.
Nothing about MOTIR-2795's own scope. One product observation the run surfaced and did not file, deliberately, because it is a business question rather than a defect and may already be owned by the billing/plan-tier work: a brand-new self-serve organization gets no CreditLedger row at all, so its first AI action returns out_of_credits (balance 0) — this tenant hit it three times in 150 seconds and left. Disposed 2026-08-17 at this card's close-out: the claim was true — the work IS already owned, by MOTIR-1106 (8.6.2 Decide pricing strategy: free PM-core ↔ paid AI boundary, todo, high, 3 pts, blocking MOTIR-1119). MOTIR-1138 settled the tiering MODEL and is done; nothing in the graph decides the first-run allowance, so the absent CreditLedger row is a default nobody chose. The production reading (3 refusals in 150 s, 0 tokens, 0 ledger rows, the user gone) is now a comment on MOTIR-1106 with the note that whatever it decides owes an owning card for the mechanism. No new card filed from here — a pricing question already has an owner, and filing a second one is the duplicate-write shape.
motir run MOTIR-2916)1 — The correction HELD, and then some. MOTIR-2795 is not merely re-scoped in place: it was executed and is done (motir-ai PR #235, subtask/MOTIR-2795-reconcile-freshness-witness, "fix(reconcile): assert a freshness witness before classifying an org as unknown", merged 2026-08-17T18:31:54Z). The remedy is now an assertion in code, not a plan. MOTIR-2915 exists as the type: decision carve-out (todo, 2 pts). Both statuses read off the live tenant.
2 — The lesson is on origin/main and the corpus is clean. notes.html #291, located by CONTENT not by the card's citation (the card carried no number). Numbering audited: 295 entries, highest mistake-num 295, "Across the 295 mistakes", and grep -o 'mistake-num">[0-9]*<' | sort -n | uniq -d empty — no gap, no duplicate.
3 — The one citation that was wrong is the diagnostic one, corrected above and in the entry: the QUANTITY limb postdates the defect by four days. This is the [MOTIR-2280] discriminator's own material — a record card's account of why nothing caught it is a citation like any other, and it is the least-checked sentence in the corpus because it is the sentence everyone agrees with.
4 — Promote question: SHARPEN, filed as MOTIR-2929 (motir-meta) → MOTIR-2930 (motir-ai, blocked_by, seeded blocked). This card posed no explicit promote question, but its explanationMd argues for one ("that is worth a standing check"), so it was settled rather than left open. The grounds, in the order they were run:
origin/main; the platform limb's own distinction is repo file vs platform, and a live database is a platform. The failure sits in the seam.run.md / phase-skeleton.md / kind-container.md and is already at the 60-minute agent ceiling with no CI to absorb it; MOTIR-2913 holds op-replan.md. Neither touches kind-leaf-deepen.md, so folding would prevent no collision. The one file that does overlap (run.md) is criterion 4, marked droppable with a mechanical drop test.5 — Advisories disposed on both new cards (MOTIR-2899's create-time post-condition); the per-entry table is a comment on MOTIR-2929.
6 — Close condition. motir-meta PR #215 (the #291 correction). No PR of this run carries a MOTIR- id: this card's targetRepo is unset and the PR records something about cards shipping in motir-ai, so the sync cannot flip it — the close-out is by hand.