Ledger Stats API
Ledger Stats is the calibration and integrity view: how the ledger breaks down, how many verdicts have been reconciled, and how well each verdict has actually borne out. It is the compounding-asset view of the record.
What it returns
The response returns total, breakdowns by_kind, by_verdict, and by_data_mode, outcomes_recorded, an outcome_coverage ratio, a calibration map (per verdict, the outcome mix and a borne_out_rate), the full integrity proof from verify, the storage backend, and a note.
Calibration is only meaningful once outcomes have been reconciled via the outcome endpoint.
When to use it
Use Stats for a dashboard of the ledger as a calibration dataset: which verdicts the engine gives, how often outcomes get reconciled, and whether a given verdict tends to be borne out. It is open with no per-call metering.
Unlike per-name Institution Memory, Stats is the platform-wide view across every recorded verdict.
Notes and honesty
As outcomes are reconciled the ledger becomes a compounding calibration dataset a data feed cannot buy. Borne-out rates are only present once outcomes exist. Offline the ledger is in-memory and resets on restart unless Supabase persistence is configured.
- total and breakdowns by kind, verdict, and data mode
- outcomes_recorded and outcome_coverage
- calibration: per-verdict outcome mix and borne_out_rate
- integrity: the embedded hash-chain proof
- storage: in-memory or supabase
- platform-wide calibration view
curl -s https://api.lyramindos.com/v1/ledger/stats
Questions
What is calibration here?
For each verdict, the mix of reconciled outcomes and the resulting borne-out rate. It becomes meaningful only after outcomes are recorded via POST /v1/ledger/outcome.
How is this different from Institution Memory?
Memory is the per-name track record. Stats is the platform-wide view across every recorded verdict, kind, and data mode, plus the integrity proof.
Is a key needed?
No. Ledger stats is open and not metered, like the other ledger read endpoints.