The short answer
Use AI to support analysis and keep decisions with the responsible people.
A documented architecture decision record with workflow data flow, option comparison, measured constraints, failure modes, security and privacy controls, total lifecycle cost, observability, fallback, version ownership, and exit evidence.
Fit before tools
Use this workflow only when the operating conditions fit.
Use it when
- A defined AI workflow is moving into technical design or procurement.
- Network, compute, storage, data-residency, and operating constraints can be measured.
- Security, privacy, platform, operations, and finance owners can review the tradeoffs.
- The design can be tested under degraded conditions.
Do not use it
- To select architecture from a generic score without measured constraints.
- To assume an on-premises appliance has no external dependency.
- To accept a hybrid diagram that lacks state, synchronization, fallback, and ownership details.
Prepare first
Define the approved input before opening an AI tool.
Inputs to prepare
- Workflow steps and decision latency
- Data types, volume, sensitivity, retention, and residency
- Camera or sensor count and bitrate/event rate
- WAN bandwidth, loss, outage history, and recovery objectives
- Compute and storage lifecycle
- Model update and rollback process
- Identity, key, log, monitoring, and support ownership
- Five-year cost and exit requirements
Keep out of the workflow
- Credentials or precise sensitive architecture in an unapproved design service
- Unmeasured performance assumptions
- Single-year license comparison presented as total cost
- Hidden egress, relay, identity, update, or support dependencies
- No manual or degraded operating mode
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
Map the workflow and data
Draw capture, transport, inference, event, storage, review, export, and deletion. For each boundary record data class, volume, encryption, identity, retention, and authoritative system.
- 02
Measure non-negotiable constraints
Record maximum useful latency, required operation during WAN loss, available upstream bandwidth, acceptable data transfer, residency, retention, recovery objective, and site support capacity.
- 03
Model three real options
Describe an edge, cloud, and hybrid option using actual components and responsibilities. Include inference location, event metadata, video path, management plane, identity, updates, logs, monitoring, and evidence export.
- 04
Score with gates and weights
Use pass/fail gates for legal, security, latency, and resilience constraints. Then weight performance, operability, scalability, lifecycle cost, portability, and vendor dependency. Keep raw evidence beside every score.
- 05
Test degraded operation
Exercise WAN loss, bandwidth restriction, cloud unavailability, appliance failure, full storage, stale model, expired credential, delayed update, and recovery synchronization. Observe status and manual fallback.
- 06
Approve lifecycle and exit
Name owners for model, appliance, cloud service, interfaces, certificates, logs, support, and cost. Require configuration and evidence export, data deletion, replacement path, end-of-life notice, and tested rollback.
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.
ARCHITECTURE DECISION RECORD
Workflow: [capture → inference → event → review → evidence]
Data classes and retention: [table]
PASS/FAIL GATES
latency | WAN-loss operation | residency | security | evidence export | recovery
OPTIONS
Edge: components, data flow, dependencies, owners
Cloud: components, data flow, dependencies, owners
Hybrid: components, data flow, state synchronization, dependencies, owners
WEIGHTED CRITERIA
performance | operability | scale | lifecycle cost | observability | portability | vendor dependency
Evidence for each score: [source/test]
FAILURE TESTS
WAN loss | bandwidth | service unavailable | edge failure | storage full | stale model | expired credential | recovery
DECISION
selected option | assumptions | conditions | owner | review trigger | rollback | exit evidenceWorked 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.
A multi-site video analytic must raise review events within five seconds, continue basic detection during WAN loss, and retain video locally. Central teams need model management and aggregate health.
Measured event latency, site bitrates, WAN outage history, local retention, central staffing, model-update requirements, and five-year cost components.
ARCHITECTURE DECISION — CONDITIONAL HYBRID PREFERENCE Requirements: Raise review events within five seconds; retain video locally; continue basic detection during WAN loss. Central teams need model management and aggregate health. Preferred design for evaluation: Local inference and retention, with central management and aggregate health. This is a preference pending evidence, not verified capability. Approval gates: Measure latency under representative load. Interrupt WAN and central service separately; verify local detection, buffering, recovery, and replay. Document unavailable management functions and operator indications. Responsibilities: Assign local compute/storage ownership, model control, rollback, support, synchronization, and duplicate handling. Status: Conditional. Complete dependency mapping, failure tests, and five-year cost comparison. Revisit if latency, outages, retention, staffing, or recovery evidence fails requirements.
- Measure the five-second limit end to end. “Hybrid” alone proves neither WAN resilience nor local retention.
Quality control
Review the artifact and measure whether it improved the work.
Release checklist
- The workflow and every data boundary are explicit.
- Hard constraints are pass/fail gates before weighted preferences.
- Edge, cloud, and hybrid options include management and identity dependencies.
- Lifecycle cost includes compute, storage, bandwidth, egress, licenses, labor, refresh, monitoring, and exit.
- Degraded operation and recovery synchronization are tested.
- Configuration, evidence, logs, and data can be exported or deleted under documented exit terms.
Measures worth tracking
- End-to-end event latency median and 95th percentile
- Bandwidth and egress by site and event class
- Inference availability during WAN and service failures
- Backlog and recovery synchronization time
- Model/configuration version drift
- Five-year total lifecycle cost versus plan
- Mean time to detect and recover a failed dependency
Stop conditions
Treat these outcomes as failures, not minor editing issues.
A hybrid design has two control planes but no source-of-truth rule.
WAN recovery replays stale or duplicate events as current.
A local appliance requires a cloud license check to continue critical operation.
Exit terms cover data but not configuration, metadata, model, or audit export.
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.
Is edge always lower latency?
Not necessarily. Measure the full path, including capture, encoding, queueing, inference, event delivery, review, and evidence retrieval. Underpowered or overloaded edge hardware can add delay.
Is cloud always cheaper?
No. Compare the full lifecycle: devices, compute, storage, bandwidth, egress, licenses, operations, updates, support, refresh, monitoring, downtime, and exit.
What makes hybrid resilient?
Explicit local capability, state ownership, buffering, conflict resolution, status, recovery synchronization, tested fallback, and independent operation for the required duration—not the presence of both edge and cloud components.
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.
Membership preview
View previewInteroperability Planner
Open toolProgress is saved only in this browser. Nothing is sent to physicalsecurity.AI.