How to read this ledger: v0.1 shows the public schema and illustrative packet shapes. A resolved ledger should only claim performance after source-dated packets have been run and postmortemed.
Ledger rows
| Packet | Question | Cutoff / freshness | Source classes | Update triggers | Boundary |
|---|---|---|---|---|---|
| Market Morning Map — pre-market context sample Illustrative beta sample | What context should a trader review before the open when futures, rates, dollar, and BTC are sending mixed signals? | Live use requires same-day source timestamps. | Economic calendar; index futures; VIX; 10Y; dollar; BTC; major market reporting. | 8:30 ET data surprise; VIX divergence; DXY/10Y reversal; breadth confirmation or rejection. | No entries, exits, stops, targets, position sizing, or buy/sell instructions. |
| Forecast Packet — operator uncertainty sample Protocol sample | What evidence would change the adoption outlook for an AI workflow tool inside a regulated team? | Use only sources available before packet timestamp. | Vendor docs; customer workflow notes; policy references; comparable adoption cases. | Compliance review changes; workflow failure modes; integration constraints; budget deadlines. | No legal/compliance advice; maps decision context and review questions only. |
| Public signal forecast card sample Ledger template | Will a public signal mature into a durable product lane within 30 days? | Source cards and internal review packets available before routing decision. | Original source URL; forecast registry; related notes; follow-up public evidence. | Repeated user requests; source quality improvement; clear buyer/job; postmortem shows reusable pattern. | No fabricated traction or unverified performance claims. |
Next resolved-ledger fields
Outcome
What happened by the horizon or check date.
Score
Brier/log score for binary components where appropriate; qualitative postmortem for scenario maps.
What changed
The specific source or market condition that changed the view.