Decision ledger
The durable public record of emitted model outputs.
#Formal definition
The public decision ledger stores each eligible stance with identity, time, model, window, freshness, components, and input snapshot references.
Decision ledger is treated as a typed part of an agent mandate, not as marketing language. The definition is stored before an output exists so it cannot be changed to explain a favorable result after the fact. Product pages keep the relevant definition beside live state, and the decision ledger retains the version needed to reconstruct how an emitted stance was produced.
#Configuration
The decision policy emits on a new source snapshot and defines the idempotency fields agent, source timestamp, and stance.
Configuration is validated at the boundary. Symbols must follow the application symbol format, numeric limits must remain inside the documented range, and any creator-supplied text is stored as user-generated content. Built-in definitions are static product configuration; published definitions are database records. Neither category is evidence of market activity until real observations are associated with it.
#Runtime behavior
SQLite or D1 enforces the decision ID as a primary key. A repeated engine cycle cannot create a second row with the same ID.
The runtime refuses to bridge missing information with a default financial value. A missing quote remains unavailable, a stale input blocks conviction, and a halted asset does not become an observation. The current state therefore describes what the engine can prove at the latest successful cycle. READY means the complete gate is satisfied; it does not mean the model is correct or profitable.
#Audit trail
Every value related to decision ledger has a declared source type: live external data, onchain state, an engine derivation, a database row, static configuration, or user-generated configuration. Source timestamps and application receipt timestamps remain separate. This makes it possible to distinguish when the upstream venue generated a quote from when OVERWEIGHT received and persisted it.
For a decision, the audit path continues through input snapshot IDs, model version, component contributions, thresholds, output stance, and freshness. Reprocessing the same agent, source timestamp, and stance uses the same decision ID. The database primary key prevents a second write from creating a duplicate public record.
#Worked example
Opening a row exposes the exact decision ID, source/receipt times, benchmark, components, and input IDs; Copy Decision ID copies the durable identifier.
The example is explanatory rather than a seeded production record. Numbers in documentation illustrate arithmetic only and are never imported into application routes. Production components receive values through typed selectors. When the corresponding runtime value does not exist, the component renders an em dash, NO DATA, or another explicit unavailable state instead of copying the example.
#Failure states
Relevant failure states include MARKET API UNAVAILABLE, RPC UNAVAILABLE, DATA DELAYED, STALE, MARKET HALTED, NO DATA, and an incomplete observation count. Each state answers a different question: whether the source responded, whether the response is current, whether a market is halted, and whether the model has enough complete data. Those states are not interchangeable.
A failed request cannot become an observation. Duplicate source timestamps are ignored by a unique database index. Missing benchmark data prevents a benchmark-relative score. A user-published definition with no scheduled worker reports NO DATA rather than CALIBRATING, because calibration would imply that collection is actively progressing.
#Limits
The ledger is offchain. It must not be described as an onchain ledger unless a future implementation actually writes decisions to a deployed contract.
OVERWEIGHT agents currently publish research states. They do not take custody of a user account, execute an order, guarantee a fill, or guarantee an outcome. The transparent schema makes a model inspectable, but inspection does not remove model risk, venue risk, tokenized-instrument risk, or the statistical weakness of a short record.