Core Concepts
Big picture
1stLine by Burava helps your team receive alerts, route them, escalate them, and coordinate incident response in one workflow.
This page explains the core concepts and how they connect.
Alert flow model
In a common setup, 1stLine sits between an Alert Producer and an Alert Receiver.
An Alert Producer is the source system that sends alerts.
An Alert Receiver is the downstream destination that should receive the processed alert.
1stLine is not the Alert Receiver in this model.
Each Alert Schema provides an Alert Producer Destination value.
You put that Alert Producer Destination into the producer destination field so alerts enter 1stLine first.
When you need to pass the real downstream receiver address in the request, use the forwardTo query key.
If the producer request does not include an explicit destination override, forwarding follows the schema’s configured receiver destination.
See Alert Schemas for more information about producer-to-receiver forwarding.
Alert Events and Alert Instances
An Alert Event is one incoming alert payload at a specific moment.
An Alert Instance is the tracked record 1stLine creates or updates from Alert Events.
Multiple Alert Events can map to the same Alert Instance when they produce the same fingerprint hash.
From an Alert Instance, responders can run actions such as acknowledge, resolve, unacknowledge, Start incident, Join incident, Escalate to, Escalate Further, and Escalate to AI.
Alert Instance details also show lifecycle metrics such as MTTA and MTTR when available, plus the alert timeline, escalation trail, and links to AI assignments when the alert has been escalated to AI.
See Alert Instances for more information about Alert Events, Alert Instances, history, and actions.
Alert Schemas
An Alert Schema defines how 1stLine reads inbound alerts and prepares outbound updates.
Schemas are the foundation for routing, escalation, communication, and incident linking.
You can create an Alert Schema from a reusable Library Schema or from a real custom payload. Global Library Schemas are maintained from the public 1stLine Library Schemas repository, and organization Library Schemas are reusable templates saved inside your organization.
Schema Patterns
Schema Patterns extract structured fields from incoming payloads.
Those fields are then used in Conditions across Routing Rules, Escalation, and Communication Rules.
When the same field can appear in more than one place, a Schema Pattern can use ordered fallback attempts. 1stLine tries the primary pattern first, then each fallback entry in order, and stops at the first successful extraction.
Schema Transformations
Schema Transformations shape the outbound payload sent to the Alert Receiver.
Transformations can include generated links for responder actions.
Schema Resolution Mapping
Schema Resolution Mapping defines how resolution updates are built and forwarded.
Schema Acknowledgement Mapping
Schema Acknowledgement Mapping defines how acknowledgement updates are built and forwarded.
Schema Lifecycle Mapping
Schema Lifecycle Mapping defines how incident lifecycle changes become alert-side updates.
AI Escalation Mapping
AI Escalation Mapping defines how AI assignment updates are shaped for the Alert Receiver, including where 1stLine can inject the AI assignment details link.
AI Override Forward To can send AI assignment responses and terminal status updates to a dedicated receiver destination.
Schema Tokens and Schema Creation Tokens
Schema Tokens identify which schema should process incoming producer traffic.
Schema Tokens are not entirely secret and can’t be used for authentication, but leaking them can incur unexpected costs as the billing model is based on processed Alert Events.
Schema Creation Tokens are setup tokens used while creating schemas from incoming examples.
See Alert Schemas for more information about Library Schemas, Schema Patterns, Schema Transformations, mappings, Schema Tokens, and Schema Creation Tokens.
For practical setup walkthroughs, see Create Schema from Library Schema and Create Custom Schema.
Routing Rules and Conditions
After 1stLine creates or updates an Alert Instance, Routing Rules decide which escalation path should handle it.
Each rule contains Routing Conditions that must match alert data.
When a condition uses Is Priority, 1stLine evaluates the compared values as alert priorities such as P1, P2, and P3 instead of plain text. This is what allows operators such as greater than or less than to work as priority comparisons.
A matched Routing Rule sends the Alert Instance into the selected Chain for escalation processing.
See Routing Rules for more information about Routing Conditions and Chain matching.
Escalation model
Escalation is built from Chains, Lines, Line Members, Schedules, Escalation Flow, and Escalation Assignment.
Chains
A Chain is the escalation path definition for matching alerts.
Lines
A Line is one step in a Chain and includes a line timeout.
Line Members
A Line Member can be a User, Team, or Schedule.
Schedules
A Schedule provides time-based rotational on-call selection for escalation.
Escalation Flow
Escalation Flow is the runtime path the Alert Instance follows through the Chain.
Escalation Conditions
Escalation Conditions are checks that influence escalation behavior while an Alert Instance moves through the flow.
When an Escalation Condition uses Is Priority, greater than and less than operators are evaluated against P priority values instead of plain string order.
Escalation Assignment
An Escalation Assignment is the concrete assignment created for responders during escalation.
See Escalation for the overview, Chains for escalation paths, Lines and Line Members for responder setup, and Schedules for time-based coverage.
AI Escalation model
AI Escalation lets responders send an Alert Instance to a customer-owned assistant controller for diagnostics.
You create controller Connections, scoped rules, Conditions, enrichments, assignment timeouts, response character limits, and Allowed suggested actions.
Rule enrichments can include Context, Skill, Agent, MCP, CLI, and Note entries. MCP and CLI tools must already be installed in the controller environment.
The assistant can return an AI Response and Suggested Actions such as Resolve, Escalate further, Escalate to, Start incident, or Join incident. A responder reviews and runs the action in 1stLine.
See Escalate to AI, Create AI Escalation Rule, and Review AI Escalation Assignments.
Communication model
Communication defines how responder contact actions run during escalation.
Communication Rules
Communication Rules group communication behavior for escalation contacts. Used in Line Members configuration.
Communication Routines
Communication Routines based on the conditions define timing and action type, such as call, SMS, or both.
Communication Integrations
Communication Integrations connect 1stLine to external communication providers. Can be built-in or Bring-Your-Own (BYO). Telnyx or Twilio.
See Communication for more information about Communication Rules, Communication Routines, Communication Integrations, and Bring-Your-Own setup.
Telnyx and Twilio are third-party brands. Burava does not own, represent, or speak for them.
Incident model
An Incident is the shared response object for coordinated handling.
Incidents can start from alert handling actions, manually from UI or via API.
Incident Event
An Incident Event is a timeline record of something that happened to an Incident.
Incident Action
An Incident Action is a defined action tied to incident lifecycle changes.
Incident Alert Instance
An Incident Alert Instance is the alert instance record linked to incident lifecycle updates or the instance from which the incident was created.
See Incidents for more information about Incident Events, Incident Actions, and Incident Alert Instances.
Access model
Access is organized around Users, Teams, Roles, and API Tokens.
Users
Users are individual accounts that can receive assignments and perform actions.
Teams
Teams group users for routing and escalation use cases. By default, teams are synchronized from Burava Platform.
Roles
Roles authorize users to access specific product capabilities. Available roles include Admin, Editor, Reader.
API Tokens
API Tokens allow programmatic access to selected product capabilities.
Treat API Tokens as sensitive credentials and follow your team’s normal rotation policy.
See Access for more information about Users, Teams, Roles, and API Tokens.
API and MCP model
Use the generated API reference for endpoint-level REST details.
Use the MCP Server when an MCP client or assistant should work with Alert Schemas, Library Schemas, Transformation Template testing, Alert Instances, Incidents, Incident Postmortems, Users, or Escalation Flow.
How it all connects
The flow is simple: Alert Producer sends an Alert Event, the schema turns it into a usable Alert Instance, Routing Rules choose a Chain, and Escalation plus Communication contact responders.
When diagnostics need more context, responders can Escalate to AI and review the assistant response and Suggested Actions. When broader coordination is needed, teams Start incident or Join incident and continue from the same alert context.
Users, Teams, Roles, and API Tokens control who can configure and operate each part of that flow.
GitHub, Telnyx, and Twilio are third-party brands. Burava does not own, represent, or speak for those brands.