Approach A
Rule-based system
A conventional automation system applies rules written in advance. It does not split the event across specialist agents, and it does not choose a level of autonomy from a separate risk judgment.
Research portal / Methodology
Planned · not yet run · October 2026
Methodology
The study will build an event-driven prototype and give the same scenarios to three systems. No system has been built, and no comparison has been run.
Specified workflow
Monitor → Detect → Reason → Coordinate → Act or Escalate
Data
The initial study will use simulated or de-identified operational information. It does not require a live feed of employee tracking. The simulated environment may generate:
- Shift start and end events
- GPS and geofence events
- Guard availability
- Clock-in and clock-out events
- Patrol checkpoints
- Incidents
- Qualifications
- Overtime information
- Site requirements
- Supervisor decisions
What will be held constant
All three approaches receive equivalent test scenarios. Differences in the outcome should come from the decision procedure, not from a different case. The four scenarios are the first set. Scoring rules for the measures below are not yet defined. They will be fixed before any comparative run and published with the results.
Three approaches
Approach B
Single AI agent
One agent sees the information provided for the scenario and determines a response. The comparison does not give this agent a coordinator or a division of work by operational role.
Approach C
ASBOS multi-agent system
Field, workforce, incident, and compliance agents analyze their own areas. The supervisor agent coordinates them and selects an autonomy level from the operational risk.
A system that performs more autonomous actions but produces unsafe or incorrect decisions will not be considered superior.
Named measures
The proposal lists these measures. It does not yet define the scoring rules, so they are not treated here as an instrument.
- Successful event-resolution rate
- Average response time
- Incorrect action rate
- Unsafe action rate
- Correct escalation rate
- Unnecessary escalation rate
- Number of human interventions
- Percentage of operational steps automated
- Decision consistency
- Policy violations
- Decision auditability
- Estimated reduction in human operational workload
Conditions the tests should include
An operational system has to be judged when dependencies fail, not only on a clean run. The plan is to include cases in which:
- An SMS message fails
- An email is delayed
- A webhook is retried
- A telephone call is unanswered
- A GPS event is missing
- Several operational events occur at the same time
Some scenarios may be repeated hundreds or thousands of times so the three approaches can be compared. Communication is part of the operation, so message, email, and voice tests are in the plan. Repetition counts are not fixed. No repetitions have been executed.
What this method will not support
A higher automation rate will not be reported as a better system if incorrect or unsafe actions rise. The study will not treat a location anomaly as misconduct. It will not treat a simulated run as evidence about a named security company, and it will not use live employee tracking in the initial experiment.