Skip to main content

ADR-003: Trust Signal Taxonomy

Status: Accepted (revised 2026-03-23) Date: 2026-03-20

Context​

The /v1/entities/{entityId}/trust-signals endpoint (ADR-002) returns trust signals for an entity. The protocol must define what types of signals exist. Too rigid and the protocol cannot serve new industries. Too open and agents cannot reason about what they receive.

Decision​

Use an open taxonomy with reference types. The authority defines which signal types it supports. The specification documents a set of reference types with schemas that illustrate common trust signals across domains, but does not require authorities to implement any specific set. Authorities that represent the same concept SHOULD use the reference type name for interoperability. Any string is a valid type value.

Reference Signal Types​

TypeDescriptionExample Data
identityLegal entity verification — business name, registration, country{"legalName": "...", "country": "DE", "registrationNumber": "HRB 12345"}
reputationAggregated reputation data from verified sources (reviews, ratings, accreditation scores){"aggregateRating": 4.2, "reviewCount": 1247, "sourceCount": 3}
complianceRegulatory and certification status{"certifications": ["PCI-DSS", "GDPR"], "lastAudit": "2025-11-01"}
recourseAvailability and type of recourse mechanisms (disputes, complaints, appeals){"mechanism": "ombudsman", "provider": "EU ODR Platform", "responseTimeDays": 14}
contactVerified contact information{"emailVerified": true, "phoneVerified": true, "addressVerified": true}

Authorities MAY define additional types that fit their data model (e.g., licensing, regulatory_status, security_audit, data_residency). Agents MUST NOT fail on unrecognized signal types.

Signal Envelope​

Every signal uses the same envelope:

{
  "type": "string",
  "verifiedAt": "RFC 3339 datetime (UTC)",
  "data": {}
}

The data field is type-specific. The envelope fields are universal.

Options Considered​

A. Fixed set. Protocol defines a closed set of signal types. Predictable for agents. Cannot accommodate new industries or evolving trust requirements without a protocol version bump.

B. Extensible with core. Core set that all authorities must implement, plus namespaced extensions for domain-specific signals. Adds rigidity (authorities must fit their data into five prescribed buckets) and governance overhead (namespace registry). The core/extension distinction matters for multi-authority interoperability but adds no value in a single-authority model.

C. Open taxonomy with reference types (chosen). The protocol documents reference types with schemas but does not mandate any. Authorities return the types that match their data. Agents do not fail on types they do not understand — LLM-based agents can interpret them. Forward-compatible — new types require no protocol changes. The authority's data model drives the signal types, not the other way around.

Consequences​

  • Authorities define signal types that match their actual data
  • Adding a new signal type requires no protocol changes — just documentation
  • Agents handle unknown types gracefully (ignore them)
  • Interoperability between authorities is looser — no guaranteed shared vocabulary. If multi-authority interoperability becomes important, a shared type registry can be introduced later.
  • The reference types serve as a starting vocabulary, not a requirement

References​

  • ADR-002 — Verification Endpoint Schema (response structure)
  • ADR-004 — Response Format