Resource Library
Evidence review frameworks for local government
By XVision Engineering
- Evidence Frameworks
- Local government
- ANPR evidence
- Decision records

A practical engineering method for sensor and ANPR evidence
Technical whitepaper · Edition 1.1 · November 2026
Evidence first. Accountable decisions. Traceable follow-up.
Download the whitepaper (PDF) · 12 pages · Word document
Editable templates: evidence review checklist (Word) · blank decision record (Word)
Contents
- Review evidence before acting
- Define the question and assess the evidence
- Separate a plate reading from a finding
- Register sources and resolve conflicts
- Set thresholds before reviewing outcomes
- Sign the finding, authorise the decision
- Completed illustrative decision record
- Evidence review checklist
- Blank decision-record template
- Follow-up and public reference register
01. Review evidence before acting
Traffic and transport engineers need to know what a dataset supports before using it to change a road, investigate an asset or recommend a compliance response. Counts, images, sensor observations and automatic number plate recognition (ANPR) records answer different questions. A useful review connects each finding to its sources, limitations and accountable decision owner.
This paper provides an engineering method for that review. Start with the council's existing evidence. Define the question, gather a bounded evidence pack, assess its quality and provenance, write a finding, authorise a decision and verify the follow-up.

Figure 1. Evidence review chain. Return to gathering or assessment when a material gap changes the answer.
Four outputs from every review
- A finding that states what the observations support and the conditions under which it holds.
- A source register that lets another authorised reviewer locate the evidence and repeat the analysis.
- A decision record that separates technical judgement from the authority to act.
- A follow-up task with an owner, target date and verification method.
Scope and limits
This is a recommended framework and method, not a report of XVision product performance or implemented software features. Any proposed implementation needs its own agreed scope, source validation and acceptance checks. The worked record is illustrative and hypothetical.
This paper is not legal advice and gives no assurance of admissibility. The council's responsible officers must establish the applicable privacy, records, decision and delegation requirements for the purpose and jurisdiction. Use an approved urgent-safety process when immediate protective action is needed, and record that action separately from later conclusions about cause or responsibility.
Evidence is fit for a stated use. A planning observation, an individual event finding and an authorised compliance action require different evidence and review controls.
02. Define the question and assess the evidence
Write a question that the available observations can answer. State the event, location, direction, period and population. Define the intended action and excluded uses. A loading-area investigation and a finding about whether a particular vehicle was non-compliant are separate tasks.
Agree the brief before reviewing results
Name the decision owner, technical reviewer and source custodian. Describe the consequence and reversibility of each available action. Approve the sampling method, reference method and escalation plan before assessment. Confirm authority for collection and use, access permissions and the records retention basis.
Gather original observations, configuration history, unit health and outage logs, clock information and relevant site context. Include the signs or zone layout in force during the period when these affect interpretation. Select periods before looking for favourable events; cover the operating conditions relevant to the question.
| Quality check | Test and record |
|---|---|
| Relevance | Same event definition, place, direction and period as the question. |
| Coverage | Expected operation versus files and health logs; gaps, blind routes and blocked views. Treat missing observations separately from zero events. |
| Measurement validity | Compare with an independently reviewed reference using the same event definition. Record sample size, selection, exclusions and disagreements. |
| Timing and location | Event time versus receipt time; clock source, offset, drift, time zone, zone geometry and location reference. |
| Consistency | Duplicates, reprocessing, version changes, aggregation intervals and incompatible class definitions. |
| Representativeness | Whether reviewed conditions cover the proposed use, including difficult conditions and relevant rare events. |
Test the failure modes
Inspect missed and false detections separately. Check class confusion and interval differences as well as totals: misses and duplicates can cancel. Build the reference without first showing reviewers the system answer. Keep validation records separate from tuning records. Repeated observations of one event are not independent confirmations.
Record uncertainty and the denominator behind each rate. Limit conclusions to the sampled population and conditions. OAIC guidance provides a useful quality lens: accuracy, currency, completeness and relevance, with effort proportionate to adverse consequences [R1].
03. Separate a plate reading from a finding
ANPR produces a proposed reading from an observation. Review detection, recognition, matching and interpretation as separate layers. Each layer needs evidence appropriate to the intended decision.
| Layer | Review question | Boundary |
|---|---|---|
| Detection | Was a plate region found in the relevant observation? | Detection alone establishes neither the characters nor identity. |
| Recognition | Are the characters and plate context readable in the authorised source image? | A plausible string requires a source check. |
| Matching | Do the observations refer to the same plate and event sequence? | Similar characters, multiple candidates and repeat visits create ambiguity. |
| Interpretation | What movement or presence does the sequence demonstrate? | An entry/exit pair establishes bounding observations, not continuous dwell by itself. |
| Decision | Does the finding meet the approved use and review pathway? | A vehicle observation alone identifies neither a driver nor a breach. |
Preserve the original reading
Retain the engine output and separately attribute any human transcription. Record obscured characters and alternative candidates. Keep uncertain characters uncertain rather than guessing a replacement. Review authorised image context where available and explain what the view cannot resolve.
Validate pairing before deriving duration
Agree the time basis, direction, zone, sequence rules and treatment of repeat visits, duplicate and unpaired records. Check routes outside the capture area. A single observation establishes presence at that observation time; calculating a duration requires additional evidence and explicit assumptions.
Describe a derived interval precisely: the time between the accepted bounding observations, the pairing rule and any continuity assumption. If an unseen exit or ambiguous match changes the interpretation, escalate or issue a limited finding.
Treat confidence scores as model outputs
An engine score is not automatically a probability that a plate, event match or allegation is correct. Validate any screening rule against local reference data for the intended task. Record the engine version, score definition and operating conditions. Revalidate the rule when those inputs change.
A supplier's engine documentation explains its output. Local validation determines fitness for the council's question. Preserve that distinction in the finding and the decision record.
04. Register sources and resolve conflicts
Assign every source a stable ID and approved repository reference. Link derived records to their parents and link findings to the source IDs they rely on. Preserve originals as received and label working copies and corrected versions.
| Source-register field | Required entry |
|---|---|
| Identity and custody | Source ID, origin/custodian, repository reference, file/version, date received and transfer history. |
| Coverage and timing | Site/zone/direction, start/end, named time zone and offset, event/receipt time, clock source and uncertainty. |
| Collection context | Unit ID, view/placement, configuration and engine/model version, changes, outages and blind spots. |
| Transformation lineage | Parent IDs, query/filter, matching and deduplication rules, software/version, operator, run time, exclusions and output ID. |
| Integrity and quality | Original status, integrity checks, quality results, unresolved gaps and fitness-for-use assessment. |
| Handling and linkage | Purpose/access authority, retention/disposal reference, hold status, reviewer, related findings and decisions. |
A checksum shows whether a file has changed since a recorded check. Collection accuracy and completeness require separate checks. Log time corrections, redactions and reprocessing as transformations; keep earlier versions traceable. Retain the calculation or query so another analyst can repeat it.
Resolve disagreements explicitly
- Log competing source IDs and statements. A conflict is material if the alternatives change the finding, action or review level.
- Align event definitions, coverage, time bases, directions and zones before comparing results.
- Check source dependence. Two displays fed by one stream are one origin, not independent corroboration.
- Inspect authorised originals and configuration history. Have a second competent reviewer assess decision-critical disputed material independently, then record reconciliation.
- Test defensible alternative matching rules, time corrections and exclusions. If the action changes, gather more evidence or escalate. Otherwise explain why it remains appropriate.
Keep unresolved alternatives in the finding. Distinguish measurement error, missing coverage, uncertain matching and uncertainty about generalising. Narrow the conclusion when evidence leaves a decision-critical gap.
Apply approved access, disclosure, retention and hold rules throughout. Use redacted public derivatives only where authorised. A hashed plate identifier still needs a re-identification assessment [R2].
05. Set thresholds before reviewing outcomes
Set evidence-sufficiency and review thresholds from decision risk and validation evidence before assessing results. Choose accuracy, sample-size, score, duration and discrepancy rules for the specific use, rather than adopting a universal number.
Build a threshold plan
- Define the consequence. Record the harm of wrong and missed actions, safety, individual impact, privacy and reversibility. Identify the delegation and decision requirements.
- Identify decisive failure modes. Choose metrics and a reference method that expose decision-changing errors. Separate engine screening rules, evidence sufficiency and policy criteria.
- Validate locally. Use representative independent reference records, difficult conditions and relevant rare events. Set sampling effort to bound decision risk. Record uncertainty and reference disagreement.
- Set and approve the rules. Select tolerances from validation evidence and the council's risk approach. Define exclusion, retesting, second-review and escalation rules. Obtain technical and decision-owner approval before use.
- Control changes. Record version, rationale and operating boundaries. Review the plan after changed engines, configuration, purposes or material conditions. Preserve earlier criteria and results.
| Trigger to define | Review route |
|---|---|
| Critical source, provenance or authority gap | Hold the affected use and refer to the source custodian or responsible governance officer. |
| Ambiguous identity, material conflict or sensitivity that changes the action | Independent second technical review, then further collection or a bounded/inconclusive finding. |
| Adverse individual action, significant safety consequence or action outside delegation | Authorised decision owner and the required specialist pathway before action. |
| Changed configuration or failed monitoring check | Suspend affected reliance, investigate and revalidate the relevant use. |
Record the uncertainty that matters
State alternatives that change the decision. Use numerical bounds where sampling supports them. An inconclusive finding is a valid outcome. NIST's overview describes voluntary management of AI risks to individuals, organisations and society [R3]; councils set their operational rules.
06. Sign the finding, authorise the decision
Assign competent people and record their roles, delegations and conflicts of interest. Suppliers explain their outputs; the council owns its engineering judgement and decisions.
| Role | Sign-off gate |
|---|---|
| Review owner | Approves the question, intended use and threshold plan before assessment. |
| Source custodian | Confirms origin, versions, transfer, permissions and gaps when accepting or replacing the evidence pack. |
| Technical reviewer | Signs the bounded finding and quality assessment before submission for decision. |
| Independent second reviewer | Signs a separate conclusion and reconciliation when an escalation rule is triggered, before decision approval. |
| Responsible specialist | Records advice on privacy, records, legal or other required matters before the affected use. |
| Authorised decision owner | Signs the current decision version, delegation, reasons and conditions before action. |
| Follow-up owner | Records implementation, verification and closure, or refers new evidence for review. |
Combine administrative roles only where council policy permits. Preserve independence wherever second review is required. Each signature identifies the person, role, record version and date/time with its time zone. Material changes require renewed approval; retain the superseded record.
Write a bounded finding
Separate observed facts from inference. Include source IDs, period, event definition, checks, limitations and competing explanations. Choose a disposition: supported, supported with limits, inconclusive or not supported. These are workflow labels. Explain whether evidence fails to support a proposition or actively contradicts it.
Make the decision explicit
Record options, including further collection and no action. State the chosen action, authority/delegation, reasons, residual uncertainty and conditions. Explain any departure from the technical recommendation without rewriting the finding. Apply the approved individual compliance process where relevant.
Close the loop
Assign a follow-up owner, due date and verification method. Define reopening triggers: new evidence, a challenge, source faults or material site changes. Check completion separately from approval. When an error affects other decisions or reports, link corrections to the originals and notify authorised record users through the approved process.
07. Completed illustrative decision record
ILLUSTRATIVE AND HYPOTHETICAL. All events, source IDs, authorities, role-signatures and outcomes are invented for teaching, not real approvals or XVision results. All times use Asia/Manila (UTC+8).
The question concerns a layout inspection, not whether a particular vehicle was non-compliant. Incomplete evidence supports a bounded, reversible action.
| Field | Completed illustrative entry |
|---|---|
| Record identity and status | ILL-01 / DEC-01 v1.1; closed after inspection. Hypothetical record. |
| Question and scope | Justify a layout inspection at fictional Loading Area A? 2 Nov 2026, 09:00-11:00 Asia/Manila (UTC+8). Individual non-compliance excluded. |
| Authority and ownership | Engineering coordinator owns review. Fictional authority ENG-A permits a layout inspection only. |
| Review plan | PLAN-01 v1, approved 1 Nov 2026 by coordinator/manager. Ambiguous matches or decision-critical gaps trigger second review. |
| Evidence pack | REG-01 v1: H-A export, H-B images, H-C health/clock log, H-D layout. Originals H-A/v1 to H-D/v1: illustrative Case ILL-01 repository. LOG-01: transformation history. |
| Quality assessment | H-A/H-B share an origin; H-B obscures a character. H-C records a gap; H-D shows an unseen route. Timing aligned; continuity unresolved. |
| Conflicts and uncertainty | CON-01: continuous visit versus repeat visits. Pairing assumptions change dwell interpretation; either supports checking the layout. |
| Finding | Inconclusive for continuous dwell. Bounding observations support a layout inspection only, not individual non-compliance. |
| Technical approval | Traffic engineer role-signature: FIND-01 v1, 3 Nov 2026, 10:00 Asia/Manila. |
| Second/specialist review | Asset engineer independently reviewed originals, agreed and role-signed REV-01, 3 Nov 2026, 11:00 Asia/Manila. GOV-01 confirms inspection-only use. |
| Decision and reasons | Options: close, inspect or collect more. Inspect: reversible and proportionate to coverage uncertainty. Exclude individual compliance action. |
| Decision approval | Manager role-signature: DEC-01 v1 under ENG-A, 3 Nov 2026, 14:00 Asia/Manila. |
| Follow-up | Asset officer: inspect route visibility/layout by 6 Nov 2026; verify with site notes/sketch H-E. |
| Closure and reopening | H-E/v1 confirms unseen route. Manager role-signed closure, 6 Nov 2026, 16:00 Asia/Manila. Reopen on new evidence, changed geometry or correction. |
| Handling and retention | Engineering-review access only; no public identifiers. Fictional classification ENG-REV-01; RET-01 requires records-officer disposal approval and hold check. |
| Correction history | ERR-01: no source correction found. DEC-01 v1.1 adds H-E/closure; retains v1 decision and FIND-01 v1. |
08. Evidence review checklist
Review ID: ____________________ Reviewer: ____________________
Date/time and time zone: ____________________ Record version: __________
Tick one result per row. Record a reference and initials. Explain each N/A and each failure in the review record. A decision-critical failure holds the affected use until resolved or explicitly excluded.
| Check | Pass | Fail | N/A | Ref | Initials |
|---|---|---|---|---|---|
| The question and event definition are recorded. | ☐ | ☐ | ☐ | ||
| The location, direction, period and excluded uses are set. | ☐ | ☐ | ☐ | ||
| The intended action and authority are recorded. | ☐ | ☐ | ☐ | ||
| The review roles and required independence are assigned. | ☐ | ☐ | ☐ | ||
| The threshold plan was approved before assessment. | ☐ | ☐ | ☐ | ||
| Original sources and versions are registered. | ☐ | ☐ | ☐ | ||
| Collection, use and access permissions are confirmed. | ☐ | ☐ | ☐ | ||
| Coverage gaps and selection limits are recorded. | ☐ | ☐ | ☐ | ||
| The output has been checked against its reference. | ☐ | ☐ | ☐ | ||
| Timing, location and configuration checks are complete. | ☐ | ☐ | ☐ | ||
| ANPR matching and continuity assumptions are addressed. | ☐ | ☐ | ☐ | ||
| Transformations and corrections link to originals. | ☐ | ☐ | ☐ | ||
| Conflicts and decision-sensitive uncertainty are resolved or bounded. | ☐ | ☐ | ☐ | ||
| The technical finding is signed with source links. | ☐ | ☐ | ☐ | ||
| Required second and specialist reviews are recorded. | ☐ | ☐ | ☐ | ||
| The authorised decision and reasons are signed. | ☐ | ☐ | ☐ | ||
| Follow-up, verification and reopening triggers are assigned. | ☐ | ☐ | ☐ | ||
| Access, retention and hold checks are recorded. | ☐ | ☐ | ☐ |
Gate outcome: ☐ Proceed for stated use ☐ Hold and gather ☐ Escalate ☐ Close
Outcome owner/signature: ____________________ Date/time/zone: __________
Reason or review-record reference: _____________________________________
Standalone editable versions: Word checklist
09. Blank decision-record template
Complete this record in the council's approved recordkeeping system. Link the source register and supporting records; keep identifying details in controlled evidence files. Include record versions and date/time/time zone with each approval.
| Field | Record entry |
|---|---|
| Record identity and status | |
| Question and scope | |
| Authority and ownership | |
| Review plan | |
| Evidence pack | |
| Quality assessment | |
| Conflicts and uncertainty | |
| Finding | |
| Technical approval | |
| Second/specialist review | |
| Decision and reasons | |
| Decision approval | |
| Follow-up | |
| Closure and reopening | |
| Handling and retention | |
| Correction history |
Standalone editable versions: Word decision record
10. Follow-up and public reference register
Put the method into practice
Start with one engineering question. Agree the source inventory, review roles, thresholds and records location. Use the checklist to check completeness and the decision record to capture judgement. Test the process with missing and conflicting evidence before extending it to another source or purpose.
Set review intervals from consequence, failure modes and rate of change. Review earlier after configuration changes, new conditions, complaints or source faults. Track completion, reopened cases and corrections. Assess road outcomes separately from review completion.
Public reference register
These public sources inform the quality, handling and governance principles. The detailed workflow is this paper's engineering recommendation. Sources were read on 7 November 2026. OAIC guidance addresses APP entities; the council's responsible officers determine the applicable local regime.
| ID | Public source | Supports |
|---|---|---|
| R1 | OAIC, APP Guidelines, Chapter 10: Quality of personal information, v1.1, 22 July 2019. | Purpose-specific accuracy, currency, completeness and relevance; consequence-based quality effort. Sections 02 and 05. |
| R2 | OAIC, APP Guidelines, Chapter 11: Security of personal information, v1.3, updated 3 October 2025. | Lifecycle protection, retention exceptions and re-identification risk. Section 04. |
| R3 | NIST, AI Risk Management Framework, public overview webpage. | Voluntary risk-governance context only. Section 05. |
R3: https://www.nist.gov/itl/ai-risk-management-framework
Discuss a Location
Contact XVision to discuss the evidence and review needs for a road location.
