`output/wallco-settlement-canary-2026-06-01.md`

70 lines
# wallco.ai Settlement Integrity Canary — 2026-06-01

**Type:** READ-ONLY canary. No UPDATE / publish / unpublish performed.
**Question:** Is anything with a BLOCK-class settlement verdict currently `is_published = TRUE`?
**Run:** 2026-05-31 (filename per task spec).

## Verdict: ✅ CLEAN on BOTH machines — zero leaks

No `is_published = TRUE` row carries a BLOCK-class settlement verdict on either
Mac2 (authoritative) or prod (45.61.58.125). **Zero leaked ids.**

BLOCK-class for this canary = `BLOCK`, `REVIEW-VISION-ERROR` (fail-closed vision error),
`BLEED_GHOST_BLOCK` / `BLEED_GUARD_BLOCK` (quality blocks — flagged separately below).

---

## Mac2 (`dw_admin@127.0.0.1/dw_unified`, table `all_designs`)

| settlement_verdict   | total | published |
|----------------------|------:|----------:|
| (null)               | 35002 |      2864 |
| BLEED_GHOST_OK       |  5898 |      2182 |
| OK                   |  1699 |       641 |
| BLEED_GHOST_REGEN    |   372 |         3 |
| **BLEED_GHOST_BLOCK**|  1600 |     **0** |
| **BLOCK**            |   220 |     **0** |
| **REVIEW-VISION-ERROR** | 8  |     **0** |
| **BLEED_GUARD_BLOCK**|     3 |     **0** |

- All four block classes: **0 published.** ✅
- `BLEED_GHOST_REGEN` (3 published) is a *regen-pending* quality flag, **not** a settlement/quality block — not in scope, not a leak.

## prod — 45.61.58.125 (`dw_admin@127.0.0.1/dw_unified`, table `all_designs`)

| settlement_verdict   | total | published |
|----------------------|------:|----------:|
| (null)               | 10363 |      2868 |
| OK                   |   193 |         0 |
| **BLOCK**            |    30 |     **0** |
| **REVIEW-VISION-ERROR** | 1  |     **0** |

- All block classes: **0 published.** ✅
- prod `all_designs` is sparse vs Mac2 (10,587 rows vs ~44,800) and has **0** rows for the `BLEED_*` verdict family — consistent with the known prod-PG-sparse / designs.json-is-source-of-truth pattern. The customer-facing grid reads `designs.json`, not prod PG directly. This canary covers the table integrity on both machines as specified; it does **not** re-derive the live feed.

---

## Recommended predicate (for Steve — if a future force-publish needs the legal gate)

When force-publishing (which requires `SET LOCAL settlement.allow_override='true'`, disabling
the auto trigger), the WHERE-clause is the *only* remaining legal gate. Exclude every block class:

```sql
WHERE settlement_verdict IN ('OK', 'BLEED_GHOST_OK')   -- explicit allowlist, safest
  AND user_removed = FALSE
  AND needs_fixing_at IS NULL
-- NEVER publish rows where settlement_verdict IN
--   ('BLOCK','REVIEW-VISION-ERROR','BLEED_GHOST_BLOCK','BLEED_GUARD_BLOCK')
--   or settlement_verdict IS NULL without a vetted reason.
```

Allowlist (`IN ('OK','BLEED_GHOST_OK')`) is preferred over a blocklist because new/unknown
verdict values fail closed. `(null)` verdicts are the bulk of currently-published inventory
(legacy / pre-gate designs) — left as-is; not a leak, but a candidate for a future backfill pass.

## Post-canary action
- **None taken.** READ-ONLY. No removal recommended because there is nothing leaked to remove.
- If a leak *had* been found: removing blocked-live content is compliance-safe and needs no
  approval; bulk-unpublishing pre-existing blocked rows (possible intentional overrides) would
  need Steve's OK.