How it works
Five layers. One ticket.
Each layer has a falconry name and a plain job. The names are here because they make the architecture memorable in a demo and give an engineer a one-word handle for a service — not because they are clever. Every one of them is translated on first use, here and in the product.
01
Eyrie
the console
The high nest, with a view of the whole territory.
One screen for a fleet of any size.
Fleet, incidents, policy, the action library, connectors and the audit record. Built like a flight instrument panel rather than a SaaS dashboard: dense, dark, monospaced where it matters. The Recall button — the kill switch — sits in the top bar of every single screen. An admin who cannot find the stop button in two seconds does not trust the product.
- Device registry (Cadge)
- Incident queue and approvals
- Creance policy manager with a simulator
- Flightlog audit viewer
02
Jess
the ticketing fabric
Jesses are the leather straps that connect falcon to falconer — the tether to your world.
Kestrel lives inside the helpdesk you already run.
A ticket arrives by webhook, or by polling if your account cannot register one — and Kestrel says so plainly rather than failing silently. Jess normalises every system into one ticket schema, correlates the requester to a device, and holds the original human sentence intact all the way through. Every write back to your system carries an idempotency key, so a retry can never produce a duplicate comment or flip a status twice.
- Normalised ticket schema
- Webhook with polling fallback
- Device correlation with a published match rate
- Idempotent writeback
03
Stoop
the orchestration core
The stoop is the dive — the moment of decision and strike.
It observes, classifies, and selects. It does not improvise.
Telemetry is pulled from the device and frozen. Runbooks and prior resolutions are retrieved. The model reads all of it and selects exactly one action identifier from Quarry with typed, schema-validated parameters. It cannot write a command. It cannot invent an action. Its entire vocabulary is the signed library, and the library is published.
- Frozen observation snapshot
- Retrieval over runbooks and past resolutions
- Tool-use against Quarry identifiers only
- Model reasoning captured verbatim
04
Creance
the autonomy engine
A creance is the long training line that lets the bird fly free but never away.
Deterministic code decides. A model never authorizes itself.
This is the most important component in the system and the one your security team should read first. Creance is plain, testable, reviewable logic — no model output anywhere in the decision path. It evaluates action, risk tier, device group, health, time window, rate limit and reversibility against rules a human wrote, and returns one of four outcomes: execute unattended, execute and notify, require approval, never. The model may recommend. Only Creance authorizes.
- Rules render as English sentences, not JSON
- Deny always wins; precedence is shown, not hidden
- Simulator replays 30 days before you save
- Every change versioned, diffed and reversible
05
Talon
the endpoint agent
The talon is the part that touches the ground.
A small signed binary that refuses anything it cannot verify.
Rust, not Electron. It runs unprivileged, holds its own signed Quarry bundle, and receives an action identifier plus parameters — never an action body. If the identifier is not in its local bundle, it refuses and reports. It escalates for one named action through a platform-native broker and drops the token in the same function call. Bells, its telemetry stream, is how you always know where the bird is.
- Per-device certificate issued at enrollment (Manning)
- mTLS gRPC channel
- Sandboxed execution with rollback snapshots
- Recall works even when orchestration is down
Cross-cutting
Flightlog holds every step, and it cannot be edited.
Observation, retrieval, recommendation, policy decision, approval, execution, verification, outcome. Every step, every time, with the model reasoning stored verbatim rather than summarised. Append-only at the storage layer, not by convention.
The audit record is not a compliance afterthought. It is the answer to the only question that matters when an autonomous system touches a laptop: why did it do that. If a step is not in Flightlog, it did not happen, and it cannot ship.