Trust Signals

This document specifies the structure and types of trust signals returned by the verification API.

Normative language follows RFC 2119: MUST, SHOULD, MAY indicate requirement levels.

Signal Envelope

Every trust signal MUST use this structure:

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

All JSON object keys MUST use camelCase. Signal type name strings (the type field value) are authority-defined. Spec-defined reference types use lowercase with underscores (e.g., recourse).

Field	Type	Required	Description
type	string	MUST	Signal type identifier. The authority defines which types it supports.
verifiedAt	string (RFC 3339, UTC)	MUST	When the authority last verified this signal
data	object	MUST	Type-specific signal data. Schema varies by signal type.

Each signal object (the complete type + verifiedAt + data structure) MUST NOT exceed 4 KB when serialized as JSON. This limit caps the prompt injection surface for authority-defined signal types with open data schemas. See the Security specification for prompt injection guidance.

Signal Types

The authority defines which signal types it supports. A signal is included in the response only if the authority has data for it — the authority MUST NOT return signals with empty data objects. Agents MUST NOT fail on unrecognized signal types. Programmatic agents SHOULD skip unknown types gracefully. LLM-based agents MAY interpret unknown signal types from their field names and values.

An empty signals array is valid. An entity MAY have status set to verified before signal data is collected — a normal state for newly onboarded entities. Authorities SHOULD return at least one signal when signal data is available. A response with no signals and no assessment gives agents nothing to act on beyond the status field itself.

Any string is a valid type value — the protocol does not restrict authorities to a fixed set. The following reference types illustrate common trust signals across domains. Authorities that represent the same concept SHOULD use the reference type name for interoperability. Authorities MAY define additional types that fit their data model. The OpenAPI spec enforces reference type schemas through a discriminated union, and a CustomSignal pattern accepts authority-defined extensions (see openapi.yaml, ADR-013).

Domain-specific examples beyond the reference types:

Domain	Example Types	Description
Healthcare	licensing, accreditation, hipaa_compliance	Professional licensing, facility accreditation, regulatory compliance
Financial services	regulatory_status, insurance, aml_kyc	Regulatory registration, insurance coverage, anti-money-laundering checks
Education	accreditation, certification_body	Institutional accreditation, certifying authority status
SaaS / API	uptime_sla, security_audit, data_residency	Service-level commitments, penetration test results, data hosting jurisdiction

These domain-specific types use the CustomSignal schema — authorities define the data structure. Agents that do not recognize them skip gracefully or, for LLM-based agents, interpret them from field names and values.

identity

Legal entity verification.

Data Field	Type	Required	Description
legalName	string	MUST	Registered legal name of the entity
country	string (ISO 3166-1 alpha-2)	MUST	Country of registration
registrationNumber	string	SHOULD	Official business registration number
registrationAuthority	string	MAY	Name of the registering authority
incorporationDate	string (ISO 8601 date)	MAY	Date of incorporation or registration
memberSince	string (ISO 8601 date)	MAY	When the entity was first verified by the trust authority

{
  "type": "identity",
  "verifiedAt": "2026-01-15T00:00:00Z",
  "data": {
    "legalName": "Example Electronics GmbH",
    "country": "DE",
    "registrationNumber": "HRB 12345",
    "registrationAuthority": "Amtsgericht München",
    "incorporationDate": "2019-06-01",
    "memberSince": "2025-08-10"
  }
}

reputation

Aggregated reputation data from verified sources (reviews, ratings, accreditation scores).

Data Field	Type	Required	Description
aggregateRating	number (1.0–5.0)	MUST	Weighted average rating across sources
reviewCount	integer	MUST	Total number of reviews across sources
sourceCount	integer	MUST	Number of independent review sources aggregated
ratingDistribution	object	MAY	Breakdown by star level: {"oneStar": count, "twoStar": count, "threeStar": count, "fourStar": count, "fiveStar": count}. Nullable.
periodMonths	integer	MAY	Time period the reviews cover (in months)

{
  "type": "reputation",
  "verifiedAt": "2026-03-01T00:00:00Z",
  "data": {
    "aggregateRating": 4.2,
    "reviewCount": 1247,
    "sourceCount": 3,
    "ratingDistribution": {"oneStar": 42, "twoStar": 68, "threeStar": 187, "fourStar": 412, "fiveStar": 538},
    "periodMonths": 12
  }
}

compliance

Regulatory and certification status.

Data Field	Type	Required	Description
certifications	array of strings	MUST	Active certifications or regulatory compliance
lastAudit	string (ISO 8601 date)	SHOULD	Date of most recent compliance audit
auditor	string	MAY	Name of the auditing entity
nextAudit	string (ISO 8601 date)	MAY	Scheduled date of next audit

{
  "type": "compliance",
  "verifiedAt": "2025-11-01T00:00:00Z",
  "data": {
    "certifications": ["PCI-DSS", "GDPR"],
    "lastAudit": "2025-11-01",
    "auditor": "TÜV Rheinland"
  }
}

recourse

Availability and type of recourse mechanisms (dispute resolution, complaints, appeals).

Data Field	Type	Required	Description
mechanism	string	MUST	Type of recourse (e.g., ombudsman, arbitration, mediation, internal, appeals_board)
provider	string	MUST	Organization providing the recourse service
responseTimeDays	integer	SHOULD	Committed response time in calendar days
url	string (URL)	MAY	Link to the recourse process or filing page

{
  "type": "recourse",
  "verifiedAt": "2026-02-01T00:00:00Z",
  "data": {
    "mechanism": "ombudsman",
    "provider": "EU ODR Platform",
    "responseTimeDays": 14,
    "url": "https://ec.europa.eu/consumers/odr"
  }
}

contact

Verified contact information. The authority confirms that contact channels are operational — it does not expose the actual contact details.

Data Field	Type	Required	Description
emailVerified	boolean	MUST	Whether a working email contact exists
phoneVerified	boolean	MUST	Whether a working phone contact exists
addressVerified	boolean	MUST	Whether a physical address has been verified
supportUrl	string (URL)	MAY	Link to the entity's customer support page

{
  "type": "contact",
  "verifiedAt": "2026-01-15T00:00:00Z",
  "data": {
    "emailVerified": true,
    "phoneVerified": true,
    "addressVerified": true,
    "supportUrl": "https://shop.example.org/support"
  }
}

Signals vs Assessment

The signals array contains verified facts — structured data with typed fields and verification dates. The optional assessment object (defined in the Verification API specification) contains the authority's interpretation of those facts: a recommendation, reasoning, and highlights. Signals are evidence. The assessment is opinion. The two serve different purposes and are intentionally separate in the response schema.

References

• Glossary — Canonical definitions for protocol terms
• Verification API specification — Response structure and assessment section
• ADR-003: Trust Signal Taxonomy
• ADR-004: Response Format
• ADR-010: Assessment Layer