Verification · TIP-4

Verify a Trust Object

Anyone holding an object ID can confirm what was asserted, when, on what evidence — without trusting Censio's word for it. Verification never routes through Censio's servers.

CensioCert™ · TIP — the Trust Intelligence Protocol™, a Censio invention · blockchain anchoring · active partner discussions underway

Reference surface · try a certified document or enter any object ID to inspect the record schema

What Censio does

The record between AI and the decision.

Censio is the layer between AI and the decisions made on it. Every AI-assisted assessment is issued as a Trust Object — calibrated confidence, the complete evidence set and an integrity seal — and anyone can verify it, without trusting Censio, under TIP, the Trust Intelligence Protocol™.

Real use case · autonomous vehicles

The road ahead is flooded. Says who?

A hazard report reaches the vehicle. Censio grades whether it is true and fresh before the car acts; a cryptographic warrant authorises the reroute at machine speed, verified on-device; and the whole decision is recorded, so it can be replayed and defended later. The vehicle never acts on an unverified rumour.

The protocol · TIP™

TIP — the Trust Intelligence Protocol.

Censio’s own invention: the open standard that records, seals, anchors, verifies and supersedes every machine-judgment record. Verification never routes through the issuer — a phone, a controller or a regulator can check a record from the sealed evidence alone. Read the specification →

Verified — authentic and unaltered
FINGERPRINT MATCHES ITS ANCHORED MERKLE ROOT · VERSION CHAIN INTACT
TRUST OBJECTCX-924837
AssessmentSolvency II compliance review
Confidence94% · evidence strength high
Evidence sources52 · contradiction low
MethodologyCompliance Model v3.1 (published)
Issued20 July 2026 · 14:02:11 UTC
IssuerCensio · Reach Infrastructure Ltd
Version12 · full history preserved
FingerprintSHA-256 · 8f4e2b7c a91d43f6 0e5c88ba d7f1264e 9b03c5a2 6d8e71f4 3ba9d0c8 c21a9b7d

Chain of proof

TIP-1
Record
Schema valid · evidence set sealed · methodology v3.1 archived
TIP-2
Seal
Canonical JSON recomputed · fingerprint matches 8f4e…9b7d
TIP-3
Anchor
Epoch 2026-07-20T14:03Z · batch #48,213 · 1,214 fingerprints
Merkle root b3a1f0…9d47e2 · dual-rail anchored
TIP-4
Verify
Inclusion proof walks to the anchored root · checked against the anchor, not against Censio
TIP-5
Supersede
Version 12 of 12 · no supersession notice · chain unbroken since v1

Methodology — how the confidence was computed

Compliance Model v3.1  Published · archived · replayable

Evidence weighting0.92
Source reliability0.88
Contradiction pressureLOW
Calibrated confidence0.94

Calibration means 94% behaves like 94%: of records scored in this band, ~94% resolve true. Calibration is audited against outcomes and published with each methodology version.

Evidence composition  52 sources

SUPPORT 47 CONFLICT 3 NEUTRAL 2

Tier 1 registers · regulators · commercial intelligence · enterprise systems. Every source carries its own reliability history in the Trust Graph; conflicting evidence is preserved in the record, never discarded.

Version 12 of 12 · chain unbroken since v1 · supersession monitored

Anchoring rails — the chain methodology, TIP-3

RAIL 1 · QUALIFIED TIMESTAMP

eIDAS-qualified timestamping

RFC 3161 tokens from a qualified authority — legally recognised proof of existence under eIDAS. The regulator-facing rail.

RAIL 2 · PUBLIC-CHAIN ANCHOR

Chain-agnostic Merkle commitment

Each epoch’s root is a single 32-byte commitment — carried by any public network. Immutable, censorship-resistant, independently checkable. Partner discussions underway.

RAIL DOCTRINE · PARALLEL

Any intact rail verifies

Rails run in parallel and cross-check. Verification succeeds on any intact rail; only the root ever leaves the issuer — never evidence, never customer data.

RAIL DOCTRINE · PARALLEL

Any intact rail verifies

Rails run in parallel and cross-check. Verification succeeds on any intact rail; only the root ever leaves the issuer — never evidence, never customer data.

Rail selection criteria — what the public rail must prove

Full validation at every participant — no miner or validator oligopoly Device-grade footprint — anchors must verify on a phone or an embedded controller Fully offline verification — no reach-back, no datacenter trust Minimal energy per epoch — one 32-byte root, batch-carried Censorship-resistant by construction
COMPATIBLE NETWORK CLASSES BITCOIN · OTS-STYLE AGGREGATION ETHEREUM & EVM · CALLDATA L2 ROLLUPS DEDICATED INTEGRITY NETWORKS RFC 3161 QTS

Network classes shown are compatibility targets of the TIP-3 design, not commitments or endorsements. The protocol requires only that a network carry a 32-byte commitment durably.

Published methodologies — versioned, archived, replayable

compliance-model/3.1Enterprise compliance & counterparty claimsCALIBRATION AUDITEDPUBLISHED
market-claims/2.4Market & financial assertionsCALIBRATION AUDITEDPUBLISHED
source-reliability/5.0Source scoring — feeds the Trust GraphCONTINUOUSPUBLISHED
scientific-evidence/1.9Research & clinical claimsCALIBRATION AUDITEDPUBLISHED

Every methodology version is archived under TIP-1: any historic record can be inspected — and replayed — under the exact version that produced it. Nothing is scored by an unpublished method.

The anchoring pipeline — TIP-3

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
Anyone verifies
● Not via Censio
Rail 1 — eIDAS-qualified timestampLegally recognised proof of existence at a moment in time
Rail 2 — public-chain anchorChain-agnostic · any network carrying a 32-byte commitment · partner discussions underway

Only the epoch's Merkle root touches the chain — never the evidence, never customer data. A single on-chain transaction makes every fingerprint in the batch an immutable hash record — tamper-evident, auditable and independently checkable for its lifetime. Anchoring-partner discussions are ongoing.

Verification methods — five conformant ways to run TIP-4

M1
WEB
This surface — any object ID or document QR.
M2
CLI
npx @censio/verify — open source.
M3
EMBED
<censio-verify> badge in any page or app.
M4
MCP
Agents call verify_claim mid-workflow.
M5
OFFLINE
From the record alone — no network, no issuer.

All five implement the same walk from the public specification. Any third party can build a sixth — the protocol is chain-agnostic and issuer-independent by design.

The protocol — five layers

TIP-1
RECORD
The governed Trust Object schema.
TIP-2
SEAL
Canonical JSON → SHA-256 fingerprint.
TIP-3
ANCHOR
Epoch Merkle root, anchored dual-rail.
TIP-4
VERIFY
Proof walk — never via the issuer.
TIP-5
SUPERSEDE
Version chains · living records.

Verify independently

$ npx @censio/verify CX-924837
// resolves the object, recomputes the fingerprint, walks the inclusion proof
✓ fingerprint match · 8f4e2b7c…c21a9b7d
✓ inclusion proof · epoch #48,213 → root b3a1f0…9d47e2
✓ anchor intact · eIDAS timestamp + chain transaction
✓ version chain · v12 · no supersession
VERIFIED — independent of censio.io

The verification walk is fully specified — any third party can implement TIP-4 from the public specification alone; the Censio CLI and the <censio-verify> embed are part of the launch toolchain. CX-924837 is the published reference record: the walk shown is the TIP-4 procedure, exactly as specified.

Verification confirms the record's authenticity and integrity — not a valuation or endorsement. Only the cryptographic fingerprint is anchored; the underlying evidence never leaves the issuer's control. Read the protocol →