> ## Documentation Index
> Fetch the complete documentation index at: https://docs.vh3.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Sentinels
> Understanding and configuring proactive monitoring
# Sentinels
Sentinels are VH3 AI's proactive monitoring layer. They run **24/7** against your operational data to detect emerging risks and growth opportunities while there is still time to act. Detection is a structured graph read, with near-zero AI cost at the watch layer.
For operators, a sentinel is the morning signal that something changed: repeat visits on one account, SLA slips in a region, a dormant customer worth calling, or an engineer-flagged follow-up that needs a quote.
## How sentinels work
Every sentinel is a **structured read on the operational model:** a query against the intelligence layer that evaluates a specific operational signal against configurable thresholds. Conversational AI is only invoked if you choose to generate a narrative explanation or briefing from the result.
The sentinel query runs against your graph, looking for the pattern it's designed to detect (e.g. repeat visits at a site exceeding threshold).
Results are scored by severity. Each sentinel has a default threshold that determines what counts as a trigger vs. noise.
Triggered results are available via the API, and can be routed to Slack, Teams, email, or WhatsApp via automation.
## Configuration
Every sentinel supports these configuration parameters:
| Parameter | Description |
| ---------------- | ------------------------------------------------------------------- |
| `threshold` | Minimum severity to trigger (higher = fewer, more critical results) |
| `lookbackDays` | How far back to analyse (default varies by sentinel) |
| `limit` | Maximum results to return |
| `excludeFilters` | Exclude specific engineers, sites, or customers from results |
## Operational sentinels
Thirteen operational sentinels monitor for emerging risks across engineers, sites, customers, and SLAs:
### Engineer performance slip
Detects engineers whose SLA punctuality or completion quality has degraded compared to their historical baseline. Catches problems early, before a pattern becomes a client complaint.
### Site deterioration
Identifies sites where fault frequency or repeat visits are trending upward. Surfaces sites that may need a planned maintenance visit to reduce continued reactive attendance.
### SLA breach cluster
Finds concentrated SLA breaches, by geography, engineer, customer, or time period. Distinguishes between isolated misses and systemic problems.
### Scheduling drift
Flags jobs where planned vs. actual timings are diverging. Useful when planning assumptions have drifted from reality.
### Data quality issues
Surfaces anomalies in job records that may indicate extraction or ingestion problems, helping keep the intelligence layer clean.
## Growth opportunity sentinels
Six growth sentinels surface revenue opportunities hiding in your operational history:
### Dormant customer
Identifies customers with no recent job activity who previously had regular engagement. Useful for re-engagement and churn-risk review.
### Overdue service interval
Flags equipment or sites that have passed their recommended service interval, creating maintenance-contract review opportunities.
### Single-service cross-sell
Finds customers using only one service line when your business offers multiple, with evidence for cross-sell conversations.
### Engineer-flagged follow-up
Surfaces jobs where engineers noted "follow up," "recommend," or "return visit", so missed quote or revisit opportunities can be reviewed.
### Seasonal buying patterns
Identifies customers whose service rhythms suggest upcoming seasonal needs, supporting proactive outreach.
### Geographic upsell clusters
Finds neighbourhoods where one scheduled visit would make multiple nearby follow-ups economical.
## API access
Sentinel results can be run on demand, read as a digest, or reviewed historically.
| Action | Endpoint | Typical use |
| --------------- | ------------------------ | --------------------------------------------------------- |
| Run a sentinel | `POST /sentinels/run` | Test a specific pattern or trigger an automation |
| Read the digest | `GET /sentinels/digest` | Morning ops review or channel summary |
| Review results | `GET /sentinels/results` | Filter historical detections by type, severity, or period |
Use the digest for daily operating rhythm. Use results when a manager wants to inspect trends or build a report section.
## Automation
Sentinel results are most powerful when routed automatically. Common patterns:
* **Daily Slack digest:** summary of all sentinel triggers posted to an ops channel each morning
* **Email alerts:** critical sentinels (SLA breach cluster, site deterioration) sent to account managers immediately
* **Weekly report inclusion:** sentinel results embedded in weekly operational reports
* **Case creation:** high-severity triggers automatically create a case for follow-up
* **WhatsApp notifications:** urgent alerts routed to field managers on the move
All of these are achievable via the VH3 AI n8n nodes (100+ pre-built templates) or direct API integration.
## From signal to ownership
A useful sentinel result should have somewhere to go. High-severity triggers can open a **case**, attach the relevant jobs or customer records, and assign ownership to the team responsible for that account, region, or function.
Example flow:
1. Repeat attendance sentinel flags a customer with three fire-panel callouts in six weeks.
2. The digest routes the result to the regional operations channel.
3. An automation opens a case, attaches the jobs, and assigns the regional team.
4. Connie drafts a short briefing with the cited job references for the coordinator.
## Related
How operators use sentinels in the daily rhythm.
Include sentinel digests in scheduled operational reporting.
Run precedent searches after a sentinel flags a pattern.
How teams own the work that sentinels surface.