Documentation

ORTUS CHEQIT Customer Release Notes

Version: 1.0.1

Released: 2026-07-29

Release-candidate preview updated: 2026-08-13

Release Summary

This release provides the installed ORTUS CHEQIT web application for on-premises CCTV health monitoring, activation-gated licensing, alert triage, connector management, signed updates, support bundles, and Enterprise federation/HA workflows.

CHEQIT is intended to help teams keep camera fleets usable by finding camera, stream, VMS, network, storage, and visual-quality issues before missing evidence becomes a business problem.

Version 1.0.1 Highlights

  • Public waiting-list and limited-release customer workflow with protected installer access.
  • Signed Linux installer and online/offline activation workflows.
  • Hardened public/customer API boundaries and request throttling.
  • Bounded artifact-retention reconciliation with path and symlink safety.
  • Signed in-place update staging, health checks, and rollback support.
  • Unattended online retrieval of customer-gated update archives for active cloud-licensed instances, using short-lived artifact-scoped grants.
  • Durable audit, redacted support bundles, and verified backup/restore procedures.
  • Improved live fleet health rendering and evidence-backed degradation monitoring.
  • Security and dependency refresh with no reachable Go vulnerability or npm audit finding at release validation.

Included Capabilities

  • Web dashboard with Nexus, Tree, and Map fleet views.
  • Alerts Console with search, filters, sorting, pagination, live update handling, and batch actions.
  • Alert detail pages with timeline, occurrences, image evidence, VMS archive video review where available, downloadable evidence clips, and workflow actions.
  • Activation-first operation: online activation, offline key-file activation, and delegated federation activation.
  • Licence entitlement enforcement for features, alert types, connectors, and camera allocation.
  • Camera limit management with manual selection, grouping, search, filters, sorting, pagination, and warning confirmation.
  • Local user management and profile/security workflows.
  • Enterprise authentication configuration for OIDC, LDAP/Active Directory, and trusted SAML proxy mode.
  • Per-user email notification opt-in with immediate or digest delivery.
  • Optional additional notification recipient.
  • SMTP-backed test notification.
  • Settings -> System version/update status, support bundle, and signed update installation workflow.
  • Shinobi VMS connector.
  • Direct Camera Connector for RTSP/ONVIF sources.
  • Map upload and camera placement.
  • Enterprise federation: primary/leaf operation with leaf-initiated sync.
  • Enterprise HA: active primary plus warm standby with signed replica sync, switchover, failback, and browser/leaf endpoint fallback.

1.1.0 Avigilon and VMS release

The signed 1.1.0 release adds protected Shinobi-native snapshot/live/archive media, evidence export, automatic inventory reconciliation, connector/API health, explicit configured media-profile checks, and bounded recording-continuity checks. It also contains the lab-validated Avigilon Unity connector; Avigilon partner review remains pending and is stated separately from software release availability.

1.1.1 migration hardening

  • Explicit camera allocation now permits a VMS connector to discover the full

    authoritative fleet even when only a licensed subset is monitored. The seat limit still gates analysis, media access and alert generation.

  • Avigilon Unity connections can pin the exact SHA-256 fingerprint of a legacy

    self-signed WEP certificate that has no valid hostname, avoiding insecure TLS verification while preserving a deliberate certificate-rotation workflow.

1.1.2 Avigilon recording-policy correction

  • Avigilon connectors now distinguish continuous recording from scheduled or

    motion recording. Because Unity WEP does not expose recording schedules, the safe default no longer treats normal empty timeline periods as recording failures; administrators can explicitly enable continuous-recording checks.

  • Routine Unity recording start/stop events no longer open incidents. Explicit

    recording interruption/restoration events remain monitored.

  • Camera metadata work that is deferred by the bounded fleet scheduler no

    longer appears as a VMS API timeout. Completed query failures remain actionable.

  • A successful empty Unity timeline window is not treated as archive failure

    for scheduled or motion recording. It remains actionable when continuous recording is explicitly expected; failed timeline queries and Unity storage events remain actionable in both modes.

1.1.4 orientation-baseline recovery

  • Accepting the current orientation for a rotation alert now remains available

    when an older or migrated incident no longer retains its original current frame. Cheqit requests a fresh snapshot through the owning VMS connector, stores it as evidence, analyses it through the normal rotation model, updates the approved orientation and records the operator action in the audit trail.

  • The fallback remains VMS-first: it does not reconnect directly to the camera

    when Unity or Shinobi owns the camera.

