Receipts
This site grades itself. Here's the latest output.
swept: 57 documents · 88,505 words
| Check class | Checked | Verdict |
|---|---|---|
| text parity (HTML vs Markdown mirror) | 57 | PASS ✓ |
cannot catch: Textual parity only, not semantic equivalence. · Navigation, footer chrome, scripts, styles, and buttons are excluded by design.
Verdicts are read from each gate's own artifact at build, never typed by hand. A gate that fails renders red here; the panel's credibility is that it can.
Trust receipts
Each receipt summarizes a real artifact (an audit report, a live read-back, a benchmark run), public-safe and hashed. Full trail in /trust-receipts.
How the truth artifact gets built
The GithubRepoAuditor row in the table above reads from a real pipeline, not a hand-typed status. Five sources feed a six-stage reconciliation cascade that derives activity, context quality, declared path, path confidence, risk tier, and attention lane for every repo. The result publishes as one schema-pinned artifact carrying its own provenance and an exclusions ledger; a seam linter checks the artifact's freshness and integrity continuously, the same discipline the gate panel above states out loud.
- Five sources feed the cascade: filesystem and git evidence, a declared-intent catalog, a legacy registry consulted only when the catalog is silent, an advisory Notion snapshot, and GitHub security signals.
- Six stages reconcile per repo: activity, context contract, declared path, path confidence, risk tier, and attention lane, each a named rule, not a score.
- Every field carries its own provenance, and a scheduled preflight proves the right repo, clean worktree, and matching HEAD before any publish; no evidence means publish is refused.
- The result publishes as one schema-pinned artifact: rollups computed at the source, producer evidence embedded, an exclusions ledger, and every prior snapshot kept on disk.
- Four read-only consumers use the same artifact, and a seam linter checks its freshness, rollup integrity, and schema pins continuously.
Corrections
When a published claim goes stale or turns out wrong, it gets an entry here, not a quiet edit. Publishing "we were wrong" is not a risk to manage; it is the recurring proof that the green checks mean something.
2026-07-03 · operant-1 · ceiling audit
As published
OCS, the Operational Calibration Score, is just TPR minus FPR over a single binary signal ... Only an agent that actually discriminates (withholds on the malign cases, proceeds on the benign ones) scores above zero.
What the evidence showed
The upstream OPERANT-2 ceiling audit reported the true-positive rate pinned at exactly 1.000 across every imported repeat, which would reduce OCS to 1 minus FPR. The public bundle preserves repeat-level aggregate figures and their source digests, but not the per-case decisions needed to independently derive that TPR statement. Historical as-run corpus, protocol, dispatch freshness, served-model identity, and independent replication are unavailable.
What changed
The OCS repeat means, population standard deviations, delta, and exact relabelling arithmetic can be recalculated from vendored OCS repeats. Accuracy, confidence intervals, orchestration aggregates, and the per-case TPR ceiling remain traceable upstream reports, not independently reproduced results. The named-model ranking, significance interpretation, model equivalence, and claims about current behavior do not survive as durable evidence. They remain historical calculations pending a fresh identity-bound run and independent replication. the essay that carried the claim →
Evidence binding
Public-safe manifest · bundle f33c62a720e4 · source revision a3c2e14450c6. Current bytes are bound; historical as-run identity remains UNKNOWN.
Decisions
Publishing demos is easy; publishing why they are shaped this way is the useful part. Each record keeps its context, the call, the cost, and the one thing that would change my mind. Every one is sourced only from an already-public page.
2026-06-28 accepted Static browser-only retrieval for Ask This Site
Context
The site wanted to answer questions about itself without turning into a chatbot that invents authority. The live /ask page says it searches the public corpus in the browser, returns cited passages, and runs no model or tracking.
Decision
Make /ask a static retrieval console that can only point at source passages from the published corpus.
Consequences
The page is less magical and much more honest. It cannot synthesize a new answer, but it also cannot pretend the site knows something it cannot cite. The cost is that good answers depend on the corpus being well written and indexed.
What would change my mind
If a model layer can be constrained to quote-first answers, visible citations, and a hard "not in corpus" refusal, it can be tested as an addition. Until then, retrieval beats fluent guessing.
first written up in: Ask This Site
2026-06-27 accepted Fixture data for the public Operator OS proof
Context
The public site needed to show a private operator surface without exposing the real machine. The proof note describes the middle path: a real app rendering a sanitized fixture, plus a receipt naming what stayed private.
Decision
Publish fixture data and redacted screenshots for the public proof, never live internals.
Consequences
Visitors can inspect the mechanism, while raw auditor reports, private repo names, inbox state, tokens, agent logs, and machine-specific state stay out of the public path. The proof is narrower than the private system, by design.
What would change my mind
If a public artifact ever needs live private inputs to be convincing, the artifact is shaped wrong. Build a better fixture or do not publish it.
first written up in: Showing the Operator OS without leaking it
2026-06-27 accepted The apps shelf ships link-free
Context
The apps page is a visual shelf for native builds. Its live copy says screenshots are public-safe local captures, that App Store availability is not claimed, and that public links arrive only after independent verification.
Decision
Show the native app artifacts without source or store calls to action until release status is independently verified.
Consequences
The page can make the Swift and Metal work inspectable without laundering local build evidence into a public release claim. The trade-off is obvious: interested readers cannot click through yet.
What would change my mind
When an app has a verified public source link, TestFlight, App Store page, or release receipt, add the link with the evidence beside it.
Addendum (2026-07-07): the trigger fired for verification receipts
The portfolio verification campaign produced real, independently generated verification receipts for the repos behind part of this roster. That is exactly the "release receipt ... with the evidence beside it" condition above, so /workshop entries whose repo carries a receipt now link to it in plain text. Entries without a receipt say "not independently verified" out loud. The original rule stands for everything else: no store links, no availability claims, and no status language that is not backed by evidence.
first written up in: The apps shelf
2026-06-20 accepted FTS5 over a vector database for agent memory
Context
The memory layer had missed recalls, and the obvious modern answer was a hybrid vector search stack. The public field note says the dry run found a different bug: the missing rows were never written, so semantic search would not have recovered them.
Decision
Use SQLite FTS5 and BM25 for bridge memory recall until the corpus actually shows a semantic gap.
Consequences
This bought deterministic local search, no embedding service, no network hop, and one less cross-machine dependency. It also means the system is deliberately not optimized for large, messy, many-author text yet.
What would change my mind
If the corpus grows across many authors or the query language stops matching the way records are written, bring the hybrid vector plan back with an eval that proves the gap.
first written up in: Why bridge-db runs on FTS5, not a vector database
2026-06-20 accepted Freshness envelopes over silent stale answers
Context
A dashboard can be worse than down when it serves old data with a confident face. The freshness note names the failure mode and the fix: every source carries age and a threshold, so stale data has a different visible shape.
Decision
Refuse stale certainty by wrapping source answers in freshness envelopes.
Consequences
The system earns trust by admitting when it does not know right now. It does not prove current data is correct, but it kills one common class of quiet lie: the answer that used to be true.
What would change my mind
If a source can prove immutable truth instead of timed freshness, it can use a different contract. Operational state changes, so it needs age, threshold, and a visible stale state.
first written up in: Teaching a system to say "I don't know"
2026-06-20 accepted No visitor tracking on the workshop
Context
The public workshop exists to show artifacts and reasoning, not to optimize visitors into a funnel. The site says it is a hand-built static file with no backend, no tracking, and no analytics.
Decision
Do not track visitors; make the work itself carry the signal.
Consequences
The site gives up growth dashboards and attribution tricks. In exchange, the privacy story is simple, the page is lighter, and the measurement pressure stays pointed at the artifacts and the author, not the reader.
What would change my mind
Only a public, privacy-preserving metric that helps keep the site honest without identifying readers. Aggregate broken-link health qualifies; behavioral surveillance does not.
first written up in: Why this is public
2026-06-20 accepted Publish decisions and receipts, not just demos
Context
The public note says the transferable part is not just the demo, but why a thing is shaped the way it is. The proof note makes the same move with receipts: claims need a place to fail if they drift.
Decision
Publish the reasoning and the receipts beside the artifacts.
Consequences
This makes the site less like a highlight reel and more like a workshop bench. It exposes costs, limits, and reversibility, which is exactly why the artifacts are easier to trust.
What would change my mind
If a decision cannot be explained from public-safe evidence, it should stay private until the operator writes the boundary deliberately.
first written up in: Why this is public
What the gates check, and what they can't
A gate before every push runs the site's checks in sequence and blocks a failing build. It pins each project's status to one canonical value and asserts every page agrees (status-claims), holds each essay's HTML against its Markdown mirror (content-parity), binds live counts to their source registries so no number is typed into prose (prose-counts), forbids em dashes and other tells (no-emdash), asserts a single labelled heading and image alts on every page (a11y), and re-runs every generator to prove they produce no drift (idempotency).
What it cannot catch is the honest part: a gate checks claims against artifacts, so it is blind to a claim nobody wrote down, an artifact that went stale without changing, and any category the sweep was never pointed at. The corrections ledger above exists for exactly the failures the gates cannot see. Publishing the limits is what makes a green check worth trusting.
It also cannot fix the shape of the evidence pool by itself. A small number of vivid incidents carry more than one argument across the book and essays, so those pieces should be read as practitioner evidence from one operator's workshop, not as certification or a claim that the same pattern has been independently reproduced.