# Reporting WorldFork reports are structured database records first. They summarize the Monte Carlo tree search of the real world by comparing retained timelines, endpoint evidence, branch/path mass, and terminal outcomes. Rendered Markdown and PDF outputs are generated from those records only on request. ## Layers | Layer | Meaning | | --- | --- | | `reports` | Logical report slots, scoped to one multiverse or the final Big Bang | | `report_versions` | Generated revisions with parsable content and source metadata | | Artifacts | Cached Markdown/PDF render outputs for a specific report version | Artifacts are not canonical. If a rendered Markdown or PDF artifact is removed, the report version remains reconstructable from `report_versions.content`. ## Report Version Metadata A report version can store: - title and summary - structured report content - generation metadata - report-agent model - source multiverse IDs - source multiverse version - source Big Bang config version - latest source tick snapshot and tick index - Markdown artifact ID - PDF artifact ID This makes a report auditable even if a multiverse continues later. ## Viewing Outcomes ```bash worldfork reports list worldfork reports versions worldfork reports view worldfork reports view --format json worldfork reports render --format pdf --output report.pdf worldfork reports pack --mode summary worldfork reports adjudicate worldfork reports adjudication worldfork ledgers path-mass worldfork query GET /api/big-bangs//report-status ``` The Markdown view can include the outcome summary, outcome distribution, multiverse comparison, report inventory, and evidence appendix when those sections are present in the structured content. Use `report-status` while generation is running. It reports whether the run is still simulating, generating single-universe reports, resolving predicates, or generating the final multiverse report, plus the active job/LLM call when one is available. ## Question Context Reports prefer dedicated question metadata over raw scenario text. The frontend and API can store: - `scenario_input.primary_question` - `scenario_input.resolution_criteria` - `scenario_input.supporting_questions` The primary question becomes the forecast contract the report answers directly. Resolution criteria define what should count as yes, no, or unresolved, and supporting questions guide the report sections and evidence review. If those fields are absent, reporting falls back to the original scenario text for legacy runs. ## Multiverse Reports Generate a report for one terminal multiverse: ```bash worldfork reports generate multiverse \ --title "M1 report" \ --summary "Terminal timeline report." ``` Then inspect the returned report version: ```bash worldfork reports view ``` ## Final Big Bang Reports The final report compares terminal multiverses for a Big Bang: ```bash worldfork reports generate final \ --title "Final report" \ --summary "Cross-multiverse outcome review." ``` The final report should be generated after the relevant multiverses have reached terminal states. ## Endpoint Ledgers, Adjudication, And Path Mass Endpoint ledgers store endpoint status and evidence. They are not the branch probability distribution. Final outcome probability comes from retained timeline/path mass after adjudication. Final reports also include a Prophet-style probability extraction layer: - `forecast_predictions.primary.p_yes` is the calibrated YES probability for the primary forecast contract. - `forecast_predictions.primary.mass` records the yes/no/uncertain path mass used to compute that value. - explicit predicate resolutions take priority when available because they map directly to the original yes/no scenario question. - endpoint path-mass evidence is the fallback when predicate resolution is not available; unresolved or insufficient-tick mass is split evenly rather than coerced into YES or NO. - process-only endpoints are recorded as auxiliary evidence and cannot dominate the binary forecast. ```bash worldfork ledgers list worldfork ledgers view worldfork ledgers evaluate --wait --timeout 120 worldfork ledgers path-mass worldfork reports adjudicate worldfork reports adjudication ``` Use ledger views to inspect endpoint evidence. Use path-mass or timeline adjudication outputs when you need data suitable for plotting an outcome distribution. ## Cost Summaries Report-version JSON responses can include cost summaries derived from audited LLM calls and model estimates. Use: ```bash worldfork runs cost worldfork ticks cost worldfork query GET /api/report-versions//cost ``` Observed provider cost is included when available. Estimated cost is marked as an estimate when exact provider usage is unavailable. ## Report Agent Prompting And Retry Backend reports store the full structured report content in `report_versions.content`, but the user-facing report body is generated by the report LLM. The report agent receives a compact digest with outcome distribution, selected high-signal timelines, divergence drivers, report inventory, evidence gaps, recent event highlights, and cohort/hero state samples instead of the whole raw payload. Mutable audit counters such as LLM-call and artifact totals are kept in the structured record but pruned from the LLM digest. If the first report-agent LLM attempt fails after the normal LLM retry policy, the backend retries once with a smaller rescue digest. Reports do not fall back to deterministic prose. If the report LLM cannot produce a long-form Markdown report, generation fails and no completed report version is stored. Rendered Markdown and PDF outputs use the LLM report body, followed by a structured evidence appendix for traceability. ## Continuing A Multiverse When a multiverse reaches `max_ticks`, it becomes terminal and reportable. To continue it, set a larger tick limit: ```bash worldfork query POST /api/multiverses//continue \ --data '{"max_ticks":120,"reason":"Extend after report review."}' ``` Continuation increments `multiverse.version`, stores a per-multiverse runtime override, and preserves sibling timelines at their original limits. Reports generated before continuation stay bound to the old multiverse version. Reports generated after continuation point to the newer multiverse version and latest tick snapshot. ## Storage And Deletion Report versions point at the source multiverse IDs, source multiverse version, source config version, and source tick snapshot available when the report was created. Storage cleanup should preserve those references. If deletion support is added for Big Bangs, multiverses, or artifacts, it should either block while referenced reports exist or tombstone source rows instead of silently orphaning historical report versions.