Handeware Enterprise

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."

The distinction that matters

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

PropertyHowWhy 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.

PathSemantic richnessTrustworthinessState
Library call / CLIHigh — "approved wire W"Low — the agent can simply not call itv0.1
Tool-layer recorder (MCP)High — real tool calls and argumentsMedium — not the agent's choice, but in-processPlanned
Kernel observation (eBPF)Low — syscalls, not intentHighest — not bypassable without escaping to the host kernelPlanned

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.

Honest limitation, stated in the code

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

LayerWhat it isCommercialState
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

Read this table as a design, not an inventory

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.

PieceWhere it runsState
Log storageYour 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 serviceA 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
CollectorsMCP recorder beside your agent runtime; kernel collector as a DaemonSet on the nodes agents run on.Designed
IdentityRoot 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
AnalyticsSealed epochs export to your lakehouse as Iceberg. Query there; prove from the log.Designed
VerifierAnywhere, including an air-gapped laptop. That is the whole idea.Building

What adoption actually looks like

WhenWhat happensWhat 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 fourPoint 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 oneOne production domain. Warrants bound to your IdP, Object Lock on, witness signing at interval, epochs exporting to the lakehouse.Per governed agent, annual.
ThereafterWiden 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”