Public Record

ETCHED IN STONE

What was published, and when, on the record

A record that can be quietly rewritten is not a record.

Forecasts, claims and writings are published, and then edited. The miss becomes a hit, the date moves, the wording softens, and a reader looking at the page today has no way to know it differs from the page as first published. Screenshots and archives help only if someone took them, and they say nothing about who published what.

Etched In Stone is Watchfire AI's public, append-only record. Each application publishes entries into its own record with its own sequence; Fireball's forecasts were the first. Every entry is stored exactly as published, fingerprinted, timestamped by two independent timestamp authorities and anchored to the Bitcoin blockchain, then rendered with its proofs and a downloadable evidence archive. Change one byte and the proofs fail; remove an entry and the sequence shows the gap. Verification needs nothing from Watchfire: the record, the proofs and standard public tools are enough.

Seven steps. The bytes are fixed first; every proof is about those bytes.

Each step produces a recorded artifact before the next begins, and nothing is published until every proof that must exist at publish time exists. What each step produces:

IN
Entry
S1
Accept
S2
Sequence
S3
Canonicalize
S4
Timestamp
S5
Anchor
S6
Record
S7
Publish

What each step produces

S1 AcceptA payload validated against the publishing contract, and a ticket; nothing is written yet
S2 SequenceThe entry's public id, next in its application's series, placed inside the bytes that will be stamped
S3 CanonicalizeOne exact byte sequence in canonical form, and its SHA-256 fingerprint
S4 TimestampTwo signed tokens for that fingerprint from independent RFC 3161 timestamp authorities
S5 AnchorAn OpenTimestamps receipt from public calendars, upgraded to a Bitcoin block on the hourly run
S6 RecordThe bytes, the proofs and a downloadable evidence archive, stored once and never rewritten, with the registry row that assigns the id
S7 PublishStatic pages rendered from the stored record, each passing an integrity check against it before it is served

What holds for every entry, enforced in code.

The bytes are fixed before any proof is made, and every proof is about exactly those bytes. Two independent timestamp authorities and the Bitcoin blockchain attest that the record existed by the times shown. Change one byte and verification against the original proofs fails. Entries are appended, never substituted; a correction or an update sits beside what it follows. The entry's id is inside the stamped bytes, so a removed entry leaves a visible gap in its sequence. If a timestamp receipt cannot be obtained, nothing is published. Verification needs nothing from Watchfire: the record, the proofs and standard public tools are enough.

Serverless on AWS, one serial writer, append-only at the core.

Entries arrive through a private path on Watchfire's staff portal, gated by signed cookies, and reach a small API on AWS Lambda that validates the entry and issues a ticket. An Amazon SQS FIFO queue delivers each job to one serial worker, so publishes never interleave. The worker canonicalizes and fingerprints the entry, obtains the two RFC 3161 tokens and the OpenTimestamps receipt, writes the bytes, proofs and evidence archive to Amazon S3 and the registry row to Amazon DynamoDB, renders the static site and invalidates Amazon CloudFront. An Amazon EventBridge schedule runs the worker hourly to upgrade pending receipts to Bitcoin blocks, retry any missing token and re-render every page.

Sources1 Intake2 Queue & Worker3 Proofs4 Record5 Targets6 Fireball ListingFirefly 4.0 Direct submissionsJackRoelofs.com writings OperatorsHQ in Firefly 4.0 Amazon CloudFrontstaff portal pathsigned cookies AWS Lambdaeis-api: validate,issue a ticket Amazon SQS FIFOone job at a time AWS Lambdaeis-worker: fingerprint,stamp, write, render Amazon EventBridgehourly upgrade run Timestamp authoritiestwo, RFC 3161 OpenTimestampspublic calendars Bitcoin blockchainanchor within hours Amazon DynamoDBregistry: ids, proofs status Amazon S3bytes, proofs, pageswritten once etchedinstonewatchfireai.comvia Amazon CloudFront Readersverify in the browser Standard toolsshasum, ots, opensslon your own machine

Steps

1 SourcesApplications that publish: Fireball's Listing today, direct submissions; operators reach HQ inside Firefly 4.0
2 IntakeA private path behind the staff portal's signed-cookie gate reaches an IAM-authorized API that validates the entry and issues a ticket
3 Queue & WorkerA FIFO queue feeds one serial worker; an hourly schedule re-runs it for upgrades, retries and re-rendering
4 ProofsTwo timestamp authorities sign the fingerprint at publish; the OpenTimestamps calendars anchor it to a Bitcoin block within hours
5 RecordBytes, proofs and evidence archives in S3, written once; ids and proof status in DynamoDB; append-only
6 TargetsCloudFront serves the public site, a machine-readable index and the evidence archives to readers and to standard tools

Existence and integrity are proven in public. Authorship, order and completeness are not yet.

The proofs establish that each exact record existed no later than the attested times, and that it has not changed since. They do not establish who authored it beyond the domain it is served from, they do not bind the order of entries beyond their timestamps, and they do not prove that nothing has been removed after the last entry. Those three, a signing key per publisher, a per-series hash chain and periodic signed completeness roots, are the open items before the record is offered to third parties, and they are stated on the record's own verification page.

Deliberately absent from this page: the canonical form specification, the contract fields, calendar and authority endpoints, and infrastructure identifiers. The method is described to the level at which its guarantees can be judged, not reproduced.

Ready to learn more?

Discuss putting your own published claims on the record: forecasts, analyses, statements, or the outputs of a system you run, each entry verifiable by anyone.

Get in Touch

We'll respond within two business days.

Message sent.

We'll be in touch shortly.

Download Document

Please provide the following to access the document.

Starting download…

If the download does not begin automatically, click here.