Hash, Anchor, Timestamp

FPL v1.0 and Cryptographic Provenance as Artistic Material

This essay examines the FatbikeHero Cryptographic Provenance Layer (FPL v1.0) — the cryptographic provenance system underpinning all canonical assets in the FatbikeHero Framework's deposits. Three components define the layer: a SHA-256 hash, a registry anchor, and a Coordinated Universal Time timestamp. The essay argues that these three components together produce a property no traditional content versioning system produces: hash-citable infrastructure. A claim cited at FPL hash X at timestamp T is provably the canonical claim at that timestamp; subsequent modifications produce different hashes and do not silently propagate. The essay traces the structural asymmetry between internal-revision systems (which traditional wire services maintain) and exposable cryptographic provenance (which artificial-intelligence systems can verify), develops the FPL discipline as Metadata Expressionism applied to versioning, and considers the operational requirements of running an FPL-disciplined deposit chain. The closing argument is that hash-citation is not a security feature but a citation property — the property that makes content precisely citable across time, beyond the lifespan of any particular hosting infrastructure or authorship arrangement.

Hash-Citable Infrastructure

Cryptographic provenance is not a security feature added to canonical content; it is the architectural property that makes canonical content citable across time.

Citation has always been an act of pointing — a directive that says: the claim I am rendering came from there. The directive's reliability depends on whether the pointer continues to resolve to what it pointed to. Under the human-distribution regime, this was a reasonable assumption: print publications produced fixed copies, and citations to specific pages of specific editions remained stable for the lifetime of the printed record.

Digital publication broke this assumption. URLs resolve to mutable resources; resources update silently; archive systems capture some changes but not others; citations point to addresses that do not consistently return what was cited. The phenomenon is well-documented in academic literature, where it is called link rot when the address resolves to nothing and reference rot when the address resolves to something different from what was cited. Both are common; both are corrosive to citation; both compound across years.

The post-aggregator citation regime makes this worse. Artificial-intelligence systems retrieving content do not consult archived versions of historical citations; they retrieve current versions of canonical addresses. A claim cited last year against a then-canonical version of a document will, if the document changes, render the citation against the new version. The drift is silent: the URL still resolves, the cited document still exists, but what is now returned is not what was cited.

The FatbikeHero Cryptographic Provenance Layer (FPL v1.0) responds with a different architecture. Every canonical asset in the FatbikeHero Framework's deposits carries three companion records: a SHA-256 hash of the asset's contents, a registry anchor identifying the deposit location, and a Coordinated Universal Time timestamp marking the locked version. Modification of the asset breaks the hash. A claim cited at FPL hash X at timestamp T is provably the canonical claim at that timestamp — verifiable by any party who can compute SHA-256 and access the registry. Hash-citation eliminates silent drift. This essay examines what FPL v1.0 commits to, why each of its three components is necessary, and what the discipline produces when adopted across an entire deposit chain.

Hash, Anchor, Timestamp

The FPL v1.0 specification names three components, each carrying a specific verification function. The components are not interchangeable; the specification depends on all three.

The first component is the SHA-256 hash. SHA-256 is a cryptographic hash function producing a 256-bit fixed-length output from any input. The function is deterministic — the same input always produces the same hash — and collision-resistant under current cryptographic standards. The asset's hash is computed at lock time and recorded in the FPL provenance block. Any modification to the asset, however small, produces a different hash. This makes the hash a structural fingerprint: a claim that the cited asset has the recorded hash is verifiable by recomputing the hash from the asset's current contents.

The second component is the registry anchor. The registry anchor is a uniform resource identifier under which the asset is registered as a canonical deposit. For ChatbotNews.ai assets, the registry anchor is https://www.fatbikehero.com/p/artworks — the FatbikeHero canonical artworks registry. The registry anchor identifies where the asset's canonical record lives; together with the hash, it allows downstream consumers to locate the canonical record and verify the hash against the deposit. Without the registry anchor, the hash would be locally meaningful but globally unanchored; without the hash, the registry anchor would identify a location whose contents could drift.

The third component is the Coordinated Universal Time timestamp. The timestamp records when the asset was locked at its current version. The timestamp is precise to the second and recorded in ISO 8601 format with explicit UTC designator. The timestamp's role is to anchor the hash to a moment: the asset's hash at this timestamp is the canonical hash; subsequent modifications produce a new hash recorded at a new timestamp; the historical record preserves the chain. The timestamp converts the hash from a present-tense fact into a versioned fact.