1.1.5 migrated evidence ownership recovery

  • Camera-identity migrations now preserve the service ownership of copied

    evidence trees when the offline migration runs as root.

  • Existing migrated installations with read-only camera evidence directories

    recover without weakening filesystem permissions: new detector evidence and approved rotation/scene baselines use a camera-scoped application-owned fallback, while long-exposure history is cloned once into a writable overlay and continues updating there.

1.1.6 VMS-native structural-baseline recovery

  • Accepting the current view for camera-moved and scene-change alerts now uses

    a fresh snapshot from the owning VMS when an older or migrated incident has no retained current frame. The image is stored as normal Cheqit evidence and the operator action remains audited; Cheqit does not reconnect directly to a VMS-managed camera.

  • Artifact links addressed by kind now select the newest approved baseline, so

    migrated historical references do not hide a newer runtime baseline.

1.1.7 recurring structural scene modes

  • Camera-moved alerts can now accept an expected recurring scene mode, such as

    a camera switching between illuminated colour and low-light infrared views, without replacing the normal hourly reference view.

  • Accepted scene modes suppress both camera-moved and scene-change alerts when

    the current image matches that approved mode. A real geometric or scene deviation from every accepted mode remains actionable.

1.1.8 camera-moved scene-mode evidence

  • Camera-moved detail now shows and serves the approved recurring scene-mode

    evidence after acceptance, matching the existing scene-change workflow.

1.1.9 Unity event replay protection

  • Unity event polling now persists and compares native source-event sequence

    IDs. Polling overlap and service restarts cannot create a duplicate occurrence or reopen an operator-resolved incident from an older event.

  • Genuinely newer Unity transitions remain actionable and repeated native

    detections continue to be grouped into the same incident history.

1.1.10 Unity tamper lifecycle and fleet-scale queue

  • Unity DEVICE_TAMPERING incidents now recover safely when no newer native

    event has arrived during the quiet period, the camera is active and online, a fresh Unity snapshot succeeds, and Cheqit's independent structural analysis does not still see a moved or changed scene.

  • Matching Unity and Cheqit structural signals appear as one Alert Queue

    incident, labelled Cheqit + Unity, while each source retains its own event identity, evidence and immutable history.

  • Hard-freeze detection now requires exact-frame or independent decoded-content

    confirmation. Naturally still scenes and normal JPEG recompression noise no longer qualify from a perceptual scene hash alone.

  • The current Alert Queue uses a compact persisted projection over long alert

    histories. Licence hardware identity is cached and evidence entitlement is evaluated once per response, substantially reducing cold latency and request-time allocations on large retained histories.

1.1.11 Alert Queue sustained-load hardening

  • Routine evidence and message refreshes within an existing alert cycle now

    rebuild only the current Alert Queue rows. Exact retained-cycle totals stay cached until a change can actually affect them, avoiding repeated history scans while monitoring a busy fleet.

  • The persisted occurrence store adds a composite current-cycle index, and the

    live-row query now starts from current alert cycles instead of ranking the complete occurrence history.

  • New incidents, reopened cycles, status transitions, camera allocation

    changes and inventory changes still invalidate the relevant exact summary; the optimization does not trade queue accuracy or authorization for speed.

1.1.12 Incremental Alert Queue summaries

  • Status transitions, reopened cycles and new alert families now refresh only

    the affected retained-history families instead of reconstructing the whole retained queue. Exact counts, camera allocation and access filtering are preserved.

  • The affected-family refresh is indexed and batched between operator

    requests, so rapid detector changes remain bounded by the number of changed families rather than the total retained history.

  • Inventory and licence changes still force a complete correctness-preserving

    rebuild because they can change visibility across the whole fleet.

1.1.13 Stable inventory observations

  • Routine connector inventory observations no longer invalidate retained Alert

    Queue summaries when camera identity, allocation order, lifecycle and access scope are unchanged.

  • Online/offline state, last-seen time, firmware telemetry and observation

    timestamps can continue updating without tying operator queue latency to the complete retained history.

  • A real camera add/remove, lifecycle, name/first-seen allocation, site,

    hierarchy or scope-tag change still performs a full correctness-preserving invalidation.

