One Incident Record Governing the Event From First Report to Final Resolution
The BATA architecture creates a structured incident record at the beginning of the roadside event and continuously updates that record as information, decisions, services and outcomes progress.
Each operational stage becomes part of one connected incident lifecycle rather than a series of disconnected service transactions.
Complete Roadside Incident Lifecycle
Incident Detection
The lifecycle begins when a roadside event is identified by a person, vehicle, connected platform or enterprise system.
- Motorist request
- Passenger request
- Connected vehicle alert
- Automatic crash notification
- Vehicle diagnostic event
- Insurer contact
- Fleet monitoring system
- Roadside operator
- Emergency notification
- Third-party digital platform
- Detect or receive the event
- Identify the reporting source
- Capture initial time and location
- Establish preliminary incident context
- Initiate incident-record creation
- A roadside event enters the architecture as a detected incident.
- Preliminary incident ID
- Reporting source
- Timestamp
- Initial location
- Initial event type
- Current status: detected
- Motorist
- Vehicle
- Connected platform
- Operator
- Insurer
- Fleet system
Incident Detection
The lifecycle begins when a roadside event is identified by a person, vehicle, connected platform or enterprise system.
Preliminary incident ID, reporting source, timestamp, initial location and initial event type are recorded with the status "detected".
Incident Creation
The system creates a unique structured incident record that becomes the operational control object for the event.
- Assign incident identity
- Establish incident ownership or authority
- Identify known participants
- Create initial data fields
- Establish lifecycle status
- Begin source-attributed event history
The event now exists as a persistent digital object capable of receiving, organising and governing all subsequent activity.
Information Capture
The architecture receives available incident information from the motorist, vehicle, device and connected enterprise systems.
- Receive input
- Verify format
- Timestamp information
- Attribute source
- Normalise data
- Associate information with the incident record
Each input is timestamped, source-attributed and associated with the same incident record.
Interpretation and Classification
Artificial intelligence and operational rules interpret the available information to identify the condition and characteristics of the roadside event.
- Natural-language interpretation
- Image interpretation
- Video interpretation
- Vehicle-data interpretation
- Location interpretation
- Hazard identification
- Incident classification
- Confidence assessment
Unstructured information becomes a defined and actionable representation of the incident.
Safety and Response Determination
The system evaluates safety, urgency, participant circumstances and operational requirements before initiating the response.
- Traffic exposure
- Road type
- Vehicle position
- Passenger vulnerability
- Environmental conditions
- Time of day
- Vehicle damage
- Fire or hazardous condition
- Medical concern
- Emergency-service requirement
- Roadside repair
- Battery assistance
- Tyre assistance
- Towing
- Accident recovery
- Specialist recovery
- Emergency escalation
- Passenger transport
- Temporary accommodation
- Insurer notification
The incident is assigned a response pathway based on the complete operational context.
Provider and Service Selection
The incident requirements are matched against available providers, service capabilities and commercial rules.
- Flatbed recovery capability
- Electric-vehicle certification
- Access to restricted roadway
- Response within service threshold
- Network eligibility and rate agreement
Provider A — Metro recovery
Suitability 90Provider selection reflects the complete incident requirement rather than location and availability alone.
Dispatch and Execution
The selected provider and connected participants receive the instructions and information required to execute the response.
Each execution event is written back into the structured incident record and becomes part of the lifecycle history.
Monitoring and Reassessment
The architecture continues to monitor the event after dispatch and reassesses the response when new information or operational changes occur.
- Provider assigned
- Estimated arrival 35 minutes
- Provider reports material delay
- Update estimated arrival
- Assess incident priority
- Compare alternative providers
- Determine whether reassignment is appropriate
- Notify motorist
- Update insurer or operator where required
Downstream Resolution
The structured incident record may continue to coordinate services and workflows after the initial roadside response has been completed.
- Vehicle profile
- Incident location
- Recovery requirement
- Destination and handling method
- Recovery instruction issued
- Storage arranged where required
- Recovery status
- Destination
Closure and Audit
The incident may be closed when all required operational and downstream workflows have reached an appropriate resolution state.
- T+00:00
- Motorist — mobile application
- Detected
- Create structured incident record
- Acknowledge receipt to motorist
- Incident record created
- Incident identity, reporting source, location
The completed incident record provides a traceable history of what occurred, what decisions were made and how the event was resolved.
How the Structured Incident Record Evolves
- Source
- Location
- Preliminary event
- Known vehicle
- Known participant
- Incident classification
- Vehicle condition
- Safety state
- Likely service requirement
- Confidence level
- Selected response
- Provider
- Pricing
- Authorisation
- Instructions
- Estimated arrival
- Provider activity
- Event updates
- Reassessment
- Recovery
- Repair
- Insurer and claim workflows
- Final outcome
- Completed services
- Commercial completion
- Full incident history
- Audit state
- Closure status
Coordinated Participant Handoffs
The structured incident record remains the common point of coordination across every participant handoff.
Parallel Workflow Orchestration
Roadside incidents may require multiple services and decisions to progress simultaneously rather than through one linear sequence.
- Provider dispatch
- Estimated arrival
- Service completion
- Customer instructions
- Escalation
- Emergency coordination
- Coverage verification
- Authorisation
- Payment pathway
- Towing destination
- Repair allocation
- Vehicle assessment
- Transport
- Accommodation
- Communications
BATA allows multiple workflows to remain connected to the same operational incident state.
Exception Management
Continuous Customer Communication
Customer communication can be generated from the current structured incident state, improving consistency between operational activity and the information provided to the motorist.
A provider has been assigned and is expected in approximately 30 minutes.
- Assigned provider
- Provider status
- Calculated arrival estimate
- Current workflow stage
Complete Lifecycle Traceability
Data Traceability
What information was received, when it was received and where it originated.
Decision Traceability
What decision was made and which incident state, rule or assessment informed it.
Workflow Traceability
What instruction was issued, to whom it was issued and how the workflow progressed.
Outcome Traceability
What service was completed, what changed during the event and how the incident was resolved.
Provider A selected against capability, distance and commercial eligibility.
Lifecycle Relevance to Agero
Agero operates across multiple stages of the roadside incident, including customer intake, dispatch, provider coordination, connected vehicle services, accident management and downstream support.
The BATA lifecycle architecture provides a patent-positioned method for connecting these activities through one persistent incident-level control object.
Continuity Across Service Stages
The incident record may preserve context as the event moves from customer intake to provider response and downstream resolution.
Dynamic Reassessment
Provider, vehicle and safety changes may trigger updated decisions without creating a disconnected service request.
Coordinated Participant Handoffs
Motorists, operators, providers, insurers and repair participants may receive information derived from the same incident state.
Downstream Workflow Extension
The incident may continue into recovery, repair, insurance and claims processes without losing its original operational context.
Operational Traceability
A complete incident history may support service review, quality management, customer support, governance and commercial reconciliation.
Incident Lifecycle Findings
The incident begins as a digital operational object rather than a temporary service request.
The structured incident record becomes more complete as new information, decisions and service events occur.
Safety, provider, commercial and workflow decisions remain connected to the current incident state.
Dispatch is one stage of the lifecycle, not the endpoint of the architecture.
Changing conditions can trigger reassessment, revised instructions and provider reassignment.
The same record can coordinate roadside, recovery, repair, insurance and customer-support workflows.
Final closure retains a traceable history of the complete event and its resolution.
Incident Lifecycle
The BATA architecture maintains one persistent incident record from the first indication of a roadside event through interpretation, response, provider activity, recovery and final resolution.
The record continuously receives new information, supports new decisions and coordinates the workflows required to progress the incident.