# Preserve the forecast made before the outcome

Illustrative planning brief; no automatic product import.

Synthetic planning case: Before a proof starts, a duration forecast of three days is saved. After the actual six-day finish, a recap changes the forecast field to six and reports zero error.

## Decision

Evaluate the original three-day forecast against the six-day outcome, giving a three-day signed error. Preserve the after-outcome recap as a different record, not a replacement prediction.

## Owned work

- Retain original forecast evidence
  - Owner role: Recorder
  - Acceptance evidence: The three-day prediction and its pre-outcome timestamp remain immutable in the evaluation ledger.
- Separate recap from prediction
  - Owner role: Reviewer
  - Acceptance evidence: The six-day recap is labelled after-outcome information.
- Evaluate the declared vintage
  - Owner role: Planning lead
  - Acceptance evidence: The three-day error is reported for the original forecast rather than a hindsight value.

## Workflow

1. Retain original forecast evidence. Check: The three-day prediction and its pre-outcome timestamp remain immutable in the evaluation ledger.
2. Separate recap from prediction. Check: The six-day recap is labelled after-outcome information.
3. Evaluate the declared vintage. Check: The three-day error is reported for the original forecast rather than a hindsight value.

## Judgment

A timestamp alone does not prove the complete training or information boundary. This worksheet preserves the stated prediction vintage only.


## Filled manual planning note

Evaluate the original three-day forecast against the six-day outcome, giving a three-day signed error. Preserve the after-outcome recap as a different record, not a replacement prediction. Original signed error=6−3=3 days. Using the post-outcome replacement gives 6−6=0 but changes the evidence vintage and invalidates that evaluation. A timestamp alone does not prove the complete training or information boundary. This worksheet preserves the stated prediction vintage only.


## Workflow questions

### May forecasts be updated before outcomes?

Yes. Keep each dated vintage and evaluate it at its own declared horizon; do not erase the earlier prediction.

### Does a corrected clerical entry require the same treatment?

Record the correction reason and evidence explicitly instead of silently rewriting the evaluated record.

## Product connection

Use the owned checks and downloaded brief to discuss this planning decision alongside your TeamBoostAI tasks. Confirm available fields, roles and account features separately. The example is manual; it does not calculate live analytics, create work or run an experiment in the product.

Confirm account availability before adopting this manual outline.

## Original worked case

Synthetic records, manual planning only. No account import or live analytics.

### Inspect the invented case records

Record | Timing | Duration value | Evaluation use
--- | --- | --- | ---
Original prediction | Before start | 3 days | Eligible original forecast
Observed result | After finish | 6 days | Outcome
Recap replacement | After outcome | 6 days | Not a genuine earlier prediction

### Reasoning

Original signed error=6−3=3 days. Using the post-outcome replacement gives 6−6=0 but changes the evidence vintage and invalidates that evaluation.

### Bounded result

Evaluate the original three-day forecast against the six-day outcome, giving a three-day signed error. Preserve the after-outcome recap as a different record, not a replacement prediction.

### Distinct decision

The artifact protects prospective evaluation from replacing a saved forecast with hindsight.

### Limits

A timestamp alone does not prove the complete training or information boundary. This worksheet preserves the stated prediction vintage only.

### Definitions and method context

- Forecasting: Principles and Practice — accuracy — https://otexts.com/fpp3/accuracy.html — Genuine held-out forecast and point-error evaluation context. Binary scoring examples use their own explicit toy definitions; no real task model is validated.