Specification

The TrustEnvelope specification

A deterministic envelope format for sealing and verifying AI evidence records.

Publication 1.0 Draft · Freeze Candidate · June 2026 · describes TrustEnvelope wire format tsp: "3.0". The publication number versions this document; the tsp field versions the on-the-wire envelope.

Overview

Purpose. A TrustEnvelope is a portable record of an AI-assisted action whose integrity can be re-checked by anyone, offline. It binds the content of a claim to a deterministic digest and, optionally, to one or more Ed25519 signatures.

Design goals. Determinism (the same fields always produce the same bytes); offline verifiability of integrity; vendor-neutrality; and a strict, fail-closed verifier that rejects anything it cannot reproduce.

Non-goals. The envelope does not adjudicate truth, legal compliance, or issuer authority. It is evidence plumbing, not a compliance verdict.

Terminology

TrustEnvelope: The complete record: content, process metadata, ledger fields, and signatures.
content.value: The asserted claim or action, as a string.
issuer / principal: The party that sealed the record and the human or system actor it represents — carried in process and signature metadata.
policy scope: The rule context the action ran under, carried in alignment.policy.
canonical form: The single deterministic byte string produced from a value by the canonicalization rules in §04.
digest: A SHA-256 hash, encoded as a lowercase 64-character hex string.
verification: Recomputing digests and signatures from the envelope and comparing them to the stored values.

Data model

An envelope is a JSON object. The following members are required and validated structurally; unknown members are rejected.

Field	Meaning
`tsp`	Wire-format version. MUST be `"3.0"`.
`content`	`type`, `value` (string), and `hash` (digest over canonical `value`).
`declaration`	Primary source and citations backing the claim.
`process`	How it was produced: `model` (provider, name, version, temperature, context window) and `systemPrompt` (hash, optionally redacted).
`alignment`	Uncertainty notes, human-review flag, and `policy` (id, version).
`timestamp`	Claimed time and optional TSA token / URL.
`ledger`	`id`, `prevHash`, and `hash` — hash-chaining the record.
`signatures`	One or more entries: `role`, `algorithm` (`ed25519`), `keyRef`, `signature`.

Optional. executionProvenance (spatial / temporal boundary and deterministic-output attestation) is included if and only if present, and is bound into both the ledger and signature domains when it is.

Conceptual roles map onto the wire fields: what lives in content.value, who in signatures[].role / process, and under which rules in alignment.policy.

{
  "tsp": "3.0",
  "content": { "type": "text", "value": "...", "hash": "<64-hex>" },
  "declaration": { "primarySource": { ... }, "citations": [] },
  "process": { "model": { ... }, "systemPrompt": { "hash": "..." } },
  "alignment": { "uncertainty": [], "humanReviewRequired": false, "policy": { "id": "default", "version": "1.0" } },
  "timestamp": { "claimed": "2026-05-15T00:00:00.000Z", "tsaToken": "...", "tsaUrl": "..." },
  "ledger": { "id": "...", "prevHash": "<64-hex>", "hash": "<64-hex>" },
  "signatures": [ { "role": "instance", "algorithm": "ed25519", "keyRef": "...", "signature": "<base64>" } ]
}

Canonicalization

Canonicalization turns a JSON value into one deterministic string. The rules:

Object keys are sorted by Unicode code point, ascending.
Strings are wrapped in double quotes; control characters and " / \ are escaped; other characters below U+0020 use \uXXXX.
Numbers use their shortest round-trip form; -0 serializes as 0; non-finite numbers are rejected.
Arrays preserve order; true, false, and null are literal.
No insignificant whitespace is emitted.

Because keys are sorted, two envelopes that differ only in field ordering canonicalize identically and therefore produce the same digest (see conformance vector 3).

Sealing

Sealing computes the digests and signatures, in this order:

content.hash = SHA-256 of canonical(content.value), as lowercase hex.
signature = Ed25519 over canonical(signatureDomain), where the signature domain excludes the signatures array and the TSA token.
ledger.hash = SHA-256 of canonical(ledgerDomain), where the ledger domain is the envelope without ledger.hash — and therefore includes the signatures just produced.

Digest format is a bare lowercase 64-character hex string. Signatures are base64. Issuance of production receipts is a controlled operation; the verifier's seal tab demonstrates the loop with ephemeral, in-browser keys only.

Verification

Local verification is fail-closed: every required check must pass, or the envelope is not valid.

parse the envelope and validate its shape; any structural error makes it malformed.
content hash recompute SHA-256 of canonical(content.value) and compare to content.hash.
ledger hash recompute over the ledger domain and compare to ledger.hash.
signatures verify each Ed25519 signature over the signature domain against the supplied public key.
verdict valid only if schema, content hash, ledger hash, and all signatures pass; otherwise invalid.

The reference verifier is verifyLocal(envelope, { knownPublicKey }), returning { valid, checks, warnings }. The same module runs in this site's verifier and in the conformance gate.

Security properties

Integrity. Any change to a sealed field changes its digest. Determinism. Canonicalization removes serialization ambiguity, so verification is reproducible across implementations. Offline verification. Integrity and signature checks need no network. Tamper evidence. A broken seal is detectable by anyone, not only the issuer.

Limitations

A digest is not identity — it says the bytes match, not who produced them.
A digest is not legal compliance — conformance is a separate, human judgement.
Local verification does not authenticate the key reference; keyRef binding to an organisation is an online-mode property requiring a published manifest.
A valid signature is not non-repudiation on its own — that requires authenticated, non-revoked keys.
Online verification (manifest fetch, root signature, certificate chain, revocation, TSA) layers on top of local checks; it is out of scope for this offline profile.

EU AI Act mapping

This is a support mapping, not a legal claim. TSP records can serve as inputs to obligations such as:

Workflow	How a TrustEnvelope helps
Transparency	A portable record of what an AI system produced and under which policy.
Record-keeping	Tamper-evident, hash-chained receipts retained over time.
Human oversight	A `human-reviewer` signature role captures sign-off as evidence.
Auditability	Any auditor can re-verify integrity independently, offline.

Whether a given record satisfies a specific legal obligation is for the deploying organisation and its counsel to determine. AI Act dates: see the European Commission.

Conformance vectors

Illustrative cases an implementation MUST handle. The normative suite lives in the public tsp-spec conformance fixtures.

#	Input	Expected
1	Well-formed, untouched envelope	`valid`
2	A sealed field (e.g. `content.value`) altered	`invalid`
3	Same fields, different key ordering	`valid` — identical digest
4	Missing digest or unknown field	`malformed`

Versioning

Current. Publication 1.0 Draft; wire format tsp: "3.0". Compatibility. The tsp value identifies the wire contract; a verifier rejects versions it does not implement. Breaking changes increment the wire version. Migration is additive where possible — optional fields are bound into the digests only when present, so adding them does not invalidate envelopes that omit them.

Governance

Posture. Public, royalty-free verification under an open specification and public conformance fixtures. Reference implementation. The auditable verifier core, vendored into this site and exercised by CI. Change proposals. Via the public repositories under github.com/Lexi-TSP. Steward. LexiCo AS. Contact hello@truststandardprotocol.com.

Free public verification of TrustEnvelopes and TSP licenses is the standing commitment. Issuance, certification, compatibility claims, and TrustBadge use are controlled — see the repository LICENSE.md and TRADEMARK.md.

Changelog

1.0 Draft — June 2026. Freeze candidate. Public specification of the v3.0 TrustEnvelope: data model, canonicalization, sealing, local verification, security properties, limitations, and conformance vectors.