conformance ledger · the evidence layer of vantage × parallax
What did you know, and when? Dated, machine-checked proof that one store of SEC fundamentals can answer.
Company fundamentals get restated: the revenue a data feed shows you
today is often not the number anyone could have known at the time, and a backtest
built on such a feed quietly reads the future. This page is a public test
record for one alternative — dated rows showing a specific store of SEC
fundamentals answering “what was known on day D?” correctly,
checked by a gate that was also run against a deliberately corrupted copy to prove
it can catch a lie. Every number is read out of a row you can open; any claim the
rows don't back wears a badge. It publishes test results, not the data itself.
The three pieces
Three public repositories share the work, and a reviewer can follow the whole
chain. VANTAGE builds a point-in-time store of SEC fundamentals — every
value keeps the date it became knowable, so the store can be read “as of”
any day. PARALLAX is the test harness that interrogates that store: does an
as-of read leak anything from the future, lose history, or hide a restatement?
BASELINE — this page — publishes only what those tests returned,
each claim tied to a row below by a field you can check yourself.
Neither upstream repo is a dependency of this page: the rows are
hand-copied across a hash-bound seam described in
SOURCE.md. Replaying a row needs the VANTAGE gold
surface, which is not published. The content_hash on each row identifies the
values of the gold columns, in canonical order and under the serialization the row's own
hash basis names — not the bytes of a file. For the two generation-zero rows, kept below
as history, a copy of the same frame, written out and read back, does not reproduce it, which
SOURCE.md records and measures; the current rows were written
only after the gate read its own staged copies back and reproduced their hashes.
The claim path row-backed
The gate reads a fundamentals surface the way a consumer would, re-derives what
should be visible at a chosen instant from the acceptance evidence, and counts
disagreements. A green gate is credited only when the same gate, pointed at a copy of
the surface carrying one deliberately planted error, goes red — catching exactly
the plant and nothing else.
A shift is a measurement only across a known baseline; a green gate
is a claim only against a twin that went red for the planted reason and nothing
else. One viewpoint proves nothing in either instrument.
On 2026-09-16, the gate read 440,661 as-of rows of vantage-gold-local-parquet — scope cik % 97 == 0 sample, viewpoint d = 2024-07-01 — and found GREEN on all 3 checks. The same run against 3 copies, each with a different planted error, went RED, RED, RED.
open the run — the checks, the plant, and every field of the two rows
the checks · semantics from the gate source at fc962f584074
no row visible at the viewpoint d carries acceptance evidence stamped after d — the direct lookahead check
440,661
0
1 = 1 expected
0 = 0 expected
0 = 0 expected
as_of_monotonicity
moving the viewpoint forward (d_earlier → d) never loses a key and never regresses accepted knowledge
280,324
0
0 = 0 expected
1 = 1 expected
0 = 0 expected
restatement_visibility
restatements of one key stay separately visible: no duplicate collapse, no validity interval contradicting its acceptance evidence
440,661
0
1 = 1 expected
1 = 1 expected
1 = 1 expected
The plants, one per twin: plant_future_accepted mutated 1 row out of 440,661, expected {1, 0, 1}, the gate returned {1, 0, 1}; plant_vanishing_key mutated 1 row out of 440,660, expected {0, 1, 1}, the gate returned {0, 1, 1}; plant_wrong_winner mutated 2 rows out of 440,661, expected {0, 0, 1}, the gate returned {0, 0, 1}. Each red credits only an exact match to its own plant; a red for any other reason credits nothing.
the run, field by field · every value read from the 4 rows
sha256 of Arrow IPC at compatibility level oldest, one chunk, of the gated frame (sorted by cik, tag, ddate, qtrs, uom, accepted, adsh, version, valid_from, valid_to; polars 1.43.2)
How baselines fail — and the one that holds
Every fundamentals read surface handles the viewpoint problem in one of four
ways. Three of them lose the claim — each in a different place — and each
broken variant below is pinned to what this ledger actually holds against it.
00zero baseline
in the instrument
One viewpoint. Nothing shifts; a near star and the far background are
indistinguishable. There is no measurement to get wrong.
on this ledger
commercial-fundamentals-api (APERTURE):
NO_AS_OF_MODENO_ACCEPTANCE_INSTANT
across 48 documentation pages. The only date on a
fundamentals record is filing_date — restatements
overwrite in place, so lookahead has nowhere to show up and
quietly becomes the dataset.
01unknown baseline
in the instrument
The shift is right there on the plate, but with no citable separation it
never becomes a distance — a number with no meaning.
on this ledger
A green that has never been shown able to go red cites nothing, so
the checker refuses it: a live cell arriving without its twin derives
PARTIAL, never
CLAIMABLE — a rule held by its own
named control in test-ledger.mjs.
02flexing baseline
in the instrument
The separation moves between the two observations and the instrument
manufactures shift — false parallax, indistinguishable from signal on
a single pair of plates.
on this ledger
The twins exist to catch exactly this: plant_future_accepted moved the boundary by 1 row and the gate went RED with violations {1, 0, 1}; plant_vanishing_key moved the boundary by 1 row and the gate went RED with violations {0, 1, 1}; plant_wrong_winner moved the boundary by 2 rows and the gate went RED with violations {0, 0, 1} — each plant, the whole plant, and
nothing but the plant.
03stored viewpoint
in the instrument
Bessel's standard: the separation is surveyed and cited beside the
value, so a better viewpoint later replaces without rewriting.
on this ledger
Lane 1 derives
CLAIMABLE
today: live GREEN over
440,661 as-of rows at d = 2024-07-01, 3 twins red, each for
its own planted reason. One surface, one lane, one dated run — and no more
than that.
What a feed without a viewpoint costs reported, not on the ledger
Measured on a sample of 17,787 filer-quarters from the same surface: when revisions
land, they are rare but violent — in 1.51% of cases the reported growth story
flips sign. A quarter your feed shows as growth was, on the day you would have
traded it, a decline. This measurement is reported from PARALLAX study 001 and does
not yet have a ledger row of its own; until it does, it carries this badge.
Status by lane
Surface under test: vantage-gold-local-parquet. A lane is CLAIMABLE only when both
cells exist: the live surface green and the planted-error twin red for exactly
the planted reason. Each check is credited on its own: every check the live cell reports must have been set nonzero by at least one twin red for its planted reason, or the lane derives PARTIAL and names the check. Status is recomputed from the rows at every build; it is never
written down.
derived at build time, never authored
Lane
Status
Meaning
1 · local Parquet
CLAIMABLE
live cell GREEN and every twin cell RED matching its planted error exactly, every check set nonzero by some twin
2 · Unity Catalog
UNCLAIMED
no gate runs on this lane yet
3 · Snowflake over Iceberg
UNCLAIMED
no gate runs on this lane yet
The ledger
Gate verdicts — each resolves to a replayable run (commit, content hash):
The superseded twin row's hash basis reads "of the gated frame": the frame that
gate read is the staged twin parquet, which read back hashes sha256:bbe60bf9daf1…
under that same basis, while the row records the hash of the same values before they were
written. The row stays published as history, so the gap is recorded in
SOURCE.md rather than edited into the row.
Surface audits — established by reading vendor documentation, visibly not gate
runs, coloured accordingly:
SURFACE_AUDIT · hand-authored from vendor documentation
open the audit — the row's sentence, its notes verbatim, method controls, corpus
As of 2026-08-20, this vendor's fundamentals endpoints offered no way to ask what was known on a given day. Field that dates a period: filing_date. Source: machine audit over 48 documentation pages (artifact snapshots/audit-2026-08-20.json).
Nanosecond receipt timestamps on trade/quote surfaces; calendar-day precision only on all 17 filing surfaces. No fundamentals or filings endpoint takes a knowledge-time parameter. Raw fetched pages are the vendor's text and are not republished here; the committed artifact is the machine audit result over that corpus, replayable via the auditor script against the vendor origin. — the row's own notes field, verbatim.