1.1.16 Accurate installed-update restart state

  • Settings -> System now reports Restart: Not pending after the latest signed

    release is installed. The manifest's install-time restart requirement is shown only while that release is actually available, avoiding the contradictory Up to date / Restart required state.

  • The live Avigilon cutover verifier accepts version text embedded in the

    installed-build presentation, and the inventory transition observer reads the current Nexus openAlerts field while retaining compatibility with the older field name.

1.1.15 Bounded rotation analysis and safer update publishing

  • Rotation analysis now uses a bounded admission queue in addition to its

    bounded worker pool. A fleet burst cannot turn camera monitor routines into an unbounded inference backlog, and time spent waiting for a worker no longer consumes the admitted request's execution budget.

  • Capacity and execution timeouts are inconclusive checks: an existing camera

    rotation incident is not cleared and the check is retried on a later clean frame.

  • The public Pages deployment workflow now verifies both the candidate and live

    signed release sets and refuses version regressions, same-version content replacement, signing-key changes, and unavailable or unverifiable baselines.

1.1.14 Stable licence check-ins

  • Routine connected-licence check-ins no longer invalidate retained Alert

    Queue summaries when the active state and effective camera allocation are unchanged.

  • A real activation or camera-entitlement change still performs a full

    correctness-preserving invalidation, while alert-family changes retain the indexed incremental refresh introduced in 1.1.12.

Installation And Activation

Install CHEQIT on a Linux host using the signed release archive and systemd installer. After installation:

  1. Sign in as admin.
  2. Activate online with an activation code or offline with signed .key files.
  3. Confirm Settings -> Licensing shows the expected plan, expiry, features, alert types, and camera allocation.
  4. Add connectors and confirm cameras appear in the dashboard.

Before activation, normal monitoring and alert review are locked. Only the workflows needed to activate or join a licensed primary remain available.

Updates

CHEQIT supports signed in-place updates through Settings -> System. When a trusted update is available, an administrator can queue installation. The update worker verifies the release, backs up state, restarts the service, checks health, and rolls back on failure.

Installer archives remain customer-gated. Connected cloud-licensed instances retrieve an entitled archive automatically after an administrator confirms the update. Air-gapped and offline-licensed environments use the same signed offline update bundles, with identical signature, checksum, health-check, and rollback protections.

Instances still running 1.0.0 need the normal entitled portal download/offline bundle once to move to 1.0.1, because the grant client is introduced by this release. Updates initiated from 1.0.1 and later use unattended retrieval.

Federation And HA

Federation is intended for distributed deployments where remote sites process cameras locally but operations need a central view.

Recommended HA deployment uses:

  • one active primary,
  • one warm standby,
  • customer DNS/VIP/load balancer where possible,
  • shared session key/cookie-domain configuration for seamless browser handover.

CHEQIT can also recover without DNS/VIP movement after a prior browser load by using cached endpoint discovery and the app-shell service worker. This fallback does not help first-time visits to a dead hostname.

Current Limits

  • Windows installer is deferred to a later release.
  • Shinobi does not expose trusted recorder disk capacity, throughput, SMART,

    host-clock or complete native health-event data through the connector paths CHEQIT uses. These facts require explicitly configured supplemental telemetry. Shinobi alarm-console delivery and bidirectional alarm workflow are not included.

  • Avigilon Unity is lab validated as a release candidate, but partner review is

    still pending and it is not included as a supported workflow in this 1.0.1 release.

  • Milestone XProtect remains a planned future integration candidate and is not claimed in this release.
  • Full first-party SAML service-provider flow is not included; current SAML support is trusted proxy/gateway mode.
  • Production go-live tasks such as final pricing approval and production Stripe cutover are operational launch steps.

Recommended Post-Install Verification

  • /api/v1/health reports healthy.
  • Settings -> Licensing is active and shows the right entitlements.
  • Settings -> System can check update status.
  • Connectors test successfully.
  • Cameras appear in Nexus and Tree.
  • Camera allocation matches the licence.
  • Alerts Console loads and filters quickly.
  • Notification test email succeeds if SMTP is configured.
  • Support bundle downloads and is redacted.

Where To Find Help

Start with:

If contacting ORTUS support, include product version, deployment mode, licence source, approximate camera count, recent changes, relevant alert IDs, and a redacted support bundle.