
Explore identity and delegated-authority architecture patterns.
Learn how identity, scoped authority, policy decisions, changing trust signals and evidence fit into enterprise systems. These guides explain reference patterns and design boundaries; verified implementation details live in the current developer documentation.
Filter by question, actor and depth
Choose a topic, an actor category and a reading depth. Filters appear only for values the guide registry supports. This layout shows the controls and their states; no guide inventory is published yet.
No guides match these filters
Remove a filter, or clear all. Your selections are kept until you change them.
The guide index is temporarily unavailable. Featured pattern steps remain on this page. We will not describe the library as empty.
Guide cards appear once they are approved
Each card shows a question, its audience, actor tags, depth and, when verified, a review date. Only published, approved guides appear here.

Architecture overview
Question the guide answers: where each trust decision sits.

Authority and policy
Question the guide answers: how a permitted action is decided.

Signals and revocation
Question the guide answers: how changed context affects access.
Card titles above are placeholders for the catalog structure. No guide with these titles is published.
A route for first-time enterprise architects
These cards are an editorial reading order, not setup tasks. They do not track completion.
Understand the actor
Who or what is represented in a trust decision.
Identify the authority
What may be done, and under which mandate.
Define the policy decision
Where decisions are made and what they consider.
React to trust changes
How signals can prompt re-evaluation or revocation.
Preserve minimal evidence
What is recorded, and why it is limited.
Choose implementation docs
Where exact interfaces are documented.
Identity, authority, policy and evidence
A conceptual sequence showing who owns each decision. It is not a map of any deployed system.
Actor identity
Who is represented.
Verified context
Claims assessed against evidence.
Scoped authority
The mandate: what, for whom, until when.
Policy decision
Current rules applied to the request.
Minimal evidence
A record of the basis for the decision.
Text equivalent.
- 1. Actor identity establishes who is represented.
- 2. Verified context assesses supporting claims against governed evidence.
- 3. Scoped authority records what may be done, for whom, and until when.
- 4. A policy decision applies current rules to the specific request.
- 5. Minimal evidence records the basis for the decision, within privacy limits.
Alongside your existing identity provider
The intended design complements existing identity providers and applications. Each side keeps its own responsibilities. Exact features depend on confirmed contracts.
Your identity provider
Authenticates people and services.
Your application
Requests decisions and enforces them.
Trust layer
Evaluates scope, policy and context.
Evidence store
Holds the decision record.
Protocol and feature labels. Any named protocol here describes a design direction. It is not confirmed as generally available. Check the Integrations page and API Reference for exact support.

Authority is granted, not implied
Being affiliated with an organization, or holding a credential, does not by itself grant authority. A delegation names the principal, the delegate, the purpose, the resources, the time limit and the revocation path.

Principal and delegate
Who gives authority, and who receives it.
Purpose, resources and time
What the authority covers, and until when.
Review and revocation
How the grant is reviewed and withdrawn.
Five actor types, five different governance needs
Each actor type has different sponsors, controls and workflows. None is assumed to use the same verification method.

Human
Signs in and acts for themselves.

Organization
An affiliation, recorded explicitly.

Service
A workload with its own narrow role.

Machine
A device or process with bounded duty.

AI agent
Acts only under explicit, sponsored authority.
How a change in context can be handled
A conceptual lifecycle. Exact event names, timing and automatic actions are defined by the engineering source, not by this page.
New signal
A change in context is received.
Re-evaluate
Current policy is applied again.
Decide
Allow, step up, restrict or deny.
Revoke
Withdraw authority where permitted.
Record evidence
Keep the basis for review.

Minimal, purposeful, reviewable
Evidence shows the actor, the scoped authority, the policy version, the decision and the time. Privacy controls limit what is collected, how long it is kept and who can see it.
What evidence explains
- Which authority applied
- Which policy version
- What was decided, and when
What is protected
- Access to records
- Data beyond the decision's need
- Retention, per approved policy
Retention durations and immutability guarantees are not stated here.
How every architecture guide is structured
This is the layout each guide follows. It is a template, not a guide.
SCOPE AND AUDIENCE
What the guide covers and who it is for
APPLICABILITY
When the pattern is relevant
PREREQUISITES
What to read first
DIAGRAM
Conceptual, with a full text equivalent
BOUNDARIES
Who owns each decision
FAILURE MODES
What can go wrong, and the safe response
RELATED DOCUMENTATION
Approved technical destinations only
OWNER AND REVIEW
Accountable owner, reviewed date when approved
For exact interfaces, go to the source
This guide explains patterns. Exact contracts, tested steps and release changes live in their own destinations.

Developer Overview
Orientation for building.

Quickstarts
Step-by-step guidance.

API Reference
Exact interface contracts.

SDKs
Language packages and their status.
Integrations, Webhooks & Events and Sandbox links appear here only when their destinations are approved and their availability is confirmed.
Frequently asked questions
Find answers to common questions about Zoiko iD

Explore more patterns,
or move to the technical material.
Continue with the identity concepts, read the developer documentation for exact interfaces, or discuss your architecture with an identity expert.