Forecasting Discipline
Use this procedure when a workflow asks for prediction, scenario probability,
valuation implication, or decision support.
Forecast fields are an agentic judgment contract, not a trading model, feature
store, autonomous signal, or execution trigger. Use them to make role judgment
reviewable, horizon-bound, falsifiable, updateable, and suitable for
postmortem.
Required output shape:
forecast_requiredforecast_allowedforecast_block_reason when probability should not be producedforecast_targetforecast_horizonprobability or probability_range when allowedbase_rate or missing-base-rate noteevidence_idscontrary_evidenceresolution_sourcereview_dateupdate_triggersinvalidation_conditions
Quality floor:
- Bound each forecast to a resolvable target and horizon.
- Separate factual data, model output, assumption, and judgment.
- For a scoreable binary forecast, provide a point probability; an optional
range may express uncertainty around it. Range-only records are exploratory
diagnostics and do not count toward proper-score calibration.
- Treat forecast probability as role judgment that needs evidence, contrary
evidence, review date, and invalidation conditions.
- If
probability and probability_range both appear, keep the point value
inside the range.
- If evidence is too weak to defend a scoreable point probability, use
forecast_allowed: false rather than presenting a range-only record as a
calibrated forecast. Use not-decision-ready, revise, or blocked with
a clear block reason.
- When forecast scope is negated, provide qualitative scenarios only; do not
create probability fields or forecast ledger records.
Write scoreable records under trading/forecasts/ only after accepted
evidence supports the forecast.
1---2name: tcx-forecast3description: Require horizon-bound, evidence-aware, updateable forecast fields when prediction, valuation implication, or decision support is in scope.4---56# Forecasting Discipline78Use this procedure when a workflow asks for prediction, scenario probability,9valuation implication, or decision support.1011Forecast fields are an agentic judgment contract, not a trading model, feature12store, autonomous signal, or execution trigger. Use them to make role judgment13reviewable, horizon-bound, falsifiable, updateable, and suitable for14postmortem.1516Required output shape:1718- `forecast_required`19- `forecast_allowed`20- `forecast_block_reason` when probability should not be produced21- `forecast_target`22- `forecast_horizon`23- `probability` or `probability_range` when allowed24- `base_rate` or missing-base-rate note25- `evidence_ids`26- `contrary_evidence`27- `resolution_source`28- `review_date`29- `update_triggers`30- `invalidation_conditions`3132Quality floor:3334- Bound each forecast to a resolvable target and horizon.35- Separate factual data, model output, assumption, and judgment.36- For a scoreable binary forecast, provide a point probability; an optional37 range may express uncertainty around it. Range-only records are exploratory38 diagnostics and do not count toward proper-score calibration.39- Treat forecast probability as role judgment that needs evidence, contrary40 evidence, review date, and invalidation conditions.41- If `probability` and `probability_range` both appear, keep the point value42 inside the range.43- If evidence is too weak to defend a scoreable point probability, use44 `forecast_allowed: false` rather than presenting a range-only record as a45 calibrated forecast. Use `not-decision-ready`, `revise`, or `blocked` with46 a clear block reason.47- When forecast scope is negated, provide qualitative scenarios only; do not48 create probability fields or forecast ledger records.4950Write scoreable records under `trading/forecasts/` only after accepted51evidence supports the forecast.
monarchjuno