Mandaitor Academy
Learn verifiable authority for agentic systems from first principles.
The Mandaitor Academy is a guided learning layer for users, builders, reviewers, and decision makers. It explains why bounded authority, identity, credentials, mandates, runtime checks, evidence, and governance matter when AI agents can use tools and business systems.
The Mandaitor Academy is not a reference manual. The regular documentation tells you how to integrate the product. The Academy explains why Mandaitor exists, which identity and authorization ideas it builds on, and how those ideas apply when AI agents can act through tools, APIs, workflows, and business systems.
Mandaitor starts from a simple but demanding premise: an agent should not be trusted merely because it can authenticate or because it was instructed in a prompt. It should be able to show bounded, verifiable, auditable authority for the specific action it is about to perform. That premise connects classical access control, decentralized identity, verifiable credentials, agentic AI, runtime policy enforcement, evidence generation, and governance.
The Academy is written for learners who may have no prior background in identity systems, verifiable credentials, authorization models, agentic AI, or compliance evidence. It teaches from first principles and gradually connects those concepts to Mandaitor's platform surfaces.
Move from first principles to product confidence
The Academy is organized as a learning product: each stage builds a mental model, connects it to a Mandaitor surface, and prepares the learner for a more advanced product or governance decision.
Start with authority, not tooling
Learn why capability and access are not the same as delegated authority, especially when agents can call business tools.
- Define principal, delegate, verifier, mandate, and evidence.
- Understand why prompt instructions are not enough for sensitive actions.
Add identity and proof
Connect DIDs, credentials, claims, and trust chains to the practical problem of knowing who is acting and why proof should be accepted.
- Treat agents as identifiable subjects.
- Separate technical proof validity from business trust decisions.
Verify runtime actions
Translate authority boundaries into policy checks that happen before a tool call, API request, or workflow action executes.
- Model scopes, constraints, lifecycle states, and escalation paths.
- Use verification decisions as a control point, not as after-the-fact logging.
Review evidence and adopt the product
Use evidence packs, dashboard signals, and staged product evaluation to improve policy, support reviewers, and plan implementation.
- Read dashboard signals through their underlying evidence.
- Move from one bounded use case to a repeatable adoption route.
Choose the route that matches your role
Completely new to all of this? You don't need to choose anything. Take the beginner path — start with Foundations and read the chapters in order; every lesson hands you to the next one.
If you arrive with a specific responsibility — deciding whether Mandaitor is strategically relevant, designing the authority layer, reviewing evidence, or preparing a pilot — pick the one route below that matches it. Each route uses the same chapter library but changes the reading order, the emphasis, and the artifact you end up with.
Founder / Decision-maker
Is verifiable delegated authority strategically important enough to influence product, risk, or go-to-market decisions?
- Outcome
- A concise authority-boundary narrative that explains why Mandaitor matters for agentic workflows.
- Suggested effort
- 45–70 min
- 01Foundations of Verifiable DelegationFrame the difference between access, capability, and delegated authority before evaluating product fit.
- 02Agentic AI from First PrinciplesConnect autonomous tool use to the need for explicit authority boundaries and runtime checks.
- 03Compliance Dashboard ExplainedUnderstand what executives and reviewers can see when agent actions become inspectable.
- 04Governance, Risk, and ComplianceTranslate the Mandaitor model into risk, control, and accountability language.
- 05Capstone Pilot WorkbookComplete the authority-boundary milestone to decide whether a first pilot is worth pursuing.
- One-sentence pilot thesis
- Named authority boundary
- Decision criteria for continuing or pausing evaluation
Builder / Platform Engineer
How should mandates, policies, verification decisions, and evidence fit into a runtime architecture?
- Outcome
- A technical route from policy design to evidence-producing authorization checks.
- Suggested effort
- 75–110 min
- 01Mandate Policies and Policy EnforcementModel principals, delegates, actions, resources, constraints, obligations, and lifecycle states.
- 02Agentic AuthorizationPlace the verification decision before tool calls, API requests, and workflow actions.
- 03Trust ChainsSeparate cryptographic validity from local business acceptance and issuer trust.
- 04Evidence Packs and Audit EventsTurn verification outcomes into reviewable artifacts that support debugging and assurance.
- 05Capstone Pilot WorkbookComplete the policy and evidence milestones for a bounded implementation scenario.
- Initial mandate-policy sketch
- Runtime verification control point
- Evidence fields required for review
Reviewer / Compliance Officer
Can I inspect what an agent was allowed to do, why it was allowed, and which evidence supports that decision?
- Outcome
- A review model for dashboard signals, evidence packs, and governance controls.
- Suggested effort
- 60–95 min
- 01Compliance Dashboard ExplainedRead review queues, risk signals, and evidence status through the product surface.
- 02Governance, Risk, and ComplianceMap Mandaitor evidence to control ownership, risk treatment, and compliance review.
- 03Evidence Packs and Audit EventsUnderstand what evidence should be present before accepting an agentic action as reviewable.
- 04Product Learning PathSee how review expectations connect to adoption planning and staged product evaluation.
- 05Capstone Pilot WorkbookComplete the dashboard-review milestone and define the first review gate.
- Minimum evidence checklist
- Reviewer questions for policy exceptions
- Dashboard review gate for the pilot
Implementation Lead / Pilot Team
How do we convert Academy concepts into a bounded first pilot with owners, gates, and readiness criteria?
- Outcome
- A complete workbook-driven pilot plan that aligns product, engineering, security, and governance stakeholders.
- Suggested effort
- 120–180 min
- 01Product Learning PathUnderstand the adoption route from product evaluation to a bounded implementation path.
- 02Foundations of Verifiable DelegationAlign the team on the shared authority model before debating implementation details.
- 03Mandate Policies and Agentic AuthorizationUse the policy and runtime lessons to scope the pilot workflow and control points.
- 04Evidence, Dashboard, and Governance LessonsConnect operational evidence to reviewer workflows and executive readiness decisions.
- 05Capstone Pilot WorkbookComplete the full workbook, pilot checklist, ownership model, and expansion gate.
- Pilot scope and success criteria
- Named owners across product, engineering, security, and governance
- Go / no-go gate for expansion beyond the first workflow
Track your progress
Lesson progress, track badges, your day streak, and — once all five tracks are complete — a downloadable Academy certificate all live locally in your browser; there is nothing to sign up for. The certificate can optionally be minted as a real verifiable credential.
Your Academy progress
Progress is saved locally in this browser. The Academy remains public; signing in later can sync learning state across devices and connect it to product onboarding.
Badges, streak, and certificate
Earn a badge by completing every lesson in a track. Your streak counts the days you complete at least one lesson. Finish all five tracks to unlock your Academy certificate. Everything is saved locally — no account required.
Academy versus documentation
The Academy and the documentation are complementary. The Academy explains mental models, background standards, and design trade-offs. The documentation remains the source for step-by-step integration guides, API contracts, SDK usage, identity-provider setup, and operational configuration.
| Surface | Best for | Example question |
|---|---|---|
| Academy | Building conceptual understanding before implementation. | Why is Proof-of-Mandate different from a generic API token? |
| Concepts | Reading focused explanations of Mandaitor primitives. | What is a mandate, constraint, audit event, or verification decision? |
| Guides | Implementing a concrete workflow. | How do I create a mandate and verify an action? |
| API Reference | Inspecting exact request and response fields. | Which fields does the verification endpoint expect? |
How Mandaitor fits into the broader technology landscape
Mandaitor does not invent the whole identity or AI-governance universe. It builds on established and emerging ideas. The W3C Verifiable Credentials Data Model defines a three-party model of issuers, holders, and verifiers for exchanging tamper-evident claims.1 W3C DID Core defines decentralized identifiers that can associate a subject with a DID document containing verification methods and services.2 The Model Context Protocol standardizes how LLM applications connect to tools and external context.3 NIST's AI Risk Management Framework frames AI risk as a socio-technical management discipline rather than a one-time technical checklist.4
Mandaitor's contribution is to bring these ideas into a practical authority layer for agentic systems. It gives teams a way to represent delegated authority, verify whether a proposed action fits that authority, and preserve evidence that can later be inspected by humans, systems, or auditors.