Consume a pinned release

Release identity, exact downloads and the limits of this pilot.

Consume a pinned release

1. Obtain a publication release ID through a trusted channel. It is the SHA-256 of the exact delivery manifest bytes.
2. Fetch that manifest and verify its SHA-256 before trusting its file list.
3. Download the selected collection. Check every listed file’s size and SHA-256; filenames alone are insufficient.
4. Check citation records carry the manifest’s accepted dataset digest. This consistency check does not independently prove membership in that dataset.
5. Keep the pin with your citations and review evidence. A change feed may select work, but never replaces byte verification.

The catalogue links to the manifest, ZIP collection and provision pages for this pilot. Download URLs address exact bytes by hash; the manifest maps each hash to its original artifact path.

Three different data identities

• Publication release ID: identifies the delivered file list and its hashes, including documentation and policies.
• Accepted dataset digest: identifies the accepted dataset under Contract 14 and is embedded in citation targets.
• Catalogue digest: identifies the consumer catalogue. It is not the accepted dataset digest.

The policy-set ID identifies the exact pilot policy document. It is not a record of approval or acceptance.

Scope and evidence

The pilot includes one complete instrument’s canonical Markdown and whole per-instrument consumer files. The public profile excludes the full accepted dataset lock. Its manifest authenticates delivered bytes against a trusted pin; accepted dataset membership is a publisher attestation. It is not a compact replacement for independently verifying the full dataset lock.

Other instruments, proof images, reconstruction assets, hosted search, amendment forecasts and live freshness observations are outside this pilot collection. No schema registry entry implies that every referenced artifact is included.

The private build verifies a single committed producer snapshot against its accepted lock, a passing acceptance receipt, source identities and recorded proof. The public verification summary reports these checks without distributing raw receipts, proof records, engine contracts or the full source registry. Certificate digests are reported, not independently recomputed; the website layout is not certified.

Documentation API

The generated /openapi.json, /api/docs/ files and /.well-known/api-catalog describe this documentation site’s API. llms.txt links to the public Data index as well as the documentation. They do not describe a legislation query or publication API. Provision text and exact downloads bypass the documentation Markdown export path.

Verify a downloaded file

Save the manifest as manifest.json and an exact file download as artifact. Run this Node.js example with the trusted publication ID and the original artifact path as its two arguments. This checks delivery integrity of one file; the private build loader additionally checks profile completeness, accepted-lock identities, source evidence and published schemas. Those private checks are publisher attestations for this public collection.

import { createHash } from "node:crypto";
import { readFile } from "node:fs/promises";
import assert from "node:assert/strict";

const [pin, path] = process.argv.slice(2);
const digest = (bytes) => createHash("sha256").update(bytes).digest("hex");
const manifestBytes = await readFile("manifest.json");
assert.equal(digest(manifestBytes), pin, "Wrong publication manifest");
const manifest = JSON.parse(manifestBytes);
const entry = manifest.files.find((file) => file.path === path);
assert.ok(entry, "Artifact is not listed");
const bytes = await readFile("artifact");
assert.equal(bytes.byteLength, entry.bytes, "Wrong file size");
assert.equal(digest(bytes), entry.sha256, "Wrong file hash");
console.log("Verified exact artifact against the pinned delivery manifest");

Repeatable builds

The website build requires an explicit local release store and publication pin. A verified cached copy is valid; a missing or changed required artifact stops the build.

The separate exporter can read the producer checkout. The consumer build can run with that checkout absent and does not fetch legislation from the Register.

Read, select and expand

Start at Legislation. Each included instrument opens its canonical contents, with full-instrument reading and focused Part or file views over the same publication. Containers include their ordered canonical descendants; related definitions and references may point outside that selection.

The reader’s Data and details link retains the selected scope. Scope membership lists canonical paths and file hashes, so software can check what was supplied. Reading URLs include the publication ID; links without a pin are convenience entry points, not reproducibility identities.

Browse supported records

The Data index links to every included record family, complete paginated records and exact downloads. It also links to fingerprints, published JSON Schema sidecars and a public source summary.

Schemas describe the published record shapes. JSON Schema validation does not reproduce every Effect refinement. This website’s public projection is experimental (public-pilot-2); no production compatibility promise or freshness SLA has been approved.

Verification and privacy boundary

Verification and dated status separates consumer-checkable delivery hashes from publisher-attested acceptance, proof and observation facts. The private lock hash identifies the publisher’s basis, but the lock is not available through this pilot and that hash alone cannot verify dataset membership.

No raw proof/acceptance records, render artifacts, internal contracts, telemetry or run logs are in the public download. Source images are not distributed; the Cyber instrument’s Coat of Arms is represented by an omission note. No public change feed or live-status claim is made.

Public manifest profile

public-pilot-2 identifies this experimental delivery profile. files lists public paths, hashes, byte lengths and families; selectedSlugs defines the selected instrument set; verificationLevel is delivery-integrity-with-publisher-attestation; omitted explicitly lists unavailable inputs and capabilities.

catalogue.json lists tracked metadata and which instruments are included. sources.json is the source-identity subset of verification.json; stability.json projects the supported families’ published compatibility metadata. The private build-input manifest is not published. Public policy and service commitments remain unapproved as stated in the policy notice.

This is a pass-only publication profile: a publication is built only when all included instruments pass the private acceptance and recorded-proof checks. It has no failing-publication state and no live-status feed. Source observation status is the producer’s attested state at the recorded ISO date-time, not a statement of current law.

The omission and verification-basis lists are explanatory prose, not machine enums. Schema generation, tooling, documentation and policy changes can change the publication ID while the accepted legislation dataset stays identical.