The publication architecture Published

How a record becomes a public page, a machine document and a verifiable bundle. This architecture is fully published because it is this website, and every component of it is inspectable.

The same diagram as a table

Component	Role	Feeds into
Typed records	Claim versions, artifacts and the status ontology, in version control. The only source of truth.	Policy as code (checked by); Schema enforcement (validated against)
Policy as code	Fifteen deterministic rules plus state-machine invariants. Decides what may be published; no override path exists.	Deterministic build (gates)
Schema enforcement	Every emitted document validated against its published schema. A failure stops the build.	Deterministic build (gates)
Deterministic build	Zero dependencies. Same inputs produce the same bytes in any directory on any machine.	Human surfaces (renders); Machine surfaces (emits); Build manifest (digests)
Digest lock	Sealed digest of every published claim version. Editing a published version aborts the build.	Deterministic build (gates)
Human surfaces	Script-free pages at three depths: understand, inspect, verify.	terminal
Machine surfaces	Twenty-two endpoints, OpenAPI, schemas and portable bundles, generated in the same pass.	terminal
Build manifest	SHA-256 of every shipped file, so a reader can verify the whole site at once.	terminal

Component status

Invariants this architecture holds

• A published version's bytes never change. Editing one aborts the build.
• Human and machine representations come from one record in one pass and cannot disagree.
• Classification fails closed: absent, unknown or ambiguous means internal, and internal is never published.
• Demonstration fixtures are excluded from every scientific index, feed, sitemap and endpoint.

Each is enforced by a test that runs against the deployed bytes, not only the local build. Machine-readable architecture →

The private-to-public boundary Published

The one-way path material must travel before it can appear here. Nothing has travelled it yet.

The same stages as a table

#	Stage	What happens
1	Private environment	The authoritative scientific work. This site never reads from it.
2	Explicit export	A deliberate act, never a sync.
3	Secret scanning	MANDATORY before the first export. Not yet built, and nothing may cross until it is.
4	Sanitisation	Private inputs become attested transformations with digests, never disclosed inputs.
5	Classification	Fails closed. Absent or ambiguous means internal.
6	Licence and IP review	Ambiguous ownership is non-releasable.
7	Schema validation	Structure checked before meaning is trusted.
8	Release policy	The same deterministic rules that gate every claim.
9	Public record	Immutable, digested, citable.

Tiffany system architecture Awaiting publication

No architecture of Tiffany itself has been released. This site will not draw a diagram of a system whose topology it has not been authorised to describe — a plausible-looking architecture diagram is the easiest thing on a technical site to fabricate and the hardest for a reader to check.

Prerequisite: A separately authorised publication unit, with the same export controls that govern scientific records.

There is no diagram here, and its absence is the point. A system map is trivially easy to draw convincingly and nearly impossible for a reader to falsify, which makes it the highest-risk thing a technical site can fabricate.

Schematics

The schematic framework → — typed diagrams with versions, scopes and accessible equivalents.

Who may change this, and how

Today: humans and Claude, through an ingestion gate that fails closed, with an explicit human decision before anything is published. Later, possibly: a machine actor through the same records and the same gates, under separately qualified and revocable authority.

The future machine-operation contract → Specified and not active — no delegation exists.