Enterprise / Products / Roobee
Roobee · the evidence substrate
What the agent did, under whose authority, provable in ten years.
Your agents are already acting. Eventually somebody — an auditor, a regulator, an insurer, opposing counsel — will ask what one of them did, who authorised it, and how you know. Roobee is the answer to that question: an append-only, tamper-evident log of machine behaviour that can be verified offline, years later, by software that is not ours.
- Shape
- Ledger, not database
- Structure
- RFC 6962 Merkle log
- Dependencies
- CPython only
- Status
- In development
The gap it fills
A generation of tooling now watches what agents do. Kernel-level harnesses observe syscalls, policy engines block disallowed actions, frameworks emit traces. That layer is real, it is well funded, and it is not what we are building.
Every one of those is a sensor. None of them is a system of record. They produce a stream, and a stream you cannot verify without the vendor still existing is telemetry, not evidence. The question an auditor asks in 2031 is not "what does your dashboard say" — it is "prove this record has not been altered since it was written."
Observability answers what happened, for you, now. Evidence answers what happened, for a sceptic, later — and has to survive the disappearance of everyone involved, including us.
What it is, precisely
| Property | How | Why it is there |
|---|---|---|
| Content-addressed | Every record is keyed by the hash of its canonical form — sorted keys, no whitespace, floats refused because their formatting is not portable enough to hash. | A third party can verify a fragment without trusting our server, and any change to any field changes the identity. |
| Tamper-evident | RFC 6962 Merkle log — the Certificate Transparency design, chosen because it is proven and interoperable rather than invented here. | Inclusion proofs show a record is in the log. Consistency proofs show nobody rewrote history between two checkpoints. |
| Causally ordered | Records reference their parents by hash, so lineage is a DAG rather than a timeline. | Distributed agents have no trustworthy shared clock. "This descended from that" is structural; "this happened at 02:14" is a claim. |
| Authority-bound | Warrant chains, delegation attenuating only — a child warrant's scope must be a subset of its parent's, terminating at a human principal. | An agent is not accountable. Only the chain back to a person is. Authority can narrow as it delegates; it can never widen. |
| Offline verifiable | Stdlib-only verifier, no network, no service, no licence check. | Evidence that only one vendor can check is not evidence. It is a hostage. |
What it is not
- Not a blockchain. No consensus, no peers, no token, no mining. A blockchain solves agreement between mutually distrusting parties, which is expensive and almost never the enterprise requirement. Roobee solves tamper-evidence for a single writer who may later be questioned. It is the same mathematics that already secures every HTTPS connection you make — Certificate Transparency, not cryptocurrency.
- Not a database. No updates, no deletes, no transactions, no query language. It sits beside your Postgres, not in place of it. Postgres holds the balance; Roobee holds the record that agent X moved it, under warrant Y, delegated from human Z.
- Not a sensor. It does not watch your agents. It is what the watchers write into.
- Not a replacement for your warehouse. See below.
How it lives beside Snowflake and Databricks
Roobee is small, append-only and optimised for proving one record authentic. It is deliberately bad at analytics. So sealed epochs stream into your lakehouse as a derived table — Iceberg, with the content hash as a column — and you get SQL over billions of agent actions: attribution, anomaly detection, cost, coverage.
The warehouse copy is not the evidence, and being clear about
that is the point. It is a mutable table in a system where a
privileged user can run an UPDATE. When a record is
challenged you do not hand anyone a warehouse query — you produce
the inclusion proof from the log. Ask questions in the lakehouse; answer
challenges from the ledger.
What happens as it grows
- Epochs, chained. A log seals at a set size, publishes a signed checkpoint, and the next epoch's genesis references the previous root. Sealed epochs move to cold storage; the checkpoint chain stays small enough to keep forever and is all you need to verify the whole history.
- Delete content, keep proof. Because the structure is a Merkle tree, record bodies can be discarded past a retention window while their leaf hashes remain — inclusion proofs still verify. You can prove a record existed, and that it was deleted, without retaining what it said.
- Which is also the erasure answer. Most immutable-log proposals die on the collision with data-deletion law. This one does not: the payload goes, the integrity stays.
How the data gets in
There is a genuine tradeoff here and we would rather state it than paper over it: the sources you can trust most see the least meaning, and the sources richest in meaning are the easiest to lie to.
| Path | Semantic richness | Trustworthiness | State |
|---|---|---|---|
| Library call / CLI | High — "approved wire W" | Low — the agent can simply not call it | v0.1 |
| Tool-layer recorder (MCP) | High — real tool calls and arguments | Medium — not the agent's choice, but in-process | Planned |
| Kernel observation (eBPF) | Low — syscalls, not intent | Highest — not bypassable without escaping to the host kernel | Planned |
The interesting output is not either channel alone — it is where they disagree. An action claimed but never observed means an agent reporting work it did not do. An action observed but never claimed means an agent doing work it did not declare. Activity under no warrant at all means unauthorised action. A sensor with nothing to check itself against can only report; it can never contradict.
Why the format is open
Your requirement is that this outlives us. That requirement is unsatisfiable if we are the only ones who can read the artifact — so the record format, the Merkle construction and the verifier are open and will stay that way. Run the verifier on a bare interpreter in ten years, with no licence, no service and no vendor.
What we sell is the operational layer above it: retention and epoch management at scale, lineage query, the regulator-facing exports, the collectors, and the integration with Engine and Garrison so that runtime execution and agent governance write into the same log as everything else.
The reference signer is HMAC, because the Python standard library has no asymmetric cryptography and we will not add a dependency to the thing whose whole value is running without one. That gives integrity and authentication against outsiders — not non-repudiation against the log operator. The verifier reports unsigned logs as unverified rather than ok, and an Ed25519 slot is documented and deliberately unimplemented for callers who accept a dependency.
How you buy it
| Layer | What it is | Commercial | State |
|---|---|---|---|
| Format, verifier, reference log | The record shape, the Merkle construction, and the offline verifier. | Open and free, permanently. Your requirement is that this outlives us; that is unsatisfiable if we are the only ones who can read it. | Building |
| Collectors | The MCP recorder and the kernel collector — getting real behaviour into the log without asking agents to volunteer it. | Per governed agent, annually. | Designed |
| Operations | Epoch sealing and lifecycle, cold-storage tiering, lineage query at scale, lakehouse export, regulator-facing bundles. | Per governed agent, annually. | Designed |
| Witness | Independent counter-signature of your checkpoints at interval. | Subscription. See below — this is the one that closes the trust gap. | Designed |
Priced per governed agent rather than per record, deliberately. Charging by volume would penalise exactly the behaviour the product exists to encourage: recording everything, including the boring actions that turn out to matter.
Transacted through AWS Marketplace like the rest of the line, so it lands on the AWS bill you already have and draws down committed spend. Container listing for the deployable parts; private offer for multi-year terms.
The witness, and why it matters
A tamper-evident log proves nobody edited it without you noticing. It does not, on its own, prove that you did not rewrite it, because you hold the log. That is a real limitation and the honest answer to it is not cryptography — it is a second party.
A witness periodically counter-signs your checkpoint roots. Afterwards, rewriting history requires forging an attestation held by someone else, which is precisely the property a regulator is looking for. Certificate Transparency works this way and it is why CT is credible: independent monitors, not a trusted operator. Handeware can act as witness; so can your auditor, your regulator, or a notary you already retain. The protocol does not care, which is the point.
How you mount it
Roobee is in development and none of the deployment pieces below have shipped. We are describing the intended shape so you can tell us early if it is wrong for your environment — not implying you can install it today. When a row ships, this table will say so, and there will be an artifact on this site you can run. That is the standard we hold the rest of the product line to and we are not exempting this one.
Entirely inside your boundary. There is no Roobee cloud, no tenancy, and nothing of yours on our side — the same posture as the rest of the product line.
| Piece | Where it runs | State |
|---|---|---|
| Log storage | Your S3 bucket, with Object Lock in compliance mode. Write-once storage even the account root cannot delete, under a lifecycle policy you set. Merkle gives tamper-evidence; Object Lock gives tamper-resistance. Use both. | Designed |
| Append service | A container in your VPC — ECS task or Kubernetes deployment — with an IAM role scoped to that one bucket prefix. Stateless; the log is the state. | Designed |
| Collectors | MCP recorder beside your agent runtime; kernel collector as a DaemonSet on the nodes agents run on. | Designed |
| Identity | Root warrants bind to real people in your existing IdP — the OIDC or SAML subject becomes the human principal a delegation chain must terminate at. No separate user directory. | Designed |
| Analytics | Sealed epochs export to your lakehouse as Iceberg. Query there; prove from the log. | Designed |
| Verifier | Anywhere, including an air-gapped laptop. That is the whole idea. | Building |
What adoption actually looks like
| When | What happens | What it costs you |
|---|---|---|
| Day one (not yet available) | Install the verifier, run it against a published sample bundle, read the format spec. Decide whether the artifact would satisfy your own auditors. | Nothing. No account, no procurement, no conversation. |
| Weeks one to four | Point a collector at one agent in one non-production environment. Watch what it records. Break the log on purpose and confirm the verifier catches it. | A pilot, fixed price. |
| Quarter one | One production domain. Warrants bound to your IdP, Object Lock on, witness signing at interval, epochs exporting to the lakehouse. | Per governed agent, annual. |
| Thereafter | Widen by domain. Each domain arrives with its own evidence from day one rather than being retrofitted. | Scales with agents, not with volume. |
Note what step two is for: you should try to break it before you trust it. Corrupt a record and confirm the verifier refuses. A guard that passes both ways is worse than no guard, and that applies to ours as much as anyone's.
Where it sits in the line
Roobee is the substrate the rest of the product line already implied. Prove emits evidence bundles. Engine event-sources every run. Garrison will evidence every agent action. Roobee is that shared model made explicit, standalone, and adoptable on its own — including by people who use none of the rest.
Early access
Roobee is in development. If you are being asked to evidence agent behaviour to an auditor or a regulator and want to shape what this becomes, that is exactly the conversation worth having now.
support@handeware.com · subject: “Roobee early access”