← Back to resource library

Resource Library

Evidence review frameworks for local government

By XVision Engineering

  • Evidence Frameworks
  • Local government
  • ANPR evidence
  • Decision records
Evidence review frameworks for local government

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

  1. Review evidence before acting
  2. Define the question and assess the evidence
  3. Separate a plate reading from a finding
  4. Register sources and resolve conflicts
  5. Set thresholds before reviewing outcomes
  6. Sign the finding, authorise the decision
  7. Completed illustrative decision record
  8. Evidence review checklist
  9. Blank decision-record template
  10. 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.

Evidence review chain

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 checkTest and record
RelevanceSame event definition, place, direction and period as the question.
CoverageExpected operation versus files and health logs; gaps, blind routes and blocked views. Treat missing observations separately from zero events.
Measurement validityCompare with an independently reviewed reference using the same event definition. Record sample size, selection, exclusions and disagreements.
Timing and locationEvent time versus receipt time; clock source, offset, drift, time zone, zone geometry and location reference.
ConsistencyDuplicates, reprocessing, version changes, aggregation intervals and incompatible class definitions.
RepresentativenessWhether 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.

LayerReview questionBoundary
DetectionWas a plate region found in the relevant observation?Detection alone establishes neither the characters nor identity.
RecognitionAre the characters and plate context readable in the authorised source image?A plausible string requires a source check.
MatchingDo the observations refer to the same plate and event sequence?Similar characters, multiple candidates and repeat visits create ambiguity.
InterpretationWhat movement or presence does the sequence demonstrate?An entry/exit pair establishes bounding observations, not continuous dwell by itself.
DecisionDoes 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 fieldRequired entry
Identity and custodySource ID, origin/custodian, repository reference, file/version, date received and transfer history.
Coverage and timingSite/zone/direction, start/end, named time zone and offset, event/receipt time, clock source and uncertainty.
Collection contextUnit ID, view/placement, configuration and engine/model version, changes, outages and blind spots.
Transformation lineageParent IDs, query/filter, matching and deduplication rules, software/version, operator, run time, exclusions and output ID.
Integrity and qualityOriginal status, integrity checks, quality results, unresolved gaps and fitness-for-use assessment.
Handling and linkagePurpose/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

  1. Log competing source IDs and statements. A conflict is material if the alternatives change the finding, action or review level.
  2. Align event definitions, coverage, time bases, directions and zones before comparing results.
  3. Check source dependence. Two displays fed by one stream are one origin, not independent corroboration.
  4. Inspect authorised originals and configuration history. Have a second competent reviewer assess decision-critical disputed material independently, then record reconciliation.
  5. 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

  1. Define the consequence. Record the harm of wrong and missed actions, safety, individual impact, privacy and reversibility. Identify the delegation and decision requirements.
  2. Identify decisive failure modes. Choose metrics and a reference method that expose decision-changing errors. Separate engine screening rules, evidence sufficiency and policy criteria.
  3. 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.
  4. 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.
  5. 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 defineReview route
Critical source, provenance or authority gapHold the affected use and refer to the source custodian or responsible governance officer.
Ambiguous identity, material conflict or sensitivity that changes the actionIndependent second technical review, then further collection or a bounded/inconclusive finding.
Adverse individual action, significant safety consequence or action outside delegationAuthorised decision owner and the required specialist pathway before action.
Changed configuration or failed monitoring checkSuspend 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.

RoleSign-off gate
Review ownerApproves the question, intended use and threshold plan before assessment.
Source custodianConfirms origin, versions, transfer, permissions and gaps when accepting or replacing the evidence pack.
Technical reviewerSigns the bounded finding and quality assessment before submission for decision.
Independent second reviewerSigns a separate conclusion and reconciliation when an escalation rule is triggered, before decision approval.
Responsible specialistRecords advice on privacy, records, legal or other required matters before the affected use.
Authorised decision ownerSigns the current decision version, delegation, reasons and conditions before action.
Follow-up ownerRecords 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.

FieldCompleted illustrative entry
Record identity and statusILL-01 / DEC-01 v1.1; closed after inspection. Hypothetical record.
Question and scopeJustify 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 ownershipEngineering coordinator owns review. Fictional authority ENG-A permits a layout inspection only.
Review planPLAN-01 v1, approved 1 Nov 2026 by coordinator/manager. Ambiguous matches or decision-critical gaps trigger second review.
Evidence packREG-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 assessmentH-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 uncertaintyCON-01: continuous visit versus repeat visits. Pairing assumptions change dwell interpretation; either supports checking the layout.
FindingInconclusive for continuous dwell. Bounding observations support a layout inspection only, not individual non-compliance.
Technical approvalTraffic engineer role-signature: FIND-01 v1, 3 Nov 2026, 10:00 Asia/Manila.
Second/specialist reviewAsset 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 reasonsOptions: close, inspect or collect more. Inspect: reversible and proportionate to coverage uncertainty. Exclude individual compliance action.
Decision approvalManager role-signature: DEC-01 v1 under ENG-A, 3 Nov 2026, 14:00 Asia/Manila.
Follow-upAsset officer: inspect route visibility/layout by 6 Nov 2026; verify with site notes/sketch H-E.
Closure and reopeningH-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 retentionEngineering-review access only; no public identifiers. Fictional classification ENG-REV-01; RET-01 requires records-officer disposal approval and hold check.
Correction historyERR-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.

CheckPassFailN/ARefInitials
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.

FieldRecord 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.

IDPublic sourceSupports
R1OAIC, 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.
R2OAIC, APP Guidelines, Chapter 11: Security of personal information, v1.3, updated 3 October 2025.Lifecycle protection, retention exceptions and re-identification risk. Section 04.
R3NIST, AI Risk Management Framework, public overview webpage.Voluntary risk-governance context only. Section 05.

R1: https://www.oaic.gov.au/privacy/australian-privacy-principles-guidelines/chapter-10-app-10-quality-of-personal-information

R2: https://www.oaic.gov.au/privacy/australian-privacy-principles-guidelines/chapter-11-app-11-security-of-personal-information

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.

Discuss a Location