Product vision hypothesis

Turn security-system faults into verified service outcomes.

A proposed security-health service for multi-site customers. Cobalt and its local partners would connect selected technical events to accountable service work and keep each issue open until restoration is confirmed.

Security platforms connect through reusable Cobalt capabilities and a local service partner to produce verified outcomes across district campuses.

The operating gap

The gap starts after the alert.

Cameras, access control, alarms, and safety devices already report technical problems. The harder part is connecting the right alert to context, an owner, service work, and proof that the system is healthy again.

Security systems across several schools produce technical alerts, but fragmented ownership interrupts the path to verified restoration.
The operating gap Useful alerts still need context, a service owner, and proof that the underlying system is healthy again.

From event to resolution

From fault to verified restoration.

The proposed service would turn approved technical events into traceable work. An issue stays open until the system reports healthy again or a person verifies the repair.

A security-system fault moves through filtering, service management, technician repair, verification, and district reporting.
  1. 01Detect

    Receive an approved technical event.

  2. 02Enrich

    Add site, device, history, and service context.

  3. 03Prioritize

    Filter noise and surface the work that matters.

  4. 04Assign

    Route the issue to a named owner.

  5. 05Resolve

    Track field service through remediation.

  6. 06Verify

    Confirm restoration and update readiness.

What the customer gets

A clearer view across every campus.

School teams would see active issues and resolution status. District leaders would see system health across campuses, service performance, and recurring faults without reconciling separate systems by hand.

  • Current system availability and unresolved faults
  • Time to acknowledge, assign, and restore service
  • Recurring issues across devices and campuses
  • Proactive service compared with reactive repair

Scope boundary Emergency response remains with school and district protocols. The proposed service focuses on the technical health of the systems that support those protocols.

A district-wide operating view connects the technical health of multiple schools while a local technician resolves an active fault.

Proposed delivery model

One local service relationship, backed by Cobalt.

The local Cobalt partner would remain the customer's service relationship and field-service operator. Cobalt would provide the reusable integrations, event definitions, workflow templates, and measurement model.

Customer environment Approved systems, permissions, sites, and outcomes
Local partner Primary relationship, service workflow, and field work
Cobalt capability Reusable integrations, event model, workflows, and measurement
Existing security and service systems connect to reusable Cobalt product modules deployed by local partners in separate customer environments.
Reusable without pooling customer data Cobalt would standardize the integration patterns, event model, workflows, and measurements while each customer environment remains separate.
Systems and integrations

Confirm access before promising support.

Source systems would be selected during discovery based on secure API access, event quality, permissions, and the work required to maintain each connection.

Customer data

Keep each environment separate.

The concept does not require a pooled repository of raw security data. Access, retention, identity, and permissions must be agreed before any connection is made.

Human responsibility

People own consequential decisions.

AI may help classify faults, summarize history, and suggest next actions. People approve actions, own service work, and verify restoration.

Cobalt AI

AI helps the service team understand what happened and what to do next.

Cobalt AI would bring together the event, device, site, service history, and current workflow. It could classify the fault, surface recurring problems, summarize the record, and suggest a next action.

AI assists. People decide.

The service manager reviews the evidence and approves consequential actions. The local team owns the work and confirms restoration.

  • 01Classify faults
  • 02Summarize service history
  • 03Find recurring problems
  • 04Suggest the next action
AI helps classify and summarize a security-system issue while a service manager reviews the evidence before assigning work to a technician.
Human control stays in the loop The service manager reviews the evidence before work is assigned and remains responsible for the operational decision.

Commercial hypothesis

Charge for the operating service, not raw alert volume.

01

One-time

Pilot & onboarding

Billing basis Fixed implementation fee
  • Connect multiple source systems
  • Configure technical-health workflows
  • Establish access, governance, and permissions
  • Set the operating baseline

Designed to test feasibility, customer value, and delivery effort.

02

Recurring

Security health

Billing basis Base subscription + included managed events
  • Signal filtering and deduplication
  • Event context and prioritization
  • Workflow routing and resolution tracking
  • System-health and service reporting

Capacity moves into higher tiers as connected usage grows.

03

Premium recurring

Managed operations

Billing basis Security health + managed-service tier
  • Everything in Security Health
  • Proactive monitoring
  • Workflow and false-positive tuning
  • Operating reviews and performance reporting

For customers that want an active operating cadence.

What counts as a managed event?

An approved event that remains after filtering and deduplication, then is normalized, retained, routed, or analyzed as part of the service.

Raw device chatter and duplicate alerts would not count toward usage.

Final scope, timeline, allowances, and pricing would follow customer and system discovery.

Proposed first pilot

Prove the service before scaling it.

The pilot would test customer demand, secure access, operating improvement, delivery effort, and repeatability before Cobalt funds a broader product.

01Discover

Confirm the customer problem, source systems, workflows, access requirements, and baseline.

02Connect

Configure selected technical events from multiple systems and route them into service workflows.

03Operate

Run the workflows with the local service team and measure ownership, restoration, and delivery effort.

04Decide

Expand, revise, or stop based on customer value, feasibility, economics, and repeatability.

Proposed architecture

How the system fits together.

Selected events move through a controlled operating path. Each stage has a clear job, and each customer remains isolated from every other customer.

Working design Final components depend on customer systems, access rights, deployment constraints, and pilot findings.
01

Existing systems

  • Cameras and video
  • Access control
  • Alarms and intercoms
  • Health and service data
02

Integration edge

  • Reusable connectors
  • API adapters
  • Secure ingestion
03

Governed event foundation

NormalizeCommon event shape
DeduplicateRemove low-value noise
Event modelSite, device and history
Operational event store
Analytics warehouse
04

Action layer

  • Rules and policies
  • Workflow engine
  • Human review Control
  • Verification
05

Service and insight

Service workflowsTickets, tasks, routing, approvals
Analytics and dashboardsReadiness, SLA, recurrence, trends

On a phone, portrait shows the architecture step by step. Landscape preserves the full system map.

Cobalt supplies

The reusable product layer

  • Connector framework and canonical event definitions
  • Workflow orchestration and reusable templates
  • Customer isolation, access controls, audit, and platform operations
  • Analytics model, AI assistance, and partner enablement

Customer and local partner retain

The operating relationship

  • OEM platforms, devices, and customer system ownership
  • Local configuration, service ownership, and field work
  • Existing ITSM where it fits, or a lightweight Cobalt workspace for the pilot
  • Human decisions, customer protocols, and outcome accountability