⚠️ TSP public alpha preview

This repository contains TSP v3.0 preview materials. It is not a final TSP release, is not certified for production use, and does not grant any right to claim TSP compatibility, TSP certification, TrustBadge authorization, or participation in the official TSP integrity domain.

Trust Standard Protocol — Specification & Conformance Suite

Bilingual Edition: English & Norsk

Warning

Verification Is Not Truth (Verifikasjon er ikke sannhet)
TSP proves cryptographic provenance and envelope integrity (proving who signed a payload and when it was committed). It does not prevent model hallucinations or prove the semantic truth of wrapped outputs.

TSP beviser kryptografisk proveniens og envelope-integritet (beviser hvem som signerte innholdet og når det skjedde). Det forhindrer ikke hallusinasjoner eller beviser den semantiske sannheten til AI-genererte resultater.

Note

Active Candidate Status (Gate A Open)
This specification represents the TSP Spec 1.0 Candidate baseline in public alpha. It is undergoing active validation toward Gate A (pending a 90-day production run by a sovereign external adopter organization signing with its own Ed25519 key).

This repository contains the normative specifications, cryptographic schemas, threat models, and conformance test vectors for the Trust Standard Protocol (TSP).

Dette arkivet inneholder de normative spesifikasjonene, kryptografiske skjemaene, trusselmodellene og samsvarstestvektorene for Trust Standard Protocol (TSP).

---

Technical Overview / Teknisk oversikt

The Trust Standard Protocol (TSP) is an open, sovereign, and lightweight runtime evidence layer designed to bridge the verification gap for generative AI outputs. It provides mathematical proof of provenance (who generated it) and integrity (it has not been altered), satisfying the core transparency and auditing demands of the EU AI Act.

Trust Standard Protocol (TSP) er et åpent, suverent og lettvektig bevislag for kjøretid, designet for å tette verifikasjonsgapet for generative AI-resultater. Det gir et matematisk bevis på proveniens (hvem som genererte det) og integritet (at det ikke har blitt endret), noe som tilfredsstiller kjerne- og revisjonskravene i EU AI Act.

For full details, please refer to:

• THREAT-MODEL.md: The strict security boundary and cryptographic perimeter of TSP.
• tsp-v3.schema.json: The JSON Schema defining the canonical TrustEnvelope v3.0 format.
• tsp-manifest.schema.json: The JSON Schema defining the online-mode trust manifest served at /.well-known/tsp-manifest.json (Gate A; see ADR-0012).
• docs/gate-a/durable-sequence-state.md: Normative durable sequence-state (rollback-protection) semantics for online verification (Gate A; see ADR-0013).
• fixtures/v3.0/: Deterministic test vectors to validate compliance of independent implementations.

---

Execution Provenance (Lexi Trinity) / Kjøringsproveniens

TSP v3.0 introduces the Execution Provenance block to support bounded-memory execution architectures like LeanTAP and STONE. By mathematically hashing the spatial bounds ($O(1)$ tool routing) and temporal bounds ($O(1)$ memory checkpoints), the protocol provides zero-trust verification that the AI agent was constrained during execution and did not hallucinate tools or context.

TSP v3.0 introduserer Kjøringsproveniens-blokken for å støtte minnebegrensede arkitekturer som LeanTAP og STONE. Ved å matematisk hashe de romlige grensene ($O(1)$ verktøyruting) og de tidsmessige grensene ($O(1)$ minnesjekkpunkter), gir protokollen null-tillitsverifikasjon på at AI-agenten var underlagt strenge begrensninger under kjøring og ikke hallusinerte verktøy eller kontekst.

Domain rule (normative): When executionProvenance is present, it is covered by both the signature domain and the ledger-hash domain — it must exist at signing time, and attaching, mutating, or stripping it after signing fails verification with reason signature/ledgerHash (not schema). Envelopes without the field hash identically under verifiers with and without this rule. Conformance vectors: valid-with-provenance.json, tampered-provenance.json.

Domeneregel (normativ): Når executionProvenance er til stede, dekkes feltet av både signaturdomenet og ledger-hash-domenet — det må eksistere ved signeringstidspunktet, og å legge til, endre eller fjerne det etter signering gir verifikasjonsfeil med årsak signature/ledgerHash (ikke schema). Envelopes uten feltet hashes identisk under verifikatorer med og uten denne regelen.

---

Quickstart: Conformance Testing / Kom i gang: Samsvarstesting

Any independent implementation of the TSP SDK (e.g., in Python, Go, Rust, or C#) must pass the conformance suite defined in fixtures/v3.0/ to be considered TSP-compatible.

Enhver uavhengig implementasjon av TSP SDK (f.eks. i Python, Go, Rust eller C#) må bestå samsvarstesten definert i fixtures/v3.0/ for å bli sertifisert som TSP-kompatibel.

Conformance I/O Contract / I/O-kontrakt for samsvar

To run the conformance runner against your verifier binary:

1. Input: The runner pipes the raw JSON fixture via stdin to your executable.
2. Output: Your executable must print the validation outcome to stdout (VERIFIED, TAMPERED_CONTENT, INVALID_SIGNATURE, or UNKNOWN_ISSUER).
3. Exit Code: Your executable must exit with code 0 if verification finished without crashing, and 1 on execution failure.

For å kjøre samsvarsverktøyet mot din verifikator-binærfil:

1. Inndata: Samsvarstesteren sender JSON-testvektoren via stdin til din kjørbare fil.
2. Utdata: Din kjørbare fil må skrive valideringsresultatet til stdout (VERIFIED, TAMPERED_CONTENT, INVALID_SIGNATURE eller UNKNOWN_ISSUER).
3. Avslutningskode: Din kjørbare fil må avslutte med kode 0 hvis verifiseringen fullførte uten krasj, og 1 ved kjøretidsfeil.

---

Contact & Governance / Kontakt & Styring

• Owner / Eier: LexiCo AS (Nøtterøy, Norway)
• Website / Nettsted: truststandardprotocol.com
• Security / Sikkerhet: security@truststandardprotocol.com
• License / Lisens: Specification prose (this README narrative + THREAT-MODEL.md) under Creative Commons Attribution 4.0 International (CC-BY-4.0) — see LICENSE-SPEC. Schemas, conformance fixtures, the conformance runner, and scripts under the Apache License 2.0 — see LICENSE.

Normative Authority / Normativ autoritet

The spec is the normative authority; SDKs and apps implement the spec. This repository — its JSON Schema, conformance fixtures, and threat model — is the normative source. Reference implementations, SDKs, and applications conform to it; when an implementation and this spec disagree, the implementation is wrong until the spec is amended. Any change to a fixture or schema is ADR-gated and recorded with a CHANGELOG.md / version note. The full authority hierarchy is defined in ADR-0008 (Normative Authority Hierarchy).

Spesifikasjonen eier sannheten; SDK-er og applikasjoner implementerer spesifikasjonen. Endringer i fixtures eller skjema er ADR-styrte. Se ADR-0008.