Receipt Practice Statement

1. Scope and status#

This statement describes how Agined Attestor, operated by Avonao, Inc., issues receipts: the signed records returned by every tool call, scheduled check and watch. It applies to production receipts and to receipts issued with the free test key. It is version 1.6 of the statement and describes receipt format version "1".

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

In plain language: a receipt is a small JSON document that Agined signs. It says which tool ran, when, and what the tool did or was told. Anyone can check the signature with our public key, without asking us.

2. What a receipt contains#

Every receipt is a JSON object with these members:

A receipt names no workspace, account or person in its envelope. It holds whatever the tool's body records: hashes of content, and readable metadata such as destination URLs, labels, DNS answers, certificate hashes or, for commit.attest, the commit author's name and email. The canonical form of a receipt is at most 4,096 bytes; a call that would produce a larger one is refused with 413 receipt_too_large.

3. Which tools 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 Agined did or saw itself: a request it made, a page or record it fetched, mail or a webhook that arrived at it.
• A checked or computed fact is something Agined worked out itself from what it was given or from its own records: that a signature verifies against a key, that a deadline passed before a step was recorded, which calls in its own relay records matched a rule.
• A reported fact is something the customer, or a party the customer named, told us. The receipt proves that they said it, at that time, not that it is true.

Many receipts hold more than one kind. The tables below say which part is which. Receipt bodies of the tools that carry an assertion member say it in the receipt itself: "agined" or "agined-observed" when Agined observed, checked or computed the fact, "customer" when the body records what the customer, or a party the customer named, sent us. A customer record can contain a separate block, such as aginedChecked or observed, with the facts Agined checked itself. Each tool's documentation page states what its receipts prove and do not prove.

AI and agents#

Content and provenance#

Web and API evidence#

Delivery and messaging#

Domains and infrastructure#

Software supply chain#

Compliance and consent#

Payments and fairness#

Some tools issue more than one receipt type, for example an enrolment, a deadline verdict or a digest; each tool's documentation page names them. Every type uses the same envelope, keys and signing.

Each regional service also signs a daily self-attestation of its own activity, of type platform.self-attestation.

Bodies of relayed requests and responses are hashed, not stored, unless the customer turns on response-body retention. The same holds for the content the other tools receive to hash: documents, prompts, frames, mail, files and page HTML are hashed and not stored, except where a tool's documentation says that it returns or keeps something. A hash proves that matching bytes existed at the time; it does not show what they were.

4. How a receipt is made#

1. Authenticate. The front door resolves the API key, token or OAuth grant to one workspace before any tool runs. Secrets are stored and compared as SHA-256 hashes.
2. Forward. The workspace and its permissions travel to the workspace's regional service in a header signed by our own services. Without a valid signature, the regional service refuses the request.
3. Do the work. When a tool observes, the regional service makes the request through an outbound filter that refuses private and internal addresses. The relay and webhook tools never follow redirects; the tools that capture public pages and records follow a bounded number of redirects and pass every hop through the same filter again. When a tool checks something the customer submits, such as a signature, a DKIM header or an attestation report, it runs the check itself and records the result. When a tool records reported facts, it records what the customer submitted.
4. Canonicalize. The receipt without its signature member is serialized in the RFC 8785 canonical JSON form (JCS): keys sorted, no whitespace, UTF-8.
5. Sign. Those bytes are signed with pure Ed25519 (RFC 8032) by the key of the workspace's region. The service checks the signature against the public key before it returns the receipt.
6. Store and return. The receipt is stored in the workspace's region and returned to the caller.

If a region has no signing key, the call fails with 503 signing_unprovisioned. If the key cannot be used, it fails with 503 signer_unavailable. The service never signs with another region's key, never signs with a local key in production, and never returns an unsigned receipt.

5. Time#

issuedAt is read from the clock of the Cloudflare Worker that signs the receipt, at the moment of signing. The time in receiptId comes from a separate reading of the same clock and can differ from issuedAt by a few milliseconds.

No third-party timestamp authority (RFC 3161) countersigns receipts, and we make no statement about the accuracy of the clock beyond that it is the server's own time. If the exact time matters to you, rely on issuedAt as Agined's statement of when it signed, and combine it with other evidence where the stakes justify it.

6. Keys#