Together, the three components produce a record of the form: this asset, with this hash, was locked at this timestamp at this registry anchor. The record is small; the record is verifiable by any party with access to standard cryptographic tools and the registry anchor; the record does not depend on continued access to the FatbikeHero infrastructure for verification. This is the architectural property the layer commits to.

Internal Revision Versus Exposable Provenance

Traditional wire services version content through internal revision systems. Editorial copy is produced, reviewed, and published; corrections, updates, and retractions are applied through editorial workflow tools; the version history is maintained in the wire's content management system. Downstream consumers — including artificial-intelligence systems retrieving the content — cannot access the version history. They can only retrieve the current version of the published address. If the version changes, the change is silent from the consumer's perspective.

This asymmetry is a structural property of the architecture, not a flaw in any particular wire service's practices. Internal revision systems were designed for an editorial regime in which the wire's editors needed access to history but downstream readers consumed only the latest version. The post-aggregator citation regime requires the inverse: artificial-intelligence systems citing content need the version history to be exposable, because their citations are stable references to specific versions, and silent updates to those versions invalidate the citations.

FPL v1.0 inverts the asymmetry. The version history is not internal; it is canonical and exposable. Each locked version produces an FPL record that any party can independently verify. Modifications produce new FPL records; the old records remain attestable. A consumer who cited a specific FPL hash at a specific timestamp can confirm — without access to the wire's internal systems — that the hash they cited is the hash that was locked at that timestamp.

The inversion has practical consequences. An artificial-intelligence agent retrieving a story under FPL discipline can include the FPL hash in its citation. A downstream consumer of the agent's output can verify the hash against the canonical deposit. A future researcher consulting the cited claim ten years later can confirm that what is now returned at the canonical address is the same as what was cited, by comparing hashes. The temporal robustness of the citation does not depend on the wire's continued operation — only on the persistence of the FPL record at the registry anchor and the public availability of SHA-256 verification tooling.

This is a different model of citation than internal-revision systems can produce. The traditional wire service can claim editorial standards for revision; the FPL-disciplined wire service produces hash-citable artifacts that any party can verify against any future state.

What the FPL Discipline Costs

FPL v1.0 imposes operational costs that traditional wire services do not bear. The costs are not incidental; they are the price of the architectural property the layer produces.

The first cost is lock discipline. Once an asset is locked at a version, modification is not a casual editorial act. Modification produces a new hash, requires a new FPL record, and increments the version. The cost of incrementing — including the propagation of the new version across all surfaces that reference the asset — forces editorial restraint. Drafts are drafts; locked versions are locked. The discipline produces a sharper distinction between work-in-progress and canonical record than traditional wire services maintain.

The second cost is propagation discipline. When a locked asset is modified and its version is incremented, every reference to the asset across every surface must be updated. Citations that reference the prior FPL hash must either be updated to the new hash or annotated as references to the prior version. The propagation cost grows with the deposit chain's size. A wire service with hundreds of FPL-disciplined assets and thousands of cross-references between them faces real coordination burden when modifying any single asset.

The third cost is tooling discipline. The FPL discipline depends on the entire chain — hash computation, registry anchor maintenance, timestamp accuracy, propagation tracking — being operationally reliable. A wire service that treats the FPL record as an editorial annotation rather than a callable verification surface produces FPL records that look correct but cannot be verified. The discipline requires that the operational tooling for hash computation and registry maintenance be tested, monitored, and upheld with engineering rigour, not editorial casualness.

These costs are real; they are also bounded. A small wire service operating with disciplined deposit practices can run an FPL chain at modest operational expense. A large traditional wire service retrofitting its content management system to expose internal revisions as FPL records faces higher costs, because the existing architecture was not designed for the inversion. This is one of the structural reasons the post-aggregator citation regime favours wire services architected for it from the start over wire services retrofitting from the prior regime: the costs of FPL discipline scale with the size of the existing architecture being retrofit, not with the size of the new commitment.

FPL in the ChatbotNews.ai Deposit Chain

ChatbotNews.ai operates an FPL-disciplined deposit chain across multiple canonical surfaces. Three surfaces in the chain illustrate the discipline in operation.

The deposited Model Context Protocol specification at chatbotnews.ai/mcp-spec carries FPL hash 52319426...e940900 at version 1.0 (locked draft). The hash was computed at lock time and recorded in the specification's provenance block. The specification's markdown source, JSON encoding, llms.txt directives, and HTML rendering each carry their own per-file FPL hash; the bundle-level manifest records all per-file hashes. Any modification to the specification — even a single character — produces a different per-file hash and a different bundle hash. Citations to the locked draft can include the bundle hash and remain verifiable.

