Forecast Update Trigger Log¶
Workflow — instantiates Revision-Readiness Precommitment
A forecast record that pairs predictions with update triggers and later confidence changes.
A Forecast Update Trigger Log is a running ledger in which each numeric prediction is entered with the pre-set observation that would move it and, later, the actual move it made. Its distinguishing move among its siblings is that it is a time-series of probabilities in motion: unlike a one-belief record, its whole reason to exist is to make confidence change over a stream of forecasts, with each row committing in advance to "if I see X, I will shift this probability by Y." Where a static template preserves a single belief's story, the log is a workflow you run continuously — enter a probability, attach its trigger and its pre-agreed adjustment, and when the trigger fires, apply the move and record it so your updating leaves an audit trail across many predictions.
Example¶
A forecaster on a public geopolitical question — "Will the central bank cut rates before year end?" — enters a starting probability in the log: 70% (illustrative). In the same row she writes the trigger and the adjustment she commits to in advance: "If the next two CPI releases both come in above 4%, cut the probability by at least 15 points; if unemployment rises two months running, add 5." The point of writing the size of the move up front is that it stops her, three months later, from feeling the cut is "basically still on track" and nudging the number by a face-saving 2 points.
When the first inflation print lands hot, she doesn't touch the forecast — the trigger required two. When the second confirms, she applies the pre-committed −15 and logs the new probability with the date and the reason. Over a quarter the log fills with a chain of small, reason-tagged moves. At review, she can compute how well-calibrated those moves were and, crucially, see whether she updated when the evidence came or clung to the opening number until it was undeniable.
How it works¶
- Enter the prediction with its baseline. Each item gets an explicit probability (or band), dated, so movement is always measured from a recorded starting point.
- Attach the trigger and the committed adjustment. In the same row, name the observation that should move the number and the direction and minimum size of the move — before the observation occurs.
- Fire on the trigger, not the mood. When the named evidence arrives, apply the pre-committed adjustment and log the new probability with date and rationale. When it doesn't, hold.
- Review the chain. Periodically read the sequence of moves per question to check that updates happened on schedule and were the committed size, then score accuracy over resolved items.
The workflow's engine is the pairing: a probability is never bare — it always carries the evidence that should move it and the move that evidence buys.
Tuning parameters¶
- Update grain — many small increments versus a few large jumps. Frequent small moves track evidence smoothly (the superforecaster habit) but risk chasing noise; large jumps resist noise but lag.
- Minimum-move size — how large a committed adjustment must be. A floor prevents the timid 2-point face-saver; set too high, it forces overreaction to a single signal.
- Trigger sensitivity — how much confirming evidence a trigger demands (one print versus two consecutive). More confirmation resists noise at the cost of slower updating.
- Symmetry — whether triggers are written for both good and bad news or only the disconfirming side. Two-sided logs guard against updating only in the flattering direction.
- Scoring rule — whether resolved items are scored (e.g. by a Brier score) to feed calibration back into future triggers.[n1]
When it helps, and when it misleads¶
Its strength is that it makes updating timely and honest: because the move is sized before the evidence, the forecaster cannot later shave the adjustment to protect the original call, and the dated chain of moves exposes the common pathology of confidence that stays flat through a run of surprises. Scored over time, it turns forecasting into a practice with feedback rather than a sequence of unaccountable opinions.
Its failure mode is mechanical over-updating: a rigid trigger can force a large move off a single noisy print that a thoughtful forecaster would have discounted, converting discipline into whipsaw. The classic misuse is trigger-gaming — writing conditions so demanding they never fire, so the log looks revision-ready while the number never actually moves. The guarding discipline is to pair each trigger with an evidence-quality check (does this print really meet the condition, or is it an artifact?), to keep triggers two-sided, and to review whether triggers are firing at a plausible rate rather than never.
How it implements the components¶
The log realizes the live-updating face of the archetype — the components that turn a stream of evidence into moving, accountable confidence:
current_confidence_baseline— every entry pins an explicit probability at a date, so each later move is measured from a recorded anchor and confidence trajectories become visible.evidence_update_condition— each prediction is paired, in advance, with the specific observation that should move it, so the trigger exists before the evidence.update_action_mapping— the committed direction-and-size of the adjustment is the action bound to the trigger; when the condition fires, the mapped move is applied and logged.
It does not lock a full write-once accountability_trace of one belief's whole story (that is the Belief Update Review Template), enumerate an alternative_hypothesis_set or watch an observation_window for a research claim (the Preregistration Refutation Table), or bring an independent_revision_witness and a dissonance_buffer (the Red-Team Update Condition Session). Its nearest twin is the Belief Update Review Template: the template is a static, single-belief record, whereas the log is a running ledger whose defining job is tracking probability movement across many forecasts and enacting each pre-sized update.
Related¶
- Instantiates: Revision-Readiness Precommitment — it supplies the live, per-forecast updating loop with pre-committed trigger-to-move pairings.
- Sibling mechanisms: Belief Update Review Template · Preregistration Refutation Table · Red-Team Update Condition Session · Strategic Revisit Gate · If-Then Revision Contract
Editorial Notes¶
Form Classification¶
Form family: Record, Log & Register
Rationale: Forecast Update Trigger Log operates as a durable record, ledger, register, or trace whose value depends on preserving actual state or history because it a forecast record that pairs predictions with update triggers and later confidence changes.
Independent corroboration: The frozen evidence defines Forecast Update Trigger Log as 'A forecast record that pairs predictions with update triggers and later confidence changes', so its operative form is Record, Log & Register.
Nearest alternative: Protocol, Workflow & Routine — The item is an accumulating forecast record whose baseline, triggers, and dated confidence changes preserve revision history.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Futurism & Strategic Foresight
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Pairing forecasts with observable signposts that trigger revision is a canonical scenario-planning and foresight technique.
Related originating lineages:
- Behavioral Economics — Precommitment counters anchoring and face-saving under-reaction to new evidence.
- Organizational & Management Science — Decision logs and precommitment governance materially shape recording later confidence changes.
- Statistics & Experimental Design — Probability calibration and time-series forecast scoring materially shape the log.
Review resolution: Both reviewers agree that futurism_foresight is primary. I retain organizational_management, behavioral_economics, statistics_experimental_design only as formative origin lineage(s), without treating every later application as an origin. cross_disciplinary_synthesis is appropriate because the exact artifact combines contributions from multiple professional lineages. Reach is multi_domain as a separate applicability judgment: it does not widen or narrow the recorded provenance. Encyclopedia synthesis is true because the exact generalized artifact is an encyclopedia-authored combination or refinement. The secondary differences are reconciled with no unresolved primary-provenance ambiguity.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] A Brier score is a proper scoring rule for probabilistic forecasts — the mean squared error between stated probabilities and realized outcomes (0 is perfect, higher is worse). Logging predictions and their later moves is what makes such scoring possible, closing a feedback loop between how a forecaster updates and how well-calibrated those updates turn out to be. ↩