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

worldfork reports list <big-bang-id>
worldfork reports versions <report-id>
worldfork reports view <report-version-id>
worldfork reports view <report-version-id> --format json
worldfork reports render <report-version-id> --format pdf --output report.pdf
worldfork reports pack <big-bang-id> --mode summary
worldfork reports adjudicate <big-bang-id>
worldfork reports adjudication <big-bang-id>
worldfork ledgers path-mass <big-bang-id>
worldfork query GET /api/big-bangs/<big-bang-id>/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:

worldfork reports generate multiverse <multiverse-id> \
  --title "M1 report" \
  --summary "Terminal timeline report."

Then inspect the returned report version:

worldfork reports view <report-version-id>

Final Big Bang Reports

The final report compares terminal multiverses for a Big Bang:

worldfork reports generate final <big-bang-id> \
  --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.

worldfork ledgers list <big-bang-id>
worldfork ledgers view <ledger-version-id>
worldfork ledgers evaluate <big-bang-id> --wait --timeout 120
worldfork ledgers path-mass <big-bang-id>
worldfork reports adjudicate <big-bang-id>
worldfork reports adjudication <big-bang-id>

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:

worldfork runs cost <big-bang-id>
worldfork ticks cost <tick-snapshot-id>
worldfork query GET /api/report-versions/<report-version-id>/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:

worldfork query POST /api/multiverses/<multiverse-id>/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.