Technical Fit & Deployment Baseline
Use this page to understand what a credible first site needs technically, what is documented today, and where the current deployment boundaries still are.
This page is written for Site IT, technical evaluators, implementation leads, and integration reviewers who need to know whether the first site is technically in bounds.
Baseline at a glance
| Topic | Baseline today | Best first-site shape | Escalate or scope separately when... |
|---|---|---|---|
| Site scope | Single-site rollout is the best-supported starting point | 1 site with clear org/site ownership | multi-site rollout is required from the start |
| Cameras | RTSP-centered camera onboarding is documented | a small set of reachable, testable feeds | camera or network access is constrained or non-standard |
| Policies | Start narrow with a small number of policy types | a bounded first rule set tied to clear outcomes | many policy types must go live at once |
| Downstream workflow | Optional for the first site | incident review can stay inside Edgentik | custom workflow tailoring is a day-one requirement |
| Delivery semantics | Retry-based integration posture | at-least-once delivery with idempotent consumers | exactly-once or strict ordering is required by default |
| Readiness artifacts | CRA and SRA are documented where readiness proof is needed | use them when camera or site sign-off matters | formal acceptance artifacts are required across broader custom criteria |
Minimum first-site inputs
- one target org/site
- one operations or safety owner
- one technical point of contact
- a reachable edge device, or a clear bring-up plan
- at least one testable camera feed
- the first policy types to validate
- clear success criteria and a validation owner
The public docs assume camera-connected operation, feed testing before save, and site IT support when network conditions are constrained.
Supported deployment modes
The best-supported deployment shape today is a narrow First Site Pilot: one site, a small number of cameras, a small number of policy types, and one clear operating loop from commissioning through live review and handoff.
- Bring-Up Lane for guided commissioning
- Bring Up Device for a faster single-device path
- Device Setup for deeper direct configuration work
- Preflight for readiness before rollout
- Deployments for rollout and convergence monitoring
Supported integration posture
For a first site, incident review can stay inside Edgentik: evidence handling, diagnostics, and review materials stay in one operating loop. Downstream workflow can be added when needed, but it is not the required baseline.
The documented delivery model is retry-based and conservative: at-least-once delivery with required idempotency, not an exactly-once or globally ordered default.
Known-good first site
- the correct org/site is obvious
- at least one device is reachable
- at least one camera feed is verified and healthy
- at least one zone is saved
- at least one policy is deployed and converged
- incidents and evidence are reviewable, or the quiet state is clearly validated
- diagnostics can distinguish transient, rollout, device, and scope issues
- acceptance or handover materials can be generated when needed
Current boundaries
- broad multi-site rollout is not the default starting motion
- deep custom workflow or integration tailoring is not the default experience
- configure-everything-at-once commissioning on day one is not the documented baseline
- exactly-once delivery is not the default integration contract
- a fully local or air-gapped control-plane posture is not the documented default
If any of those are central requirements, they should be treated as explicit scoping topics rather than assumed capabilities.