A decline is rarely about the hard part of the job. The diagram is usually sound and the controls are sensible. What sends a plan back is almost always something smaller: a field left blank, a value that does not match the one three pages earlier, a hazard noted but never carried through to a control. Individually minor. Together, they are the difference between an approved plan and a week of rework.
Under a risk-based framework like NZGTTM, that bar has risen. Plans now have to show their reasoning, not just their layout. That is the right move for safety, but it puts more documentation on the people preparing the work, and more places for a small gap to hide.
Here are the patterns that come up again and again, and what closes them.
The same detail, entered four different ways
A single project carries the same core facts across the request, the diagram, the risk assessment and the plan itself. When those are keyed by hand into separate documents, they drift. The speed limit on the diagram does not match the one in the plan. The site address is abbreviated in one place and spelled out in another.
Reviewers notice inconsistency before anything else, because it makes them question everything else. The fix is not to check harder. It is to enter each fact once and reuse it everywhere, so there is only ever one version to be right.
Hazards that never become controls
A risk-based plan is judged on a chain: hazard, then assessed risk, then the control that manages it. Declines happen when the chain breaks. A hazard is identified but no control is listed against it. A control appears with no hazard to justify it.
Before you submit, read the plan the way an RCA will:
- Every hazard has at least one control.
- Every control traces back to a hazard.
- The residual risk is stated, not implied.
If any link is missing, that is the first thing a reviewer will find.
Blank fields and quiet omissions
Empty mandatory fields are the most common decline of all, and the most avoidable. They rarely reflect missing knowledge. They reflect a long form, a busy day, and no final check that every required field is actually filled.
A plan does not have to be wrong to be sent back. It only has to be incomplete.
A structured check across every field before export catches this in seconds. A human read alone will not, because the eye skips what it expects to be there.
No trail back to the source
Increasingly, reviewers want to know where a value came from. Which count informed the layout. Which past project the approach is based on. What the diagram is responding to.
A plan that can show its sources is faster to approve, because the reviewer does not have to take anything on trust. A plan that cannot leaves them to reconstruct your reasoning, or to decline and ask.
Where TrafficSense fits
TrafficSense is built around these exact failure points. Details are captured once and kept in sync across the request, diagram, risk register and plan, so nothing drifts. The hazard-to-control chain is structured, so a missing link is visible before submission, not after. A final check confirms every required field is complete and exports a clean, RCA-ready pack, with the sources behind each value on record.
The judgement stays with the qualified people who have always held it. AI drafts and checks; people decide and approve. The plan simply arrives at the reviewer with fewer reasons to be sent back.
Fewer declines is not a promise of less rigour. Done well, it is the result of more.