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.
Product vision hypothesis
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.
The operating gap
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.
Receive an approved technical event.
Add site, device, history, and service context.
Filter noise and surface the work that matters.
Route the issue to a named owner.
Track field service through remediation.
Confirm restoration and update readiness.
What the customer gets
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.
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.
Proposed delivery model
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.
Source systems would be selected during discovery based on secure API access, event quality, permissions, and the work required to maintain each connection.
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.
AI may help classify faults, summarize history, and suggest next actions. People approve actions, own service work, and verify restoration.
Cobalt AI
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.
The service manager reviews the evidence and approves consequential actions. The local team owns the work and confirms restoration.
Commercial hypothesis
One-time
Designed to test feasibility, customer value, and delivery effort.
Recurring
Capacity moves into higher tiers as connected usage grows.
Premium recurring
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
The pilot would test customer demand, secure access, operating improvement, delivery effort, and repeatability before Cobalt funds a broader product.
Confirm the customer problem, source systems, workflows, access requirements, and baseline.
Configure selected technical events from multiple systems and route them into service workflows.
Run the workflows with the local service team and measure ownership, restoration, and delivery effort.
Expand, revise, or stop based on customer value, feasibility, economics, and repeatability.
Proposed architecture
Selected events move through a controlled operating path. Each stage has a clear job, and each customer remains isolated from every other customer.
On a phone, portrait shows the architecture step by step. Landscape preserves the full system map.
Cobalt supplies
Customer and local partner retain