Backlog Weather
A retrospective test design for pipeline evidence
This public methodological example explains how to test a possible site-acquisition signal without diagnosing a real business or contacting an owner. It separates observable signs from hidden business states, and useful forecasts from impressive-looking datasets.
You cannot command tomorrow’s rain. You can observe pressure, compare forecasts with outcomes and decide whether to carry an umbrella. A development pipeline deserves the same humility.
A backlog is weather
Imagine a residential developer whose future pipeline is uncertain. The tempting response is to gather every map, register and market feed available. But more observations do not automatically make the future clearer. They can produce a larger fog.
A real backlog contains opportunities that have survived agreed checks. Each has a stage, a date and a next action. A saved search contains possibilities. Confusing the two turns hope into a forecast.
What a forecast must connect
- Public recordobservable and dated
- Market changecontext, not intent
- Planning eventa trace, not a deal
- Hidden statethe opportunity we hope exists
Read as: Public records, market observations and planning events may point toward a future opportunity. The opportunity itself remains hidden until the site, timing and willingness are checked.
A larger map can still be a poor forecast.
A sign is not a fact
A planning notice may indicate change. It does not prove that a site is feasible or that an owner wants to sell. A stale approval may be worth checking. It is not yet an opportunity.
- Hidden state
- The condition we care about but cannot observe directly, such as a viable opportunity emerging within the required time.
- Sign
- A dated, observable trace that might point toward the hidden state. A sign becomes useful only after comparison with outcomes.
- Precision
- Of the records a method flags, the share that later pass the agreed checks.
- Recall
- Of the relevant outcomes that occurred, the share the method managed to find.
- As-of date
- The date at which the test freezes knowledge. Later information must not leak backward into the prediction.
Privacy boundaryThe proposed public test uses historical outcomes and non-sensitive public observations. It excludes personal profiling, inferred distress, contact enrichment and owner outreach.
A forecast must change a decision
Accuracy alone is not enough. A signal that arrives after the decision, covers too little of the market or costs more to check than it saves is not operationally useful.
From observation to decision
- Observedated public trace
- Predictpre-agreed rule
- Checklater known outcome
- Decidecontinue, revise or stop
Read as: An observation is recorded at a known date, used to make a prediction, checked against a later outcome, and then connected to a decision rule.
- Earlier
- Does the signal arrive while a different action is still possible?
- Better
- Does it improve a ranking or decision compared with the current method?
- Enough
- Does it cover enough relevant cases to matter to the programme?
- Worth it
- Does the improvement justify the time, data and review cost?
Test one thing without contacting anyone
Choose one public signal and one historical geography. Freeze the information at a past date. Apply a rule written before looking at later outcomes. Then compare the flagged records with what subsequently happened.
The smallest honest learning loop
- Claimone falsifiable sentence
- Observepoint-in-time evidence
- Compareprecision, recall, time and cost
- Choosecontinue, revise or stop
Read as: State one claim, assemble only the observations available at the time, compare the result with known outcomes, and use the result to choose the next move.
Public test contract
| Before the test | Record |
|---|---|
| Question | What single decision should improve? |
| Signal | What observable trace is being tested? |
| Cut-off | What was knowable, and when? |
| Outcome | What later event counts as relevant? |
| Comparison | What current method is the baseline? |
| Stop rule | What result would end or redesign the test? |
Human release gateA retrospective result does not authorise owner contact. Privacy, licence, planning, discrimination, consent and contact-protocol review remain separate decisions.
What this can—and cannot—show
A retrospective test can show whether a dated sign was associated with a later outcome, how much noise it produced and what it missed. It cannot prove owner intent, current feasibility, future performance or the value of an untested operating system.
- Can show
- Coverage, timing, precision, recall, checking effort and comparison with a baseline.
- Cannot show
- Consent, willingness, site feasibility, a guaranteed transaction or a future conversion rate.
- Useful failure
- Evidence that a proposed sign is too late, too noisy, too narrow or too expensive to pursue.
Precision describes the noise among flagged records; recall describes the relevant outcomes the method missed. A useful review reports both.
A retrospective test design, not evidence that an acquisition channel already works. Owner contact remains outside the method described here.