# Why PlanAssist separates assessment time from planning outcomes

Why the PlanAssist pilot calls for separate measures of officer assessment time, total application duration and the quality of the final decision.

Author: Retrivium editorial team
Language: en
Analysis published: 2026-11-03
Event date: 2026-10-31
Original announcement: https://deepmind.google/blog/speeding-up-planning-decisions-with-ai/
Canonical URL: https://retrivium.ai/retrospectives/planassist-assessment-time-vs-outcome/

The PlanAssist expansion follows a pilot in which Google reported a reduction of up to 58% in officer assessment time. The retrospective question is what that measure explains, and which important outcomes it leaves outside its scope.

## The dated path

- 2025-06-09: [PM unveils AI breakthrough to slash planning delays and help build 1.5 million homes: 9 June 2025](https://www.gov.uk/government/news/pm-unveils-ai-breakthrough-to-slash-planning-delays-and-help-build-15-million-homes-6-june-2025).

- 2026-06-16: [AI tool to slash planning decision times as government accelerates push to build 1.5 million homes](https://www.gov.uk/government/news/ai-tool-to-slash-planning-decision-times-as-government-accelerates-push-to-build-15-million-homes).

- 2026-10-31: [PlanAssist expands its council testing programme](https://deepmind.google/blog/speeding-up-planning-decisions-with-ai/).

## A workflow has several clocks

An application can spend time waiting for information, awaiting a specialist, undergoing assessment and moving through later administrative steps. Reducing one stage can help without proportionally reducing the whole duration. Our interpretation is that AI progress in administrative work needs a clear measurement boundary. Otherwise a valid local result can become an unsupported claim about the entire process. The source announcement concerns a pilot and a testing expansion, not a completed demonstration of every downstream outcome.

## The denominator changes the conclusion

Assessment time can be reported per case, per officer or per selected task. Each view answers a different question about workload. Case complexity and the work excluded from the timing also matter. A useful evaluation states which cases were included and what counted as a completed assessment. It should make review effort visible rather than assume that producing a draft is equivalent to finishing the work. This keeps a speed result interpretable when readers compare it with a different organization’s workflow.

## A counterfactual around the queue

Imagine an assistant that shortens drafting but leaves a scarce review step unchanged. The active work time falls while the waiting period remains similar. That does not make the assistant useless; it locates the remaining bottleneck. Compare the same case mix with and without the assistant, recording stage durations and final review outcomes separately. This experiment can distinguish genuinely faster processing from moving work between people or postponing corrections to a later stage that the headline measure did not include.

## What the expansion should help reveal

A broader beta can investigate whether the effect persists across case types, record conditions and local practices. It also creates a chance to measure total completion time and decision quality alongside officer effort. These are proposed evaluation questions, not claims about unpublished pilot data. For infrastructure teams, the practical implication is to preserve timestamps and case lineage through the process. The historical lesson is that an impressive stage-level improvement becomes more useful when its relationship to the larger workflow is explicit rather than assumed.

## Technical background

Related engineering context: [Measurement boundaries](/journal/provider-monotonic-latency-measurement/); [Controlled workload comparison](/journal/inference-benchmark-method/).