What it watches
Sentinel runs as a fleet of small, single-purpose agents. Each agent owns one source.
Each agent compares the latest payload to the last one we stored. If the hash differs, it produces a structured monitoring event rather than a raw blob — already classified by severity, with the changed fields called out.
Event lifecycle
1
Detect
The agent runs, fetches data, and compares against the stored baseline.
2
Emit
A
MonitoringEvent is written with severity, title, description, and changedFields.3
Alert
An alert is fanned out to the customers who have this vendor under monitoring, respecting their notification preferences.
4
Resolve
The customer reads or acks the alert. If a sentinel finding warrants action, it may trigger a deeper Investigation Report.
Severities
High-severity events can revoke a Trust Badge automatically; medium and low events are surfaced but never auto-revoke.
Subscribing a vendor
You opt a company into monitoring from the dashboard or the API by adding it to your watchlist. Provide avendorId, an rcNumber, or both — at least one is required:
GET /v1/monitoring/vendors and an event stream becomes available at GET /v1/monitoring/vendors/:vendorId/events. Each vendor in the list carries vendorName, riskTier (LOW, MEDIUM, HIGH, or CRITICAL), and hasAlerts. Remove a vendor with DELETE /v1/monitoring/vendors/watchlist/:vendorId.
Tuning the noise
Smart Sentinel is opinionated — it prefers signal over recall. Every agent has:- A payload digest so unchanged data doesn’t fire alerts.
- A circuit breaker that opens after repeated upstream failures (so an outage at FIRS doesn’t drown the user in fake “TIN unavailable” events).
- A rate limiter with jitter so we don’t hammer source systems.
Where to go next
Verification lifecycle
Where Sentinel sits in the overall flow.
Webhooks
Receive monitoring events at your own endpoint.
