Trust Center

Give an authenticated subject a consent-aware, policy-versioned trust workflow: discover requirements, start and monitor verification, inspect minimized attestation and credential commitments, and manage allowlisted self-asserted claims without exposing regulated evidence or collapsing issuer, reviewer, provider, subject, and relying-party authority.

BUSINESS CASES

Where this module fits

identity onboarding
policy, consent, and retention disclosure
KYC/AML posture review
age or eligibility commitment review
credential and attestation lifecycle reconciliation
subject claim management

PRIMARY CONSUMERS

Who integrates it

identity subjects
consent-aware onboarding applications
trust and verification agents
credential issuers and relying-party integrators

PREREQUISITES

What must exist first

subject-scoped trust authority for subject actions, with separate issuer or reviewer authority for their own future lifecycles
an applicable policy ID, immutable version, jurisdiction, evidence purpose, consent record, and retention basis
a relying-party rule for acceptable issuer, proof type, lifecycle, freshness, assurance, disclosure, and revocation checking

RECOMMENDED WORKFLOW

Compose the module safely.

01
fetch current verification policy and sanctions-source posture
02
select the least intrusive applicable policy and disclose checks, evidence classes, freshness, jurisdiction, and retention before consent
03
start one idempotent subject-owned verification through the canonical trust lifecycle
04
poll minimized verification state and distinguish capture, check completion, review, and final decision
05
evaluate credential or attestation lifecycle, validity, issuer proof, assurance, and commitments under the relying-party policy
06
manage private self-asserted claims separately from verification evidence and issuer-backed credentials

AGENT INTEGRATION

Machine-use boundaries

Trust signals are scoped, versioned, purpose-limited, and time-bound evidence—not a universal score or permission to pay, transfer, trade, disclose, administer, or bypass another domain's policy.
No one authority substitutes for another: a subject can consent and manage eligible claims, a provider can report bounded evidence, a reviewer can evaluate an assigned case, an issuer can create or revoke its credential, and a relying party can apply its own acceptance policy.
A policy catalog entry means a workflow is available; it does not mean the subject started, completed, or passed it. A provider callback, captured evidence item, completed check, reviewer action, final decision, issued credential, and relying-party acceptance are distinct lifecycle facts.
Evaluate verification status and checks, credential or attestation lifecycle, validity window, issuer signature posture, proof type, assurance, revocation freshness, and commitments together.
Treat verification evidence as metadata plus commitments, not retrievable media; keep claim cleartext, personal and address data, identity documents, selfies, biometric material, screening matches, provider payloads, and reviewer notes out of prompts, URLs, logs, analytics, and shared caches.
A self-asserted claim may be unverified and include_in_credential is intent only; never represent either as issuer-backed assurance or evidence of disclosure consent.
Legacy KYC payload, generic action, review, attestation, provider-callback, and sanctions-sync routes are bodyless 501 migration markers at the public V2 boundary. Never translate their legacy bodies; use only canonical operations present in live OpenAPI.
Reviewer queues and decisions, regulated evidence upload or retrieval, provider callbacks, sanctions synchronization, selective-disclosure challenges and presentations, and credential issuance, suspension, or revocation remain non-executable publicly until their exact owner-specific contracts appear in live OpenAPI.
Trading, matching, prediction, ingress, publisher, allowlist, suspension, market-status, and traffic controls remain frozen and cannot be changed by a trust signal, verification result, credential, attestation, claim, or compatibility route.

Register only production-listed routes as executable tools, and re-fetch the deployed OpenAPI before generating or sending a request. Source-ready routes awaiting deployment are preparation references; planned contracts are non-executable.

MODULE CONTRACTS

Every mapped endpoint

Each operation states whether its request shape is authoritative in OpenAPI, reviewed as a planning profile, or intentionally left as an outline pending an owner schema.