TIP — The Trust Intelligence Protocol

§0 · Design principles

Four rules everything else follows.

P1 · Measurement, not advice

A Trust Object states what was assessed, with what confidence, on what evidence. It never contains a recommendation — consumers act against their own thresholds, and the record proves both sides.

P2 · Verification never routes through the issuer

Integrity proof is independent infrastructure. If verifying a record requires asking the issuer, the protocol has failed — self-attestation is structurally impossible.

P3 · Only fingerprints leave

Evidence, claims and customer data never touch the anchoring layer. Only cryptographic fingerprints are batched and anchored.

P4 · History is append-only

Records are living: new versions supersede, nothing is silently rewritten. The version chain is part of the record.

§1 · TIP-1 · RECORD

The Trust Object schema.

One governed, machine-readable record per evaluation. Censio Certs are its branded rendering; the API returns its machine form; the public verify page is its public face.

Field	Type	Definition
id	string	Stable object identifier (e.g. CX-924837). Never reused.
claim	string	The assessed proposition, stated neutrally.
confidence	number 0–1	Calibrated confidence — one headline score; the full trust profile sits beneath it.
evidence	object	Source count, support / conflict split, provenance references. The complete evidence set stays with the issuer; the record carries its summary and hashes.
methodology	string	Versioned, published methodology identifier (e.g. compliance-model/3.1). Archived so any version can be inspected later.
model_panel	string[]	The model set consulted for the evaluation.
issued_at	RFC 3339	Issuance timestamp (UTC).
version	integer	Monotonic version number within the object's chain.
supersedes	string?	Reference to the prior version, forming the unbroken chain.
issuer	string	Issuing authority. Censio is the first issuer; the layer is open to conforming third parties.

§2 · TIP-2 · SEAL

Canonicalisation and fingerprinting.

The record is serialised as canonical JSON (RFC 8785 / JCS) and hashed with SHA-256. One record, one fingerprint — deterministic from any conforming implementation, in any language. The fingerprint, not the record, is what travels.

// canonical example — the record behind CX-924837
{
  "tip": "1.0",
  "id": "CX-924837",
  "claim": "The counterparty meets its Solvency II reporting obligations for FY2026",
  "confidence": 0.94,
  "evidence": { "sources": 52, "support": 47, "conflict": 3 },
  "methodology": "compliance-model/3.1",
  "issued_at": "2026-07-20T14:02:11Z",
  "version": 12,
  "supersedes": "CX-924837@v11",
  "issuer": "censio.io"
}
// JCS canonicalise → SHA-256 →
fingerprint: sha256:8f4e2b7c…c21a9b7d

§3 · TIP-3 · ANCHOR

Epoch batching, dual-rail anchoring.

Fingerprints are collected into epochs (~60 seconds), built into a Merkle tree, and the single root is anchored on two independent rails: an eIDAS-qualified timestamp (legally recognised proof of existence) and a public-chain transaction (immutable, provider-agnostic — anchoring-partner discussions are underway; the architecture does not depend on any one chain). The design is chain-agnostic: any network able to carry a 32-byte commitment can serve as a rail, and multiple rails may run in parallel. One anchor transaction makes every fingerprint in the batch tamper-evident for its lifetime.

Objects issued

Each sealed to one SHA-256 fingerprint

→

Epoch batch

~60s window · fingerprints only

→

Merkle tree

One root commits the whole epoch

→

Dual-rail anchor

eIDAS timestamp + public chain

→

Inclusion proofs

Stored per object · public

Anchor field	Definition
epoch	Epoch sequence number and closing timestamp.
root	Merkle root committing every fingerprint in the epoch.
proof	Per-object inclusion path from fingerprint to root.
rails	The anchor receipts: qualified-timestamp token and chain transaction reference.

§4 · TIP-4 · VERIFY

The verification walk.

Resolve the object by ID (or receive it directly — verification works offline from the record itself).
Recompute the fingerprint: canonicalise, hash, compare.
Walk the Merkle inclusion proof from the fingerprint to the anchored epoch root.
Check both rails: the qualified timestamp verifies against its authority; the chain transaction verifies against the public network.
Confirm the version chain: no missing versions, no unacknowledged supersession.

No step contacts the issuer. The verifier CLI and the <censio-verify> embed implement this walk; so can anyone else, from this page alone — that is the point. MCP tools map one-to-one onto this layer (verify_claim · get_trust_object · check_policy · monitor_claim), so AI agents verify mid-workflow, natively. Five conformant methods ship at launch: the web surface, the CLI, the embed, MCP, and fully offline verification from the record alone.

$ npx @censio/verify CX-924837
// recompute → walk proof → check rails → confirm chain
VERIFIED — independent of censio.io

§5 · TIP-5 · SUPERSEDE

Living records.

Trust is dynamic; the protocol carries the history. A new evaluation of the same claim issues a new version referencing its predecessor. Supersession notices propagate to consumers holding stale versions (webhooks; agents re-check via MCP). Revocation is a terminal supersession — the record stays verifiable, marked revoked, forever. Nothing is ever silently rewritten.

Conformance · issuer

Emits schema-valid records, seals per §2, anchors per §3, publishes methodology versions, honours append-only history.

Conformance · verifier

Implements the full §4 walk with no issuer dependency. Partial verification (fingerprint-only) must be labelled as such.

§6 · The extension family

One constitution. Six statutes.

