For data-center owners & operators

Offer services whose outputs carry evidence.

Your customer has already bought identity, access control and a hardened perimeter — and all of it stops at the edge of the service. The data walks out carrying nothing, and it is the data their next system acts on. That gap is something you can sell into.

Rootz components connect a signed request, service measurements and a result to recipient verification.

Extend the Zero Trust offer your customer already understands.

Capacity, availability and performance remain essential. Rootz adds evidence to the output itself, extending the customer’s security checks into the information its systems use.

This gives the operator a defined service to package alongside hosting: signed outputs, an agreed evidence profile and integration with the customer’s verification policy. Price the capability against an actual scope and acceptance result.

What a data center already has

You own every instrument. Your customer owns none of the readings.

Nothing on this page asks you to buy a new platform or re-architect a facility. Five things already run in a well-operated data center. Each one produces a record. None of those records reaches the customer in a form they can check — so the evidence exists, and it stays inside your building.

01

Measured process

The trusted-computing primitives already in your estate — TPM, secure boot, TEE attestation — produce a measured record of what actually ran. You use it for your own assurance. The customer never sees it.

02

Signed network logs

You already log what crossed the network. Signing those records makes them evidence rather than a file an administrator could have edited.

03

Operations and an authorized identity

Someone is accountable for this facility and this service. An authorized organizational identity is what anchors every process claim to a real party — without it, a measurement is a number with nobody behind it.

04

Model and data integrity

Which model, which weights, which data, unaltered. You protect this already. The output that leaves carries no trace of the protection.

05

Event and issue archive

Your logging and incident record is how you know the state of the estate. It is also the only thing that can say what conditions held at the moment a particular result was produced.

What Rootz adds

A snapshot of that evidence, signed and bound to the output.

At the moment a service produces a result, the Binder takes a snapshot of whichever of those five records are available, signs it under your authorized identity, and binds it to that specific output. The result leaves your building carrying the conditions it was produced under.

The customer receives something they can check themselves. Not a report you wrote about your facility — the facility’s own readings, attached to the thing they are actually using. Your engineers know these as TPM, TEE and attestation. Your customer knows the result as Measured AI.

Simple tools, simple integration. The instruments stay yours and stay where they are. The Binder reads what is already there. Nothing is rebuilt, and the evidence profile states plainly which of the five layers are covered and which are not.

See the components and responsibilities

Four capabilities to build into the offer

01

An attributable service identity

Connect the facility, rack or service to the operator’s authority model and sign the selected output path. CorpID / Digital Name patterns provide the identity foundation.

02

A production record with the answer

Bind the request and result to the available application, model, boot or facility evidence. The service profile states which layers are covered.

03

Accountability for measured changes

Compare covered measurements against the agreed reference and retain the result. A change in a measured layer becomes evidence the customer can inspect.

04

Evidence for location requirements

Bind available facility and jurisdiction evidence to the output. Establish how location is evidenced and verified; a signature alone does not prove geography.

A deployment with clear operational ownership

01

Select the workload

Choose an AI inference endpoint, data service or government application boundary. Name the producing and consuming systems.

02

Define the measured scope

Inventory the available TPM, TEE, application, model and facility evidence. Establish baselines and identify what remains asserted or unmeasured.

03

Connect key and authority management

Agree who controls signing keys, how principals are authorized, and how rotation, recovery and revocation work.

04

Install Binder and the verifier

Bind requests, outputs and process evidence. Put the required verification in the receiving workflow.

05

Operate the evidence lifecycle

Treat measurement changes, expired evidence and verifier failures as defined operational events, with recovery and customer communication.

Run AI. Supply data to AI.

Execution services

Return an AI or application result with the available evidence about the producing service and its request.

Data services

Publish source-linked data and explicit quality evidence that a consuming AI can evaluate for its task.

A scoped deployment, with measurable acceptance.

Agree the workload, evidence depth and service targets before quoting. Licensing, integration, hosting and ongoing support should have separate responsibilities in the commercial proposal.

Measure added latency, verification success, exception handling and recovery in the actual environment. Establish economics from those results.

Partner delivery model

Bring one workload and its operator.

We will identify the available measurements and the first customer-visible output to bind.

Plan the integration