About
tiffany.systems is the public research and publication infrastructure for an independent research programme. It is operated by that programme's author.
Relationship to the research programme
The scientific work happens in a private repository and is not mirrored here. This site is not a window onto it. Material becomes public only by an explicit export, sanitisation, classification and release process, and a public record may reference private ancestry only as an attestation with digests — never by exposing the private input.
This means a claim here can be traceable without being transparent all the way down, and the pages say which one you are getting: provenance completeness is one of the dimensions on every claim.
Authorship and machine operation
The infrastructure is designed so that a qualified software agent can eventually operate it — preparing publications, attaching evidence, requesting review, superseding records — under narrow, expiring, auditable and revocable capabilities rather than administrative access. Authorship, execution, review and publication authority are separate fields on every record, and no agent holds publication authority today.
Deliberately not built
Every sophisticated subsystem here had to pass the same gate: what problem, what invariant does it protect, what is the simplest mechanism that protects it, what evidence says we need it now, what does it cost to operate, and how does it fail. Components that did not pass are listed here with the condition that would change the answer. Building them anyway would have been the easier and less honest choice.
| Component | Why deferred | Build it when |
|---|---|---|
| Request-time function to normalise unknown-path 404s | The only benefit is cosmetic uniformity of a response no Tiffany endpoint produces. The cost is the first request-time executable surface on a site whose integrity properties — deterministic output, reproducible builds, no runtime attack surface, offline verifiability — all depend on having none. A runtime layer whose entire job is re-dressing someone else's 404 has not earned that. | A request-time layer exists for a reason that stands on its own — authentication, or an endpoint that can genuinely fail. Normalising 404s would then be a small addition to something already justified, rather than the justification itself. |
| Transparency log / Merkle-rooted release checkpoints | One publisher, one build path, no external replications yet. A log would add key management, availability and monitoring failure modes while detecting nothing the lock does not already stop. | A second independent publisher can write, or an external party depends on detecting equivocation between what different readers were served. |
| Signing key hierarchy and attestations | Signatures would attest to a single operator signing their own work, which adds a compromise and rotation surface without adding an independent assurance. | Publication authority is delegated to a software agent, or a second party gains release authority. |
| Full typed evidence/claim knowledge graph | A graph store answers questions nobody can ask yet at one claim identity, and would become the primary UX, which is exactly what the review forbade. | Cross-claim dependencies exceed what the precomputed queries can answer, or a claim depends on another claim's version. |
| Public graph query API | An execution surface with a complexity budget, an exhaustion attack and a data-reachability risk, in exchange for questions not yet asked. | An external replicator asks for a question the bounded set cannot express, twice. |
| SciBOM (scientific bill of materials) | The fixture has three dependencies. A separate BOM format would be ceremony around a list that already exists in the record. | A finding depends on a build environment or model lineage that cannot be expressed as pinned dependency references. |
| Accounts, API keys, rate limits, entitlements | Everything published is public. An auth system would create a credential store, a breach surface and a privileged path to protect, guarding nothing. | A non-public tier exists, or abuse makes anonymous access unworkable. |
| External replication gateway | An intake pipeline needs quarantine, malware scanning, licence review and identity before a first submission exists. | A third party executes a published challenge contract and asks where to send the evidence. |
| Grounded laboratory assistant | An assistant over one fixture claim would be a demonstration of an assistant, not of a laboratory; the prompt-injection surface through ingested metadata is real and the benefit is currently zero. | There are enough published claims that navigation, not comprehension, is the reader's bottleneck. |
| Zero-knowledge and selective disclosure | No concrete disclosure need exists. Cryptographic complexity added speculatively is a failure mode looking for an occasion. | A specific releasable property of a specific unreleasable artifact must be proven to a specific party. |
| Federation and preservation mirrors | Mirroring an empty scientific index federates nothing. The bundle format is the part that has to be right first, and it exists now. | A real finding is published, or a preservation partner is identified. |
| Module and dataset registries, release downloads | There is nothing authorised for release. Building a registry now would hard-code today's assumptions about things that do not exist. | A module or dataset is cleared for public release. |
| Database, search index, server-side rendering | At this corpus size a database would add an availability dependency and a tamper surface to a corpus that fits in a directory. | The corpus stops fitting a full-rebuild-per-change model. |
Machine-readable: /api/deferred.json.
Contact
There is no contact form, no newsletter and no account system. Challenges to a claim are the intended channel, and they are structured objects rather than messages — see methodology.