TIP defines the record. Around it run six extension protocols — all Censio inventions, all already operating inside the platform: the freshness windows, version chains, warrant TTLs, custody tiers, outcome grading and conformance discipline you can see on the live surfaces are these protocols at work. Each is codified here and its full specification publishes progressively, in the order the toolchain opens. The long-form names are claimed as trademarks of Censio; registrations are queued alongside Trust Intelligence Protocol™ and CensioCert™. Most of this estate ran long before it had a name. Specifications can be copied; the issuance history cannot.

TWDPTime-Weighted Decision Protocol™V1 · Operational in the Censio platform

Time as a first-class input to trust. Confidence is not a constant: TWDP defines how it decays between evaluations, when a record must be re-derived, and how long any decision may rely on it.

"temporal": { "issued_at", "evidence_horizon", "half_life_s", "decay_model": "exp | step | cliff", "stale_after", "re_evaluate_after" }

Reader-side decay. Effective confidence at read time is computed by the consumer from the sealed parameters — the record itself is never mutated.
Hard staleness. No conforming consumer acts past stale_after without re-evaluation; a mandate’s TTL may never exceed the remaining freshness window.
Versioned decay. Decay parameters belong to the methodology version and are archived with it — yesterday’s curve remains provable forever.

Binds TIP-1 fields · TIP-5 cadence · enforced in /policy/check freshness & mandate TTLs

CDRPChronological Decision Replay Protocol™V1 · Operational in the Censio platform

Bit-exact replay of any past decision moment: what was known, what was authorised, what was decided. CDRP is the wire format the Black Box runs on — an append-only chronology of sealed ticks.

{ "decision_id", "tick", "object_version_refs"[], "mandate_refs"[], "policy_hash", "inputs_digest", "outcome_ref?", "seal" }

Deterministic replay. The same bundle reconstructs the same moment, byte for byte — canonicalised per TIP-2, anchored per TIP-3.
Gaps are evidence. Ticks are monotonic and digest-chained; a missing tick is detectable, not deniable.
Privacy by construction. Bundles carry version-pinned references and digests — never evidence content. Replay verifies offline via TIP-4, without Censio.

Consumes TIP-1–5 · product surface: The Black Box · visible today in /trust-object/:id/history

MWCPMachine Warrant Chain Protocol™V1 · Operational in the Censio platform

Delegated machine authority with provable narrowing. A mandate becomes a chain of warrants across agents — each hop cryptographically smaller than the last, each hop recorded, nothing widening, ever.

{ "warrant_id", "parent_id?", "object_id", "policy_hash", "scope": { "actions"[], "resources"[], "limits" }, "ttl_s", "depth", "max_depth", "sig": ed25519(issuer_chain) }

Monotone narrowing. A child’s scope is a subset of its parent’s; its TTL fits inside the parent’s remainder; its depth is bounded. A widening delegation cannot produce a valid signature.
Local verification. Chain checks are offline and O(depth) — microseconds on the hot path, no network call.
Cascading death. Supersede the root Trust Object and every descendant warrant dies at its next verification. Every hop lands in the CDRP chronology.

Extends Censio Mandates (the TIP enforcement profile) · recorded via CDRP · live surface: POST /mandate

OWRPOutcome Witness & Resolution Protocol™V1 · Operational in the Censio platform

Binds what happened back to what was assessed. When reality resolves, the outcome is attested as a signed witness against the original fingerprint — the calibration loop as a protocol, not a promise.

{ "object_id", "version", "outcome": "supported | contradicted | partial | expired", "resolved_at", "source_class", "evidence_digest", "attestor", "sig" }

Append, never amend. Witnesses attach to the version chain; the original record is untouched.
Conflicts surface. Multiple independent witnesses may disagree — disagreement is recorded, never silently averaged.
Reproducible track record. Calibration curves — predicted confidence against witnessed reality — are computable by any third party from sealed witnesses alone. This is the number a competitor cannot copy.

Binds TIP-1 refs · sealed per TIP-2/3 · builds the calibration track record — reproducible by any third party from sealed witnesses

EPCPEvidence Provenance & Custody Protocol™V1 · Operational in the Censio platform

Chain-of-custody for every evidence item — from source to citation. Nothing supports a confidence score without a custody record; nothing private ever leaves custody.

{ "source_id", "source_class", "licence_ref", "retrieved_at", "content_digest", "transform_log"[], "tier": "T1 | T2 | T3", "jurisdiction" }

No custody, no evidence. An item without a custody record cannot enter the evidence graph or move a score.
Digests travel, content doesn’t. Trust Objects cite custody references and fingerprints — Tier-3 private content is never published.
Licence-checked at seal. A record citing evidence outside its licence terms cannot seal. Custody records are themselves fingerprinted — tamper-evident end to end. EU AI Act record-keeping falls out by construction.

Feeds the TIP-1 evidence block · fingerprints per TIP-2 · spans the Tier 1–3 evidence network

TIFPTrust Interchange & Federation Protocol™V1 · Operational in the Censio platform

How Trust Objects travel between issuers — and how future issuers federate under one conformance regime, with Censio as first issuer and registrar of record.

{ "tip_version", "issuer_id", "registry_ref", "object", "conformance": { "vector_set", "passed_at" }, "countersig?" }

Acceptance is verification. A receiver accepts an interchanged object only by running the TIP-4 walk itself — never by trusting the sender.
Registry-anchored identity. Issuer keys rotate by append; history is preserved; standing and calibration references are public.
Conformance is proven. Issuers pass the published test vectors, and re-prove on every spec revision. Attribution survives interchange — an object never loses its issuer chain.

Interchange unit: TIP-1 schema · acceptance test: TIP-4 · root: the Censio registry