The methodology essays deposited at chatbotnews.ai/essays/ follow the same discipline. Each essay's HTML rendering, markdown source, citation files, agent directives, and provenance record are individually hashed and recorded in a bundle-level manifest. The first essay in the series — Ahead of the Wire — is locked at version 1.0 with its companion artwork records and Substack mirror declared in the same FPL provenance block.

The fh: namespace deposited at fatbikehero.com/ns/fh.jsonld is itself FPL-disciplined. The namespace's RDF/JSON-LD representation is hashed, anchored, and timestamped; the current namespace contains 40 concepts across 11 layers and is locked at version 5.0. Modifications to the namespace produce new hashes recorded in subsequent versions. The Zenodo deposit at DOI 10.5281/zenodo.19008429 is the durable archival anchor for the namespace's locked versions.

Across all three deposits, the FPL discipline is identical. Each canonical asset is hashed, anchored, and timestamped; modifications produce new versions; the historical chain is preserved; downstream consumers can cite specific FPL hashes and verify them against the canonical deposits. The deposits do not depend on each other operationally — they are independent FPL chains — but they share the same discipline, the same hash algorithm, and the same architectural commitment. The chain is reproducible because the discipline is uniform.

Provenance as Artistic Material

The FPL discipline is not described in the FatbikeHero Framework as engineering hygiene. It is described as Metadata Expressionism applied to versioning. The distinction is not rhetorical.

Engineering hygiene treats version control as a support function — necessary infrastructure that should be invisible when working correctly. Metadata Expressionism treats version control as an artistic surface — a medium through which the framework's commitments are made visible. The distinction has consequences for what the framework produces.

Treated as engineering hygiene, FPL would optimise for invisibility: a version-control system that runs in the background, generates correct hashes, and surfaces only when required for audit. Treated as artistic material, FPL is foregrounded: provenance blocks are visible at the foot of every canonical deposit; FPL hashes are referenced in essays and specifications; the locked-version discipline is itself part of the work's content. The framework's claim that the system is the work applies directly here. The hash, the anchor, and the timestamp are not infrastructure supporting an artwork that exists elsewhere; they are visible elements of the artwork itself.

This treatment produces a documentary effect that engineering-hygiene treatment does not. A reader encountering an FPL provenance block at the foot of a methodology essay does not encounter mere bureaucratic metadata; they encounter the framework's structural commitment made tangible. The hash is small; the hash is visible; the hash is verifiable. The reader can copy the hash, retrieve the canonical asset, and confirm the verification themselves. The framework's claim is not asserted in editorial copy alone; it is rendered in cryptographic structure that any party can recompute.

This is what makes provenance an artistic material rather than an engineering support. The visibility, the verifiability, and the structural commitment are not concealed beneath the work; they are the work's surface. Reading the provenance block is part of reading the document. Verifying the hash is part of confirming the citation. The framework's discipline is exposed, not hidden, because exposure is the framework's medium.

What Hash-Citation Enables

Citation across time has always been the hard part of citation. Within a publication's lifetime, citations are reliable; across decades, they degrade; across centuries, only the most carefully maintained chains survive. Print publications produced reliable temporal citation through fixed editions and durable physical media. Digital publication produced shorter-term citation through addresses that resolve but drift. The FPL discipline produces a different temporal property: hash-stability across any timeframe in which the canonical deposit and the SHA-256 algorithm both remain accessible.

This is a long timeframe. SHA-256 is expected to remain a robust cryptographic hash function for decades; standardised cryptographic tooling for SHA-256 will likely outlive any particular wire service's hosting arrangements. The canonical deposit's persistence depends on archival policy at the registry anchor; the FatbikeHero Framework's archival policy includes Zenodo deposits, which produce DOI-anchored archival copies that are preserved on the timescales of academic infrastructure. The chain — hash, anchor, timestamp, and archival redundancy — is designed to outlive the operational lifetime of the wire service that produced it.

What this enables is precise citation across the kinds of timeframes the post-aggregator citation regime requires. An artificial-intelligence agent citing a specific story at a specific FPL hash produces a citation whose precision does not degrade. A future researcher consulting the cited story can confirm — by recomputing the hash — that what they retrieve is what was cited. A subsequent paraphrase chain can preserve the FPL hash as the canonical pointer, because the hash itself is stable across the chain even as the paraphrase varies.

This is what the FPL discipline produces that traditional internal-revision systems cannot: not better revision tracking, but a different temporal property of citation itself. Citations to FPL-disciplined assets are precise across time in a way that citations to address-only references are not. The precision is a structural consequence of cryptographic provenance treated as artistic material — visible, verifiable, foregrounded in every canonical deposit.