Verified environmental conditions, sealed at the moment they happen.
A method for capturing physical-world observations from authoritative public sources and committing them to a permanent public ledger — such that any party can later establish what was published, by whom, and when, without trusting the party that recorded it.
Section 1The problem
When a dispute turns on environmental conditions — a vessel grounding, a flood claim, a freight delay, a parametric insurance trigger — the parties must establish what conditions actually were at a specific place and time.
The underlying data is not the difficulty. In the United States it is public, federal, and free: NOAA, the National Weather Service, USGS and the Army Corps of Engineers publish continuously and without restriction. Anyone can download it.
The difficulty is establishing that a particular reading existed, unaltered, at a particular moment, from an attributable source — in a form that survives an adversarial process. Current practice does this badly:
- Records requests measured in weeks, for data that was public throughout
- Weather-consulting reports at $500–5,000, which the opposing party then contests
- Expert witnesses at $300–500 per hour to interpret numbers anyone can read
- Single readings from a station that may be miles from the incident, with the distance undisclosed
None of it is cryptographically verifiable. All of it is contestable. And critically, all of it is assembled after a dispute exists — by a party with an interest in the outcome.
Section 2What the system proves — and what it does not
The central design decision is the narrowness of the claim. Systems in this space typically imply they certify accuracy. That claim cannot survive scrutiny, because the source itself does not make it.
USGS publicly states that its real-time data is provisional and subject to revision, that provisional data may be inaccurate due to instrument malfunction or physical changes at a measurement site, and that users should consider this carefully before relying on it for business decisions with substantial monetary consequences. Any system built on that data inherits the ceiling.
VerApex proves provenance and integrity, not accuracy. It establishes that specific bytes were published by a named source at a named location, that they were captured at a recorded time, and that nothing has altered them since. It does not certify that any reading is correct.
This is narrower than buyers assume, and it is the reason it holds. A sealed record supports exactly four propositions:
- The recorded content was retrieved from the identified source at the identified URL
- It was retrieved at the recorded capture time
- It has not been altered since sealing, evidenced by content hash and public ledger presence
- Where a corroboration record exists — how many independent sources were examined, and whether they agreed within a stated tolerance
It establishes nothing about instrument calibration, nothing about conditions at any location other than the reporting station, and nothing about whether the source itself was correct.
Section 3Architecture
Two separations govern the design.
Source of truth is separated from index. The ledger holds the authoritative record; the query database is a projection and is never authoritative. Nothing downstream can contradict a seal, and a total loss of our infrastructure destroys no evidence. The projection is designed to be rebuildable from the ledger — we have not yet executed that rebuild, so we state it as an intent rather than a proven property.
The projection write sits outside the seal path. Wiring the database into the synchronous seal would let a database outage break a ledger write. Projection failures are logged, never fatal, and never block a seal.
What the ledger is, stated precisely. Records are signed ANS-104 dataitems written through Irys and served at gateway.irys.xyz. Irys is an Arweave bundler, and settlement to Arweave is what would make the record retrievable independently of any single operator. We have not been able to demonstrate that settlement. As of 2026-07-27 no VerApex record resolves at an Arweave gateway we did not choose, and we are seeking a definitive answer from Irys rather than restating an assumption. Until that lands, treat the durability of these records as resting on one operator, not on Arweave. The self-verifying property below is unaffected: it is a property of the bytes, not of who serves them.
Section 4Capture
Each source is polled at its own publish frequency — no faster, no slower. USGS instantaneous values publish every 15 minutes; NWS river stage publishes hourly. Polling faster returns identical bytes and consumes public API capacity for no information gain. Polling slower produces gaps.
Every record carries sourceIntervalSeconds, the source's nominal publish interval. This is the field that answers the deposition question "why is there no reading at 14:30?" — because the source published none, and the record says so.
Incremental capture
A durable watermark per (location, source) pair records the last observed epoch. On restart the collector resumes rather than re-sealing. Only genuinely new observations are written, so cost scales with new information rather than uptime.
An early implementation caught write errors and reported them as "no new data." A silent failure in an evidence system is worse than a loud one — it produces a gap nobody knows exists. Write errors are now typed and surfaced. This class of bug is the one to hunt for.
Section 5Corroboration
Multi-source agreement is the difference between a reading and evidence. One source reporting 60 mph is a claim; several independent sources agreeing is a corroborated observation.
The word doing the work is independent. Counting sources naively manufactures confidence: if source B republishes source A, treating them as two witnesses produces a corroboration that collapses the moment anyone examines the lineage.
Independence by lineage
Every source carries a lineage root. Witnesses are grouped by root before counting. A relay of another source contributes one witness, not two — and a claim supported only by relays of a single origin remains single_source regardless of how many endpoints served it.
Disagreement is published
Where independent sources disagree beyond tolerance, the system records a conflict with the observed spread. It does not average, does not select, does not resolve. The corroboration record carries the raw counts — independent witnesses, agreeing witnesses, maximum spread — as the authoritative facts. Any confidence score is a documented convenience, never the claim.
A system that always agrees with itself is a system that is hiding something. Surfacing disagreement is what makes agreement meaningful — and it is checkable by anyone, which is what makes it defensible.
Section 6Reference frames
Water level is meaningless without a vertical datum. Two stations reporting "12.4 ft" may be reporting against entirely different reference surfaces — NGVD29, NAVD88, a local gage zero, or a pool elevation. Comparing them naively produces a false conflict, or worse, a false agreement.
Every observation carries its datum, and the datum is inside the content hash. A value's reference frame cannot be reinterpreted after the fact.
Where a station's vertical datum offset has not been registered from primary authority, cross-station comparison returns INCOMPARABLE. Not a conflict — an explicit statement that the comparison cannot be made honestly.
Two stations sharing a name, two miles apart on opposite banks, were nearly registered as one location. Forcing an offset to make them agree would have manufactured evidence. Station identity is verified by coordinates, never by name. The rule exists because it was almost broken.
Section 7Sealing
Records are content-addressed: the identifier is derived from the hash of the content, making each record self-verifying. Alteration produces a different identifier, which no longer matches the ledger entry.
The raw source payload is stored once per fetch, deduplicated by content hash, and referenced by every observation derived from it. It is compressed losslessly and decompresses to exactly the bytes the source served — not a normalised or re-serialised copy.
Record structure
{ "id": "obs_98de988c71a927e6…" ← derived from the hash "locationId": "nws_btrl1" "sourceId": "noaa_nwps" "observedAt": "2026-07-24T15:00:00Z" ← when the reading happened "capturedAt": "2026-07-24T15:05:12Z" ← when we witnessed it "value": { "kind": "numeric", "v": 19.95 } "datum": "NWS_STAGE" ← hashed: frame is fixed "sourceIntervalSeconds": 3600 ← the gap explanation "raw": { "rawHash": "44136fa3…", "fetchedFrom": "https://…" } "revision": { "status": "provisional", "supersedes": null } "storage": { "kind": "arweave", "txId": "65S_Ib4EUnc4YJw…" } }
The gap between observedAt and capturedAt is itself a quality signal. Minutes indicates real-time capture. Months indicates backfill. The record states which without anyone having to trust us.
Append-only revision
Sources revise provisional data. When they do, a new record is sealed referencing the one it supersedes. The earlier record remains permanently accessible. Nothing is edited in place — the history of what was believed, and when, is itself part of the evidence.
Section 8Verification
The system is designed so that a skeptic can check it without trusting us at any step.
| Step | Action | Establishes |
|---|---|---|
| 1 | Open the ledger link on the record | The bytes exist, permanently, at a public address |
| 2 | Read the ledger block timestamp | Those bytes existed before the claim was filed |
| 3 | Hash the envelope, compare to id | Nothing was altered — the record is self-verifying |
| 4 | Fetch raw.fetchedFrom from the source directly | The source published this. We did not invent it. |
| 5 | Compare the raw payload hash to raw.rawHash | The source's exact bytes were preserved, not summarised |
Every step is something a customer could perform themselves, for free. They pay because they do not want to — they want it assembled, attested, and defensible, without spending two days of an associate's time discovering that it is.
Section 9Key custody and epochs
An evidence archive signed by a single long-lived key has a structural weakness: if that key is ever compromised, every record it ever signed becomes arguable retroactively. The forgery need not be detected to do damage — the mere possibility contaminates the archive.
Signing epochs
Record-signing keys are rotated on a schedule. A manifest declares, for each epoch, the signing address and the time window in which it was authoritative. Windows are contiguous by construction — one epoch closes at the instant the next opens — so no record can fall into a gap.
A verifier checks that a record's signature belongs to the key declared valid at its capture time. A signature from outside its own window is invalid by construction, regardless of whether the signature itself is well-formed.
The manifest is signed by a separate cold key
If the manifest were signed by the same key that signs records, an attacker holding that key could publish a competing manifest declaring whatever windows suited them. The manifest signing key is therefore held separately, never on the collector, and never network-connected. It signs a manifest twelve times a year and has no other function.
The root of trust is an address, published in three places
The manifest signer's public address — not any particular transaction — is the anchor. It is stable across every rotation, and it is published in the source repository, on the public site, and as a DNS record on the domain. Moving the root of trust requires compromising three independent credentials.
An attacker holding the manifest key could seal a competing chain — but only now. Ledger block timestamps are not forgeable. The authoritative chain is therefore the one whose genesis carries the earliest seal time, which anyone can check with no trust in us at all.
Section 10Invariants
These are enforced in code and pinned by tests, not documented as intentions. Each was defended against a decision that would have been easier to make the other way.
| Invariant | What it prevents |
|---|---|
| Never assert more certainty than the data supports | Manufactured agreement across sources or reference frames |
| Raw payloads are never discarded or mutated | A record whose bytes no longer match what the source served |
| Ledger is source of truth; all else is projection | Downstream systems contradicting the seal during an incident |
| Records are append-only | Silent revision of history |
| Capture at native frequency; gaps are stated | Interpolated values entering evidence |
| Derived data is labelled as derived | An inference presented as an observation |
| The proof stays minimal | Interpretation on-chain, inviting the argument that the record is opinion |
Section 11Limits
Stated plainly, because a paper that lists only strengths is not describing a system anyone should rely on.
The system inherits its sources' accuracy and their disclaimers. A malfunctioning instrument produces a faithfully sealed record of a wrong number. Sealing establishes provenance; it does not audit the instrument.
A compromised record-signing key can forge a record dated inside its own epoch, and the verifier will pass it — correctly, because the signature genuinely belongs to the key declared valid then. Epochs bound a compromise to one window; they do not close it. Detection narrows the window further; nothing eliminates it.
Records captured before the first manifest was sealed are declared valid retroactively. That declaration cannot be distinguished from a later fabrication. The window is fixed and finite, and it is disclosed rather than papered over.
Conditions vary over short distances. The system discloses the distance between a reporting station and a requested location; it does not assert that the station is representative of that location. That determination belongs to the person relying on it.
Coverage today is the Mississippi main stem. Many stations have no registered vertical datum, so corridor-wide comparison returns INCOMPARABLE for those pairs. This is the system being honest about a real constraint, not a feature.
Records are corroborative. Whether any record is admitted, and what weight it carries, is decided by the presiding authority under the rules of that forum. No cryptographic property changes that.
Section 12What's next
Attested assembly design complete
A proof package assembled to a customer's parameters carries a structural hazard: if the customer supplies the parameters and we assemble to match, we are one step from delivering only the records that help them. Today the defence is a stated policy — filters by parameters, never by outcome — which is unverifiable.
Running the selection logic inside a trusted execution environment, over published deterministic code and content-addressed inputs the enclave fetches and verifies itself, converts that policy into a checkable property. The assembly function is already written as a pure function over ledger transaction identifiers specifically so it can be lifted into an enclave without a rewrite.
On-demand attestation planned
Anchoring a queried result set on-chain and issuing a verification certificate. Triggered on request rather than continuously — attesting records nobody has asked to prove is expenditure without benefit.
Additional condition types adapter, not architecture
The pipeline is indifferent to what is being measured. Wind is published by sources already polled; rainfall, air quality and drought indices have equivalent federal sources. Each is an adapter against the same capture, corroboration and sealing path.
Rogue-signer detection shipped
A stolen key producing records resembles a healthy system — liveness monitoring cannot detect it. A separate sweep checks recent seals against the epoch valid at seal time rather than at claimed capture time, because a forger controls the record's contents but not the ledger's timestamp.
VerApex operates from Louisiana on the Mississippi corridor. The dashboard is public and the archive is live: any reading can be clicked through to its permanent record and verified independently. We would rather be evaluated on what is running than on what is described.