Seven Ed25519 keys sign receipts, one for each data region, shared by all workspaces in that region. They are held as encrypted Cloudflare Worker secrets, and only the receipt service uses them. No API route returns a private key. Production and test receipts are signed by the same keys; test receipts are told apart by "environment": "test".

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

7. Storage, retention and redaction#

Receipts are stored in the data region chosen for the workspace. The database is append-only for receipts: triggers refuse changes, and a deletion passes only through an audited route, which is the customer's own deletion, a redaction or the retention job.

Receipts are customer data. Receipts, and everything recorded about them, are stored on Cloudflare in that region for a workspace on the Free, Starter, Pro, Pro+ or Team plan; on Free and Starter in the region's shared Cloudflare D1 database, and on Pro, Pro+ and Team in the workspace's own separate store on Cloudflare, one per workspace, with strict tenant isolation. For a workspace on the Scale or Enterprise plan, or with the isolation add-on, they are stored in the workspace's own Amazon Aurora database on Amazon Web Services, in the AWS region the workspace chose. When a workspace moves to Scale or Enterprise or buys the isolation add-on, its existing receipts are moved into that database. When it moves back to a plan on Cloudflare D1, its receipts are copied back into the D1 database of its region and checked, and the Aurora database is retired after the grace period. No receipt, receipt hash or batch of receipts is stored anywhere else. Each receipt is signed, so a change to a stored receipt breaks its signature, and the chains described below show a record removed from the middle of a chain.

On the Scale and Enterprise plans and with the isolation add-on, the hash of each receipt is also filed in a write-once ledger copy in the same database as the receipt, the workspace's own Amazon Aurora database. Once an hour, receipts from the hour that has closed are filed in batches of at most 2,000; each batch is one row holding the hash-only entries and a Merkle root over them, signed with the Ed25519 key of the workspace's region that signs its receipts. The entry for a receipt holds its id, its type, the SHA-256 of the signed receipt, its signature and key id, its issue time, its region and the date until which it is kept; it holds no account, label, URL or body. Database triggers refuse any change to a batch, and refuse its deletion before that date, which is seven years after the end of the batch's hour. A receipt deleted earlier, by the customer, by the retention window or on an erasure request, therefore keeps its hash-only entry until that date. The copy is in a database Agined operates and is not an independent witness: database triggers do not bind the database's owner, who could remove a trigger. Receipts stored in Cloudflare D1, on the Free to Team plans, have no write-once copy.

Some tools keep a chain: consent records, terms acceptances, identity-check decisions, erasure and reporting cases, exam submissions, approvals and MCP sessions. Each record in a chain names the previous receipt and the hash of its body, so a record cannot be removed from the middle of a chain without breaking the links. People in these chains are identified by a salted hash (an HMAC with a salt kept per workspace), not by a name or an address. The salt is kept with the workspace data and is returned only to that workspace, so the customer can link a hash back to its own user; a party holding only the receipt cannot.

Receipts are kept for the plan's retention window and then deleted: Free 7 days, Starter 30, Pro 90, Pro+ 180, Team 365, Scale 730; Enterprise has no automatic deletion unless the contract sets one. A customer can shorten the window. Deleting an account does not delete receipts before their window ends. An SBOM that a customer asks sbom.notarize to keep (escrow) is stored in the workspace's data region for ten years, in storage locked so that no one, including Agined, can delete it earlier, also when its receipts, the workspace or the account are deleted. A copy of a receipt held outside Agined still verifies after we have deleted ours.

A customer can redact fields of a stored receipt. The redacted copy records which fields were removed and when, and no longer verifies, because the signed bytes have changed. A copy taken before the redaction still verifies. The Privacy Policy and Retention and erasure give the detail.

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

A valid signature proves:

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

It does not prove:

• that a reported fact is true;
• who authored or approved the content. The receipt records what a workspace sent, not which person;
• the real time of an event, beyond Agined's own clock;
• that nothing happened where there is no receipt; or
• that Agined is neutral beyond its word. A receipt is in no public log.

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#

• issuedAt is always the time of signing. We do not issue receipts 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 production receipt published, unless it is compromised, as Key management section 7 describes.
• We never return an unsigned receipt, and never sign with another region's key.
• We do not change a receipt after signing it, and we do not reissue a receipt with different content under the same receiptId.
• 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@agined.com. Security concerns about a receipt or a key: security@agined.com.