Product
Sentinel
Endpoint monitoring over your own rules: snapshots are screened, and each match is an alert for a person to acknowledge and close.
On this page
What it does
Sentinel watches the endpoints an account tells it about. The account states threshold and pattern rules, sends a snapshot of an endpoint's state (disk use, failed sign-ins, patch age, listening ports, whatever it chooses to report) for screening, and every rule the snapshot breaks becomes an alert in the account's Endpoint Alerts register, where a person acknowledges and closes it.
What exists now
| Capability | What it does | Where |
|---|---|---|
| Rules | Numeric thresholds, counts, listed values, hours windows and patterns over named fields of the snapshot. A rule is retired, never edited, so an alert can always be read against the rule that raised it. | Endpoint screening |
| Screening a snapshot | The database evaluates every active rule against the snapshot deterministically and keeps the snapshot and the exact rules used. | POST /account/screening/endpoint/screen |
| Alert lifecycle | Alerts move raised, acknowledged, closed, and only in that order. A closed alert cannot change. | Endpoint Alerts |
Operating needs
- PostgreSQL. Snapshots reach the platform through the signed-in page or the JSON route; Sentinel does not install an agent on an endpoint.
Limits
- It does not collect telemetry: your own tooling reports what it wants screened, and a field that is absent from a snapshot never matches a rule.
- It detects only what your rules state. It has no signature set, no behavioural model and no threat intelligence feed.
- It does not notify anyone: alerts wait in the register until a person looks.
- It is not a security monitoring service and makes no claim to detect an attack.
Availability
Sentinel is running on RJV's own platform. RJV does not sell a licence for it as a separate product today: the commercial terms state what is on sale. It can be part of the result of an engineering engagement, where the written proposal names it, its licence terms and what you would hold at the end. To discuss it, use Work with Us.
Evidence
Rule evaluation, the alert lifecycle and account isolation are exercised by the platform's own tests. The evidence register lists the graded claims.
Works with
- Audit Chain: Requires. Each rule, run and status change is entered in the account's audit chain.
- Endpoint Alerts: Requires. Alerts raised by Sentinel are records in this register.
- Identity and Access: Requires. An account signs in and holds the grants that let it state rules and screen snapshots.
- Energy and Utilities: Works with. Used in this industry.
- Manufacturing and Industrial: Works with. Used in this industry.
- Observability and SRE: Works with. Observability and SRE builds the reporting that feeds snapshots.
- Security and Assurance: Works with. Security and Assurance can set rules and review the alerts they raise.
- Transaction Alert Review: Works with. Both use the same rule screening engine over different subjects.
Where it runs
| Supported target | A customer-controlled Linux host on x86-64 with PostgreSQL 18 (linux-x86_64-customer-controlled). |
|---|---|
| Not yet supported | Windows, macOS, phones and tablets, and Linux on other architectures. Each needs its own installation, update and recovery evidence before it is supported. |
| Check a device | Run rjv2 preflight on it. It reads the operating system, architecture, memory, disk, listen address, configuration, database, database role and schema, changes nothing, and exits non-zero if release 2.0.0-alpha.1 cannot run there. |
| Installed as | One application and a PostgreSQL database. Installing release 2.0.0-alpha.1 (schema 100) installs every system on this site, including Sentinel. |
| Data | It stays in the PostgreSQL database you run. The only outside service the release can use is an outbound mail relay that you configure. |
| Updating | A release is a numbered build. The schema is applied by a separate owner step (rjv2 migrate), and the application refuses to serve a schema it was not built for. |
| Backup and restore | rjv2 backup writes a checksummed dump. rjv2 restore restores it into an empty database and checks the checksum, the schema version and the audit chain of every account. |
| Leaving | The data is in your own database and can be dumped at any time. What you may do with the release is set by the terms on deployment and ownership. |
- Published
- 29 October 2026
- Revision
- 1