The short answer
Use AI to support analysis and keep decisions with the responsible people.
An implementable correlation specification covering intended use, canonical event schema, source authority, time quality, identity boundaries, correlation rules, confidence display, evidence links, test fixtures, observability, fallback, and approval gates.
Fit before tools
Use this workflow only when the operating conditions fit.
Use it when
- The operational question requires more than one approved source.
- System owners can provide documented interfaces and representative fixtures.
- The organization can test missing, late, duplicated, and conflicting events.
- A human remains responsible for investigation and response.
Do not use it
- To infer criminal intent, identity, or insider threat from proximity in time.
- To merge identities without approved identity governance.
- To auto-dispatch or deny access from an unvalidated correlation.
Prepare first
Define the approved input before opening an AI tool.
Inputs to prepare
- Canonical source and event identifiers
- Event type and schema version
- Occurred-at, observed-at, and received-at timestamps
- Clock source and known uncertainty
- Source confidence and provenance link
- Subject or object reference under approved identity rules
- Site or zone alias and sensitivity
- Raw-source retrieval pointer and retention
Keep out of the workflow
- Uncontrolled identity resolution
- Biometric inference without separate approval
- Hidden source weighting
- Correlations that cannot link back to original evidence
- Automated consequential actions without validated authority
Default rule: If the information boundary is not explicit, do not paste, upload, connect, or transmit the material. Practice with made-up information until the responsible owner approves the tool and information you can use.
Implementation workflow
Complete the work in six reviewable steps.
- 01
Define intended and prohibited use
Write the exact analyst question and the decisions the result may and may not support. Example: assemble relevant records for review—not determine whether a person acted maliciously.
- 02
Create the canonical event contract
Specify IDs, types, timestamps, time uncertainty, zone aliases, subject/object references, provenance, schema version, and raw-evidence pointer. Reject or quarantine events that fail required fields.
- 03
Establish source authority
For each field identify the authoritative system, reconciliation rule, and conflict display. Access status, video observation, identity, maintenance state, and incident disposition may have different authorities.
- 04
Design bounded rules
Start with transparent windows and prerequisites. Example: an access-denied event and a door-forced event in the same approved zone within 30 seconds create a review bundle only if both clocks meet the quality threshold.
- 05
Build adversarial fixtures
Test late, duplicated, reordered, missing, spoofed, stale, and conflicting events; daylight-saving changes; device replacement; identity reassignment; network recovery bursts; and source unavailability.
- 06
Operate with provenance and fallback
Display why the bundle exists, which evidence is missing, source freshness, rule version, and confidence limits. Preserve manual investigation when correlation is unavailable or rejected.
Copyable working aid
Use this template, then adapt it to the approved workflow.
The template deliberately exposes missing evidence and preserves human approval. Replace bracketed fields; do not paste prohibited information.
CORRELATION SPECIFICATION
Intended analyst question: [question]
Prohibited decisions: identity, intent, guilt, autonomous access/dispatch
REQUIRED EVENT FIELDS
event_id | source | source_event_id | event_type | occurred_at | observed_at | received_at | clock_quality | zone_alias | subject_ref_policy | confidence | provenance_uri | schema_version
RULE
Prerequisite events: [types]
Same-zone requirement: [definition]
Time window: [seconds]
Minimum clock quality: [threshold]
Missing-source behavior: [hold, display, or reject]
Output: review bundle with source citations
TEST FIXTURES
normal | late | duplicate | reordered | missing | conflict | clock drift | network recovery burst | identity reassignment | source unavailable
HUMAN GATE
[Role that verifies evidence and decides the next action]Worked example
A finished example you can check.
These fictional examples and corrections illustrate the review process. They are not records of real incidents or measured model performance.
An access-denied event and door-forced event occur near the same time, but the door controller clock is 94 seconds out of tolerance after a network outage.
Two canonical events with occurred, received, and clock-quality fields plus network-health context.
CORRELATION REVIEW BUNDLE — CLOCK QUALITY FAILED Sources: Access-denied and door-forced events occurred near the same time. Retain canonical events separately with provenance, occurred/received times, and clock quality. Decision: Reject high-confidence correlation. The controller clock is 94 seconds out of tolerance after a network outage. Apparent proximity does not establish event order or shared cause. Analyst view: Show both events as a low-confidence review bundle; prominently flag clock failure and preserve original timestamps. Do not silently shift a time to make the rule match. Follow-up: The system owner must verify synchronization and clock-quality reporting. Assess corrected or independently corroborated evidence before another review. Boundary: No identity, intent, access, or dispatch decision follows from this bundle. Human verification is required.
- Do not say the denied access attempt caused the door-forced event; clock drift prevents a reliable sequence from these records alone.
Quality control
Review the artifact and measure whether it improved the work.
Release checklist
- Every correlation serves a documented analyst question.
- Original evidence remains retrievable and immutable under the normal system of record.
- Clock quality and source freshness influence the result visibly.
- Identity resolution follows approved governance and is not inferred from proximity.
- Failure fixtures cover missing, late, duplicate, conflict, and recovery conditions.
- Manual investigation and response remain available when correlation fails.
Measures worth tracking
- Precision of review bundles against adjudicated fixtures
- Missed relevant-event rate
- Bundles rejected for time or data quality
- Median evidence-assembly time
- Operator correction and unbundle rate
- Source availability and schema-rejection rate
- Rules changed without completed regression test
Stop conditions
Treat these outcomes as failures, not minor editing issues.
Temporal proximity is treated as intent.
A clock problem creates a false sequence.
A shared identifier is reused or reassigned across systems.
The bundle cannot explain why an event was included or retrieve the source record.
Escalate instead of improvising: Site-specific risk assessment, emergency action, legal interpretation, employment action, identity determination, biometric use, and consequential access or dispatch decisions require the approved professional and organizational process.
Practical questions
Questions to resolve before operational use.
Should correlation use machine learning or rules?
Begin with the simplest method that can satisfy the use case and be tested. Transparent rules often provide a better initial control surface; learned methods still need traceable inputs, evaluation, and explanation appropriate to consequence.
What time should be stored?
Store at least when the event occurred at the source and when it was received, plus clock-quality information. An observation or processing timestamp may also be necessary.
Can a correlation trigger an automated response?
Only after separate authorization, representative validation, safe failure behavior, and clear accountability appropriate to the consequence. This guide specifies analyst review bundles, not autonomous action.
Sources and scope
Use authoritative guidance, then apply the organization’s own requirements.
- NIST AI Risk Management Framework Voluntary framework for governing, mapping, measuring, and managing AI risk across the lifecycle.
- CISA Guidelines for Secure AI System Development Secure-by-design guidance covering development, deployment, and operation of AI systems.
- ONVIF Profile M Official interfaces for analytics metadata, events, object classes, and rule configuration.
This guide is vendor-neutral practitioner planning guidance, updated 2026-09-07. It is not a compliance determination, site risk assessment, emergency procedure, or substitute for qualified legal, privacy, cybersecurity, safety, engineering, or security review. Product capabilities and applicable requirements change; verify them with current primary documentation.
Next step
Finished reading? Turn the pattern into practice.
Analytics validation
Read guideInteroperability Planner
Open toolProgress is saved only in this browser. Nothing is sent to physicalsecurity.AI.