Governed by itself
Every BlackLake release is approved through BlackLake.
When we deploy the API or the console, or publish the npm package, the command runs through blx, our own shell wrapper. It calls the same govern() endpoint we sell, blocks until a human approval is recorded, and writes a signed receipt to the same tamper-evident ledger every customer workspace gets. This page is the public record.
The mechanism
How a release crosses the line
Stage
Work queues behind a gate: tests green, adversarial review passed, blast radius traced, and the rollback target recorded before anything touches production.
Classify
The deploy or publish command is wrapped in blx, which classifies it as irreversible and calls govern() against our own workspace.
Approve
govern() returns approval_required. The command blocks until the release authority approves; the approval is recorded with the approver, the channel, and the timestamp.
Receipt
The command runs, its exit code is recorded, and the decision receipt lands on the append-only hash chain alongside every other governed action in the workspace.
Release recipe (excerpt)
# The deploy step from our own release recipe. blx classifies the# command as irreversible, calls govern(), and blocks until a human# approves. The approval and the outcome land on the audit ledger.blx gcloud run deploy control-plane-api \ --image ${REGISTRY}/control-plane-api \ --region europe-west2# Publishing the npm package crosses the same line:blx npm publish --access publicThe record
Governed releases
Identifiers appear exactly as recorded in the internal release log, including truncation where early entries truncated them. Releases from 24 July 2026 onward publish their ids in full. Decision tokens join each entry as soon as our release tooling surfaces them (the improvement is logged and tracked here honestly); a published token lets anyone verify the receipt anonymously at POST /v1/decisions/verify. Publishing the entry is a step in the release recipe itself.
One honest caveat: this marketing site deploys automatically on a git push, so a site release carries a staged rollback and a recorded deploy SHA but no govern() receipt of its own yet. Site changes are listed here as part of their release batch; the receipts belong to the API, console, and npm steps.
blacklake 1.1.1, and BlackLake joins the official MCP Registry
Metadata patch carrying the MCP Registry name. The npm publish ran through blx: govern() returned approval_required, the release authority approved on record, and the publish completed. First release since this page shipped, so the ids below are published in full. The decision token is not yet in this entry: blx does not print it in its receipt output today; that improvement is logged and tokens appear here as soon as it lands. After the publish, systems.blacklake/gateway went live on registry.modelcontextprotocol.io under DNS-verified domain ownership.
Receipts
- approval_74f7b30b05024bf5a81bdd41efffb09d · eval_54872a2ea2cf483588785e11a50951e8
July audit batch: API, console, blacklake 1.1.0, site
Seven correctness fixes plus three product features from a five-surface audit, released to all four targets in one session. The API and console deploys and the npm publish each ran through blx with a recorded approval; health checks and a tag-URL verification passed before traffic promotion. The site rode the same release train.
Incident
The first API promotion served 500s on govern() for about six minutes: the inline release recipe had skipped a database migration the new code depended on. We rolled back to the previous revision first, diagnosed after, ran the migration, verified the fix on a tag URL, and re-promoted. The recipe now runs migrations unconditionally before any deploy. The rollback and the re-release are both on the ledger.
Small-debt sweep: audit stream fix, console copy, site CSP
Audit SSE stream now flushes its connection comment immediately in production, console settings copy cleaned up, site image CSP tightened. Both service deploys governed through blx and verified live.
Receipts
- approval_6c403f7f… · eval_7e33a4d6…
- approval_33cda6ba…
Console overhaul complete: data legibility and tabbed settings
Ships 3 and 4 of the console overhaul: readable evaluation rows with action summaries and policy names, and a tabbed settings page. Verified live; all five overhaul ships now in production.
SSE polish and console wordiness sweep
Live-refresh connect time cut from roughly 15 seconds to under 2 by flushing a connected comment on open. Dashboard copy now leads with data instead of taglines. Both verified in production.
blacklake 1.0.0, published under its own governance
First stable release of the unified package. The npm publish itself ran through blx: policy-checked, blocked on a recorded human approval, then executed and receipted on the tamper-evident ledger. The same day, a security redeploy of the API (hono CORS fix and a transitive shell-quote patch) went out through the same path.
Receipts
- approval_0d8e2230…
Why publish this
Because you should not have to take our word for it
Every governance vendor says “trust us”. We would rather show you the same evidence trail we ask you to hold your own AI Actors to. If our governance layer went down, our own releases would stop. If we skipped the approval, the receipt would not exist. If we tampered with the record afterwards, the hash chain would break. That is a stronger claim than a testimonial, and it is checkable.
- Verify a receipt: the verification page explains the HMAC check and lets you run one.
- Verify the ledger: the audit trail is an append-only hash chain. Any workspace can run
bl ledger verifyat any time; so can we. - Read the incidents: when a release goes wrong, it goes on this page and in the transparency report, with the rollback on the same ledger as the deploy.
Govern your own releases the same way.
blx ships in the blacklake package. Wrap a deploy command, set a policy, and your next release blocks on a recorded approval too.