45. Institutional identity, functional roles, authority, and external-source adapters
RTracer must interoperate with registries, insurers, assessors, repairers, event operators, payment providers, marketplaces, tax services, safety bodies, clubs, schools, employers, and government authorities. An institution profile identifies an actor; it…
RTracer must interoperate with registries, insurers, assessors, repairers, event operators, payment providers, marketplaces, tax services, safety bodies, clubs, schools, employers, and government authorities. An institution profile identifies an actor; it does not prove that the actor is competent, current, applicable, or authorized for the requested act. Every consequential institutional result remains an attributed, time-bound assertion evaluated under a pinned policy.
#45.1 Institution identity is not authority
An InstitutionProfile binds one platform principal to declared names, legal-identity assertions, service endpoints, jurisdiction claims, qualification evidence, and status. The profile MUST NOT grant a functional role by itself. A brand page, verified domain, registry number, payment account, or prior transaction MUST NOT be treated as current authority.
| Layer | Answers | Does not answer |
|---|---|---|
| InstitutionProfile | Which principal claims or proves which institutional identity? | Whether it may make this decision now |
| InstitutionalRoleAssignment | Which issuer attributes which functional role, scope, jurisdiction, and interval? | Whether the caller authenticated or received a platform grant |
| CapabilityGrant | Which authenticated principal may perform which platform action over which resources? | Whether an external legal or professional conclusion is true |
| ExternalAuthorityAssertion | What did a named external source assert, when, and from which native record? | Universal truth outside the issuer and policy scope |
| CaseDecision | What scoped outcome did an accountable decider select from a pinned evidence set? | Erasure of competing evidence or appeal rights |
#45.2 Functional-role assignments and qualification assertions
Functional roles are vocabulary terms such as vehicle_registry_source, title_reviewer, insurer, loss_assessor, repairer, safety_inspector, moderation_reviewer, appeal_reviewer, auction_operator, market_integrity_reviewer, incident_commander, tax_determination_provider, and management_team_member. A role assignment records issuer, authority basis, permitted action families, subject selectors, domain and jurisdiction scopes, restrictions, valid interval, and verification state.
A current role assignment is necessary but insufficient for a platform effect. The runtime MUST also authenticate the acting principal, resolve a current attenuated CapabilityGrant, apply separation-of-duty rules, and evaluate action-specific policy at dispatch. Role assignments and grants expire, suspend, dispute, and revoke independently.
#45.3 External query and assertion receipts
Every external lookup produces an ExternalAuthorityQueryReceipt even when the result is NO_MATCH, AMBIGUOUS, UNAVAILABLE, or ERROR. The receipt binds the source institution, endpoint profile, query-selector digest, requested assertion kinds, request and response times, raw response artifact digest, source proofs, and freshness policy.
Native response bytes are retained as evidence when policy permits. Normalized values are separate versioned derivations carrying the vocabulary, transformation code digest, input artifact digest, and limitations. An unavailable response or NO_MATCH MUST NOT be projected as absence of title interest, lien, restriction, insurance, recall, theft report, tax duty, or other real-world fact.
#45.4 Authority applicability, freshness, and conflicts
Authority evaluation is a function of issuer, functional role, subject, asset/configuration, action, jurisdiction, effective interval, fetch time, source freshness policy, proof status, conflict set, and requested consequence. A cryptographically valid but stale assertion may remain useful historical evidence while being ineligible for a transfer or safety decision.
| Input condition | Required projection |
|---|---|
| current, applicable, independently verified | eligible input; never automatic truth |
| stale | preserved with stale status; refresh or decide under explicit exception |
| source unavailable | unavailable; no negative inference |
| two applicable sources conflict | conflicted; retain both and open review where required |
| issuer role expired or revoked | provenance retained; ineligible for new high-impact decisions |
| jurisdiction or subject scope unknown | indeterminate; fail closed for R3/R4 effects |
#45.5 Institutional service endpoints and trust profiles
An endpoint profile pins transport, authentication, response schemas, native identifiers, proof verification, rate limits, retention, privacy, incident contacts, and query semantics. Trust profiles state which assertion kinds the platform may accept from which institutional roles, their maximum age, corroboration requirements, and permitted consequences. Endpoint availability never changes the semantics of a stored assertion.