Record Practice Statement

Read it with the Verifier Terms, which say what anyone may rely on, Key management, Verifying records and Format versions and long-term verification. The technical reference is in the documentation: Ledger bundles, Verifying and Signing keys.

In plain language: Intramedial writes down what the agents in your workspace were admitted to do and what happened. Each entry is chained to the one before it. When you need to show someone else, you seal a range of entries into a bundle that we sign. The signature can be checked with our public key, offline, without asking us.

2. What the records contain#

Intramedial keeps three layers of records. Each layer is described here once, so that later sections can say which layer a statement applies to.

A ledger bundle is a JSON document. Its main members are:

A bundle names the workspace by its identifier. It holds the content of the sealed chain entries: agent identifiers, resource names, decisions and reasons. It may therefore contain personal data, such as the name or email address of an administrator who approved an action. Treat a bundle as you treat the workspace's audit log.

3. Which records observe and which record reported facts#

The difference matters more than anything else on this page. There are three kinds of fact:

• An observed fact is something Intramedial did or saw itself: a request that reached an enforcement point, a decision it made, a lease it granted or released, a caller it could not resolve.
• A checked or computed fact is something Intramedial worked out itself from what it was given or from its own records: that a mandate allows an action, that a lease is still in force, that a signature verifies, that a Merkle root covers a set of entries.
• A reported fact is something a customer, an agent or a party the customer named told us. The record proves that they said it, at that time, not that it is true.

Many records hold more than one kind. The table says which part is which, by module group. The documentation page of each module states what its records prove and do not prove.

Intralock admits or refuses an action on the facts the request carries and the rules in force. It cannot know that a fact an agent declared about itself is true. An admission record shows what was declared and what was decided; it does not show that the declaration was correct.

Customer content that an agent processes is not stored in the chain unless a module's documentation says that it keeps something. The chain stores identifiers, names, decisions and hashes of content, not the content itself. A hash proves that matching bytes existed at the time; it does not show what they were.

4. How a record is made#

1. Authenticate. The front door resolves the API key, token or OAuth grant to one workspace and one actor before any module runs. Secrets are stored and compared as hashes.
2. Forward. The workspace and its permissions travel to the regional service in a request signed by our own services, with a nonce against replay. Without a valid signature, the regional service refuses the request.
3. Decide. Intralock evaluates the request against the lease, mandate and policy in force and returns a decision and a reason. The decision is a function of its inputs; it does not call a model and it does not depend on a network call.
4. Append. The decision and the facts around it are written to the workspace's audit chain. The entry is put in RFC 8785 canonical JSON, hashed with SHA-256, and linked to the hash of the previous entry. Events of the coordination layer are also appended to the witnessed ledger under a Merkle root, which is broadcast to the witness queue.
5. Seal on request. When a user or an agent with the right scope asks for a ledger bundle, the selected range of the chain is read, its Merkle root is computed, and the canonical bundle is signed with Ed25519 (RFC 8032) by the key of the workspace's signing jurisdiction. If no key is provisioned for that jurisdiction, the request fails with 503 and nothing is signed.
6. Store and return. The bundle is stored in the workspace's region, in the ledger-bundle bucket of that region, and returned to the caller.

The service never signs with a key it was not given for that jurisdiction and never returns an unsigned bundle.

5. Time#

Time in a chain entry or an event is read from the clock of the Cloudflare Worker that wrote it, at the moment of writing. rangeEnd and the creation time of a bundle come from the same kind of clock. We make no statement about the accuracy of that clock beyond that it is the server's own time. If the exact time matters to you, rely on it as Intramedial's statement of when it recorded the event, and combine it with other evidence where the stakes justify it.

A bundle can also carry an otsProof. When an OpenTimestamps anchor is enabled for a deployment, the roots of pending bundles are batched into one super-root and anchored to a Bitcoin block. The otsProof member stays null until the anchor is confirmed. A null value means no anchor exists yet; it is never to be read as a confirmed timestamp. A confirmed anchor shows that a digest existed by the time of that block. It does not show what the digest stands for.

6. Keys#

