Evidence and reliability #

The engine treats evidence as a product, not a side effect. A paper return without its policy, inputs, cutoff, code identity, costs, and validation state is only a number. The system keeps those pieces together so a later reader can reproduce what happened and distinguish a research failure from an operational one.

Frozen records #

A registration freezes the values that define a policy before evidence arrives. A decision then records the registration, model and prompt identity, input references, cutoff, output, authority, and failure state. Later labels append outcomes at fixed horizons. They do not replace the original decision.

Reports and recovery bundles use hashes as compact content identities. A hash is not an argument that the content is correct. It proves that the bytes being read are the same bytes that were registered or retained.

Evidence tables are append-only where time matters. Source changes become revisions. Point-in-time facts keep availability and ingestion times. A missing value stays unavailable rather than becoming zero.

What a registration revision means #

A registration revision is a newly issued identity for an allowed change. It is not permission to rewrite old evidence.

Some revisions change the policy and therefore begin a new cohort. Others bind infrastructure changes that leave the research meaning untouched. The recent profitability registration revisions are in the second group. The current one, revision 17 (October 2026), binds the senior-quant review's fixes: the SEC acceptance clock, batched nightly writes, faster replays, and cost and liquidity corrections on the fill paths. Revision 16 bound its first batch: store-integrity repairs, statistics fixes, and operations evidence fixes. Neither changed scoring, books, gates, labels, schedules, or registered values. When a fix does change what an evaluation computes, as the SEC clock did for the 8-K source, the revision says so in its stated reason.

The reason for a revision is stored with the registration. Validators bind the complete registered file set, so an unrecorded source edit fails closed.

Evidence validators #

An evidence validator recomputes important claims from retained source data. It checks registration and runtime identities, source receipts, availability cutoffs, label maturity, price prefixes, book mechanics, and report inputs.

Validation distinguishes three cases that can look similar:

• unchanged values fetched again at a later time;
• a source that genuinely revised an earlier value; and
• a stored record that no longer matches its retained identity.

The first can remain valid, the second is reported as a source revision or becomes unavailable, and the third is fatal. A validator does not weaken the check because a report is inconveniently red.

Scoring first completes its book update and re-renders the league, then runs evidence validation. If validation fails, the report command returns the distinct exit status 75. The service preserves the league render, records the failure, and is configured not to restart on that status; a bad evidence view therefore cannot cause an automatic retry loop or erase the completed paper state.

Intraday retention applies the same identity rule before it writes: an unchanged payload for the same security, fact type, and event time reuses the prior revision. Changed or new facts are inserted as one batch with their exact response receipt. This keeps repeated five-minute captures from manufacturing evidence revisions while preserving real source changes.

Invariants and repairs #

Some errors are only visible across the whole store: two price bases for one stock after a split, a split recorded but never applied, a fill without its fee row, an active book without equity. A monitor checks each newly published read-only snapshot against these invariants and reports any regression beyond a recorded baseline. It runs in shadow mode: it reports, and an agent investigates; it never edits data.

Repairs to stored history use a separate tool that only plans by default and is idempotent. It changes a bar only when the source's current history agrees, keeps every original row in a rejects table, and writes each change to the audit log. Its first live run, on 22 October 2026, corrected 18,798 rows and brought the split invariants back to zero regressions on a store copy.

Speed claims need identical outputs #

A faster path is accepted only when it produces the same rows, values, and hashes as the old path on a recorded fixture or a copy of the store. A benchmarking tool prints a digest of each output with timings and code identity removed, so running it on two versions of the code proves identity. The full test suite, about 6,100 tests, runs in roughly two and a half minutes and must pass under both UTC and Singapore time before anything reaches the branch the nightly runs.

Read-only snapshots #

Completed producers publish immutable, consistent database snapshots. A manifest records the source data identity, publication time, file hash, size, and table counts. The newest two generations are retained.

When no write-ahead log is present, the publisher records source invariants under the normal writer locks, copies and synchronizes the file, releases the locks, then verifies the copy. With a write-ahead log, it uses the database’s consistent copy path. A snapshot failure never changes the producer’s own success or failure. Profitability event runs publish at most once per 120 minutes; pre-open runs do not publish. The nightly, scoring, and TradingView archive remain unthrottled.

If the primary database is legitimately writer-locked, read-only API requests may use the latest valid snapshot. Responses identify that fallback and its as-of time. A corrupt primary does not trigger fallback, and evidence status uses a snapshot only when it is newer than the live database’s last write.

Recovery and timing #

A recovery bundle contains a consistent database copy, prospective evidence, operational files, and release identity. Creation refuses unsafe paths and overlapping producers. Verification checks the file hash, schema, row counts, job states, active books, and retained files against the manifest.

The product policy also allows a private daily off-server export, restore-checked before it is pushed. Raw data and private research remain outside this public repository.

Every scheduled driver stage writes a start time, end time, duration, and exit status to its normal log and to logs/stage-timings.jsonl. tools/stage_timings.py reports the median, 90th percentile, and failure count over recent runs. Timing publication is fail-soft, so observability cannot change the driver's result.

The expensive profitability status is cached against the registration and every audited table's generation. Intraday readiness is cached against its row count and latest timestamp. Either cache is recomputed when its inputs change, so repeated status requests avoid full scans without serving a time-based guess.

Reliability here does not mean pretending nothing fails. It means failures retain enough identity and timing for an agent to investigate them on demand without changing frozen evidence.