Release evidence
Which release is running
Section titled “Which release is running”The public health response names the exact commit the deployment was built from, and every response carries it as a header:
curl -sI https://api.bitcoinuniverse.io/health | grep -i x-universe-releaseThat commit is Core’s release identifier. There is no semantic version string, and this documentation will not invent one.
What a release has to pass
Section titled “What a release has to pass”Changes are validated before publication by automated checks that build the application and exercise its safety-sensitive paths.
- Build and test on the organization-managed runner fleet. Jobs use the runner labels declared by the current workflow. A scheduled or cancelled check is not a passed check.
- Generated route ownership. The browser inventory is generated from the production router. A missing route, stale entry, invalid redirect, unrepresented parameter, or missing quality owner fails validation.
- Browser and accessibility gates run in Chromium, Firefox, and WebKit at phone portrait, phone landscape, tablet, desktop, and wide desktop sizes. The narrowest required reflow check is 320 CSS pixels.
- Truthful state fixtures exercise populated, empty, partial, failed, slow, stale, offline, large, and edge-case data where a route family supports those states. Unmatched reads and attempted mutations fail the fixture gate.
- Screenshot comparison against the exact artifact that passed those gates, rather than a second compilation. Material route families and UI compositions are checked in both themes with exact pixel comparison on the certified visual host.
- Database rehearsal on both MySQL 8 and MariaDB 10.11, comparing semantic column types, constraints, checks, triggers, idempotent reruns, and guarded rollback, so a harmless display difference cannot weaken or wrongly block the same safety contract.
- Production freshness checks using a repository-scoped pinned deploy identity with bounded timeouts and retries. Exhausting those retries fails closed before release links change; it never permits a cached candidate to bypass exact verification against the main branch.
The deployment health gate
Section titled “The deployment health gate”The deployment health check respects the selected marketplace profile.
- A read-only release requires healthy database-backed application reads and a validated private Bitcoin chain-tip read, and keeps transaction traffic explicitly closed.
- A mutation-ready release is accepted only after three complete healthy refresh cycles across every protocol authority.
This is what prevents a generic healthy response from being mistaken for permission to list, buy, or make offers. Health and readiness shows how that gate is reported.
After activation
Section titled “After activation”A recurring check runs against the live public surfaces every ten minutes. It confirms the published release marker, the fee response, anonymous collection activity, and that the live event stream stays open for a full observation window and keeps sending keepalives that do not advance a reader’s position.
Deeper sweeps that place real load on Universe-operated services are reserved for release rehearsal and are not part of the recurring check.
Control Center evidence
Section titled “Control Center evidence”The restricted Inscribe Control Center can also read Core’s release identity, health, readiness, and recent run history through a private, authenticated adapter. This gives operators one correlated view without turning operational controls into public Core endpoints.
The adapter is evidence, not an override. A healthy row does not bypass Core’s marketplace gates, and an action remains closed when Core’s own policy or readiness checks reject it. The public health response above remains the safe way for readers to verify the deployed Core commit.
Read the Inscribe Control Center guide for the user-visible boundaries of that restricted workspace.
What a passing result claims
Section titled “What a passing result claims”A passing validation result is release evidence. It is not a claim that a change has already reached production, and it is not a claim that every production gate is enabled.
The Marketplace code is a validated release candidate. Protocol authorities, protected configuration, live readiness checks, and funded canaries must pass before production execution is declared available.
Some platform-specific compatibility probes require a dedicated environment and run only when that environment is explicitly available. They do not weaken the safety or availability checks for the supported release paths.
This documentation site
Section titled “This documentation site”Its own gates run on every change:
| Check | What it enforces |
|---|---|
| Copy rules | No em dash, no banned word, no unsupported superlative, no placeholder |
| Public safety | No private hostname, IP address, port, or credential-shaped string |
| Manifest | docs.manifest.json validates against the platform schema |
| OpenAPI | The document parses as OpenAPI 3.1 and contains no non-GET operation |
| Protocol matrix | Every protocol page regenerates identically from the pinned snapshot |
| Assets | No image over 200 KB |
| Markdown lint | Structure and formatting |
| Build | Every internal link and anchor resolves |
| Accessibility | Automated audit of every built page, in both themes |
| Search and sitemap | The search index and sitemap exist in the build output |