Bundles are signed with Ed25519 keys, one for each signing jurisdiction. All workspaces in a jurisdiction share its key. The private keys are held as encrypted secrets of the signing service, which uses them to sign and does not expose them through any interface. They are not held in a hardware security module or in AWS Key Management Service. The public half of each key is published at /.well-known/ledger-bundles-keys.json as a JWK set, with its key identifier, so that a verifier can fetch it without credentials.

Secrets that customers store with Intramedial, such as connector credentials, are protected differently: each is sealed with its own key under AES-256-GCM, bound to the workspace and the secret name, and the data keys of the control-plane vault are wrapped by AWS Key Management Service.

Key identifiers, the published key set, rotation and what happens if a key is compromised are described on the Key management page.

7. Storage, retention and exit#

Records are stored in the data region chosen for the workspace: Cloudflare D1 databases and Durable Objects for workspace data, and R2 buckets for bundles. For the Europe region these are created under the Cloudflare EU jurisdiction. Regions, and what Cloudflare cannot pin to a location, are described on the regions page and in Data regions.

The audit chain is append-only. Entries are not edited. A deletion passes only through an audited route: the customer's own deletion of the account or workspace, or a retention setting.

Receipts are customer data. On Scale and Enterprise, and with the isolation add-on, they are kept in the workspace's own AWS database (Amazon Aurora, in its AWS region); on Free, Starter, Pro, Pro+ and Team they are kept in the region's Cloudflare D1 customer database. When a workspace moves to Scale or above, or adds the isolation add-on, its receipts move into the new AWS database. When it moves back, they are copied into the region's D1 and checked, and the AWS database is retired after the grace period.

Records are kept for the retention window that belongs to the plan, as shown on the pricing page and in Retention and erasure. A customer can shorten the window and cannot extend it; the Enterprise plan has no automatic deletion unless the contract sets one. When an account or workspace is deleted, there is a 30-day grace period, after which erasable data is purged. Append-only entries that must remain are kept only for a recorded reason. A bundle or export that a customer holds still verifies after we have deleted our copy.

Exports carry a manifest with one digest per item and a Merkle root over all of them, so that you can check that an export is complete and unaltered. The recovery objectives for each store are published in the exit objectives; an objective that has not been measured is reported as unverified, not as met.

Support and privacy records are kept for 3 years after the matter is closed. The Privacy Policy gives the detail.

8. What a record proves, and what it does not#

A valid bundle signature proves:

• origin: the holder of an Intramedial signing key signed exactly these bytes;
• integrity: nothing in the bundle has changed since, down to one digit; and
• a signed time: Intramedial's clock read the creation time when it signed.

A valid chain proves that the entries are in the order recorded and that none was removed from the middle or altered.

None of it proves:

• that a reported fact is true;
• who authored or approved content beyond what the record names. An entry records the actor the plane resolved, not the person behind an agent's credential;
• the real time of an event, beyond Intramedial's own clock and any confirmed anchor;
• that nothing happened where there is no record. Activity that does not pass through an enforcement point you connected is not seen; or
• that Intramedial is neutral beyond its word. A bundle is not in a public log. An anchor, where one is confirmed, fixes the time of a digest; it does not vouch for what a record says, and it does not show that every entry was sealed.

9. What you still trust us for#

Verification needs no cooperation from us, but it does not remove all trust. You still trust:

10. Our commitments#

• A time in a record is the time of recording. We do not write entries with an earlier or later time.
• We sign only with keys whose public halves are in the published key set, and we keep every key that has signed a bundle published, unless it is compromised, as Key management describes.
• We never return an unsigned bundle, and never sign with another jurisdiction's key.
• We do not change an audit-chain entry after it is written, and we do not reissue a bundle with different content under the same bundleId.
• We announce material changes to this statement in the changelog before they take effect, and keep earlier versions available on request.

11. Changes to this statement#

Questions: support@intramedial.com. Security concerns about a record or a key: security@intramedial.com.

EU notices

• Digital Services Act
• EU Data Act
• EU AI Act
• Right of withdrawal

Receipt practices

• Record Practice Statement
• Verifier Terms
• Key management
• Verifying ledger bundles
• Format versions and long-term verification
• Cryptographic agility and post-quantum status
• If Intramedial stops operating

Program terms

• Startup Program Terms
• Nonprofit Program Terms
• Education Program Terms
• Public Sector Program Terms