AI Prediction Ledger assessment receipt template Methodology 1.0 | Receipt template 1.0 | October 2, 2026 Documentation revision 1.1 | October 5, 2026 | Validator 1.0 unchanged Use this template for a separate future assessment receipt. It is not a ledger record, an API payload, a scoring engine or permission to edit a historical score. Publication of these supporting files does not publish an assessment or enroll any forecast in a new aggregate. Policy reference https://kingy.ai/blog/ai-prediction-ledger/#prospective-scoring-policy Files ai-prediction-ledger-assessment-template-v1.json: blank reusable receipt. ai-prediction-ledger-assessment-example-v1.json: entirely fictional probability example. Fill out a receipt 1. Copy the blank JSON file under a new assessment ID. Set receipt_kind to assessment and keep publication_status as draft until evidence and review are complete. Template version describes these file fields; methodology version identifies the published evaluation rules. Neither is an API version. 2. Preserve the exact forecast and its qualifiers. Use the original speaker, speaking date and primary source passage. Record date_precision as exact_day, approximate or unknown; do not substitute an upload date for an unknown speaking date. An unknown speaking date stays null: validator 1.0 accepts this in an incomplete draft, but rejects a receipt declared published or included while statement_date is missing. Link repeated statements to one forecast_family_id. If no canonical ledger record exists, record_id may remain null. 3. Complete and freeze the resolution_contract before evaluating the outcome. Use designation prospective or retrospective, and explain whether relevant outcomes were already observable when the contract was written. A future assessment date does not make an after-the-fact contract prospective. Store a recoverable frozen copy; never edit that copy to fit an outcome. Preserve approximate deadlines and conditions rather than supplying false precision. 4. Add primary evidence and observations using the entry formats below. Keep evidence publication dates separate from observation dates. Do not invent links or evidence. Record uncertainty, sample limits and missing populations explicitly. Empty evidence arrays mean no evidence has been recorded, not that the forecast missed. 5. Set assessment.state to one of: pending, met, missed, mixed, unresolved, not_operationally_defined, condition_not_met, attribution_unresolved. These are receipt states; do not map them onto historical ledger statuses automatically. Explain the decision and cite evidence IDs. Missing evidence or uncertainty crossing the success threshold requires withholding a numeric result. 6. Add applicable calculations separately. Use native JSON numbers for measured values and null for unknown or inapplicable results. Never copy a historical -100 to +100 editorial score into a fulfillment or Brier field. Do not combine incompatible measures. Retain unrounded results; for repeating fractions, retain numerator and denominator as the exact result. 7. Record the assessor, review date, second reviewer and reproduction result. Do not claim a second review unless it happened. A material interpretation disagreement withholds numeric results. Keep publication_status draft when any validator-required forecast, contract or review field is incomplete. An unresolved outcome can be recorded in a published receipt with clear gaps and null results only when all checked completeness requirements are satisfied and separate human publication review is complete. Missing attribution fields do not receive an exception; retain those receipts as incomplete drafts. See the completeness checklist below. 8. Explain duplicate and aggregate treatment. Default inclusion remains not_evaluated. Only a designated initial forecast-family representative may enter a new prospective aggregate after all relevant checks. Retrospective contracts, examples, duplicate statements and unresolved outcomes must not enter prospective scored aggregates. This field is documentation, not an eligibility switch in the live ledger. 9. Save revisions as new receipts. Retain the previous receipt and list each changed field, old value, new value, evidence IDs and reason. An initial receipt has previous_receipt_id null and no changes. Historical claims, statuses, scores and eligibility remain untouched. Evidence entry format { "evidence_id": "EV-001", "primary_source_url": null, "archived_source_url": null, "publisher_or_author": null, "source_type": null, "publication_date": null, "observation_start": null, "observation_end": null, "exact_passage": null, "locator": null, "supports": null, "limitations": [] } Observation entry format { "observation_id": "OBS-001", "metric": null, "value": null, "units": null, "population_measured": null, "observation_start": null, "observation_end": null, "uncertainty": { "lower": null, "upper": null, "description": null }, "evidence_ids": [], "limitations": [] } Calculation entry format { "measure": null, "formula": null, "inputs": {}, "result_unrounded": null, "exact_fraction": null, "units": null, "evidence_ids": [], "withheld_reason": null } Supported measures and rules fulfillment: 1 for met; 0 for missed. Otherwise null. For independent subclaims, use met_count / total_count only after every subclaim is resolved. Preserve the full denominator. A mixed compound receipt may hold that fraction; an indivisible event does not receive discretionary partial credit. signed_error: predicted_value - observed_value. Positive means overprediction. absolute_error: abs(predicted_value - observed_value). relative_absolute_error: absolute_error / abs(observed_value), only when observed_value is nonzero. threshold_shortfall: for an "at least" threshold, max(0, threshold - observed_value). Retain the comparison direction for other thresholds. Use percentage points for differences between shares. days_late: qualifying achievement date minus deadline, measured in days. Do not invent a completion date when achievement is unestablished. Retain date intervals when precision is limited. brier_loss: (p - y)^2, with an explicitly quoted probability converted to p between 0 and 1 and resolved binary y of 0 or 1. Never convert vague confidence language into p. For uncertainty or an unestablished outcome, keep result_unrounded null and state withheld_reason. If reporting a supported interval, leave the scalar null and document the interval and its derivation; do not choose a convenient point estimate. Independent subclaims Each resolution_contract.independent_subclaims entry needs subclaim_id, exact_statement and success_rule. Each assessment.subclaim_findings entry needs the same subclaim_id, state, evidence_ids and reason. Equal weights are fixed in the contract. Conditions defining one event are evaluated together, not split for partial credit. Express conditions Preserve each condition's exact wording in resolution_contract.express_conditions. Each assessment.condition_findings entry contains condition, state, evidence_ids and reason. Its state must be met, not_met or unknown. An unmet prerequisite uses not_met in the condition finding and condition_not_met in the overall assessment.state, not missed. An unknown prerequisite cannot support an unqualified numerical resolution. Field distinction (labels only, not an assessment): assessment.condition_findings[0].state = "not_met" assessment.state = "condition_not_met" Revision change entry {"field": null, "old_value": null, "new_value": null, "evidence_ids": [], "reason": null} Completeness checklist: policy requirements and validator coverage complete_for_human_review and --require-complete cover only validator 1.0's checked fields and rules. A pass is not full methodology compliance or publication approval. Checked for completeness: assessment ID/date; forecast family, forecaster, exact quote, statement date/precision, primary-source URL and locator; contract identity, registration/freeze details, designation, timing note, event, population, success rule, human assistance, acceptable evidence and cutoff; measurement metric, denominator, units and sampling method; deadline timezone/precision; assessment state/as-of/reason; aggregate reason; assessor and distinct second reviewer with dates and reproduction confirmation; disagreement flag/note when applicable; and historical-preservation scope. Resolved states also need assessment evidence IDs, at least one calculation and a deadline end. Every supplied evidence entry needs its source URL, publisher/author, source type, publication date, passage, locator and supports statement. Other declared-rule and arithmetic checks still apply. Manually check every scored assessment against policy section 5. Validator 1.0 does not require populated evidence/observation dates, observation units or population, an uncertainty description, calculation formula or calculation units. These can remain null without an incomplete_fields warning, even in a receipt declared published. Conditional date checks run when relevant dates are supplied; they do not establish that missing dates are acceptable. Record the required dated observations, units, uncertainty/limitations and formula yourself, and verify that all inputs trace to primary evidence and the frozen contract. Formula text is documentation only; the validator uses fixed arithmetic rather than executing it. Unresolved outcome evidence is different from missing attribution. A missing statement date, exact_quote, primary_source_url or source_locator makes any real receipt incomplete, including attribution_unresolved. Never invent these values. A separately labeled, unscored public evidence-gap notice is not a complete assessment receipt, a numeric assessment or a prospective aggregate entry. This clarification changes no methodology, receipt schema, validator behavior, historical record, score or eligibility. The original documentation downloads stay available at their original URLs; revised guides have documentation v1.1 URLs. Before sharing Check that a reader can trace every input to primary evidence, reproduce every calculation, identify the frozen contract and distinguish hypothetical examples from real assessments. Review missing fields, disagreements, duplicate treatment and denominator coverage. JSON syntax validation alone does not establish evidence quality or publication readiness. All sources, people, dates, review actions and outcomes in the companion example are fictional. Its calculation is illustrative. Never submit it as a real forecast, primary source or ledger update.