Evidence, uncertainty and reversal conditions

What counts as evidence

Proposed

In the record format we are building towards, every piece of evidence carries its own provenance. A claim without a source is not evidence; it is a claim. The record keeps the following, in plain words:

source

where it came from

digest

a fingerprint of the content, so a later change is detectable

collected

when it was gathered

freshness

how long it stays valid, and what makes it stale

method

how it was observed

scope

how sensitive it is, and who may see it

claim

what it actually says, with units where relevant

chain

every step between the original source and this record

Four kinds of statement, never blended

Proposed

Observations, assertions made by the person asking, inferences made by a model, and results of a simulation are marked as different kinds of thing. A simulated outcome can be useful; it is never reported as something that was observed.

When sources disagree, each is stored as its own record. We do not settle a disagreement by quietly keeping the source we prefer.

Text retrieved from a page or a document is data. Instructions embedded in it cannot change what the system is allowed to do.

Cached results are reused only while they are still valid. Stale evidence is never substituted for a fresh read to save cost.

Numbers in answers

Partly built

Language models misquote numbers. GodEngine passes the figures it has computed to the model verbatim, then checks the numbers in the answer against them. This figure check is on, and it still has known misses, so we treat it as a safety net rather than a guarantee. If a figure in a report matters to your decision, trace it.

Reporting uncertainty

Proposed

For a forecast to mean anything, it has to say what quantity is being modelled, in what units, over what horizon, under which assumptions, and how it will be evaluated against what actually happens. Forecasts in a particular domain need data from that domain.

Where a method has not been calibrated against outcomes, the honest output is a comparison of scenarios with the assumptions written out, not a percentage that looks like a measured likelihood.

Partly built The engine contains an inference layer for TimesFM 2.5, an openly released time-series forecasting model with 200 million parameters. It is not yet used in everyday answers.

Forecasts kept in a ledger

Partly built

For the forecasts written by GodEngine's newsroom, the design follows three rules:

1. A forecast is recorded before anything is written about it, and the criteria for resolving it are fixed when it is issued.
2. Source articles are evidence, never copy. The writer does not receive their text to rephrase.
3. Every number shown is a query against the system's own records, not a figure typed into a page.

Two numbers are kept and deliberately never merged: what the engine currently believes (the average probability across forecasts that have not resolved), and its track record (the share of resolved forecasts that landed on the right side). Neither is called simply “confidence”. The track record is not shown as a headline figure until a minimum number of forecasts have resolved, five by default.

The ledger only grows. Each entry is chained to the one before it, and a verifier reports a changed entry, a broken link, a missing entry or a fork. None of these is silently repaired.

Note We make no claim here about the ledger's track record. A track record is earned by forecasts resolving, not by describing the mechanism.

Reversal conditions

Partly built

Every decision record names, next to the recommendation, the new evidence that would change it. We call these reversal conditions. They turn a recommendation from a verdict into a hypothesis that can be checked.

GodEngine’s internal decision service, deployed on 4 October 2026 and not yet used in everyday answers, finds them by re-running its own scoring: the nearest budget above and below at which the recommendation changes, the effect of halving or doubling the time horizon when recurring costs matter, and the smallest change that would let the runner-up overtake. They are exact for that model, not rules of thumb.

A useful reversal condition is specific, observable, and tied to the assumption it would break. In the proposed design, when one is met, the recommendation is reassessed, not quietly kept. Nothing watches for that yet.

Alongside the reversal conditions, a decision record holds the evidence it used, the alternatives, the assumptions, the option selected, the objective and constraints, the model and configuration versions, a description of the uncertainty, the limits of where it applies, and whether it has been evaluated yet.

After the decision

Proposed

Outcomes are measured later against the original objective, with the limits of attribution stated. A later session must be able to read earlier outcomes from durable records, not from memory that disappears when a process restarts. Decision identifiers stay unique across every instance of the engine, so an outcome can always be traced to the decision it belongs to.

Partly built Records from the internal decision service already carry durable random identifiers and an evaluation status that stays “unevaluated” until an outcome is recorded against them. Recording and measuring outcomes is not built.