Product Learning Path

Module 06 · Product adoptionLesson 11 of 12

Product Learning Path

Mixed10–14 min1 prerequisite

Before you start

• Understand the conceptual Academy path or know which role-based track you are following.

After this lesson you can

• translate Academy concepts into a practical Mandaitor evaluation route
• decide which product surfaces matter for your team first
• prepare implementation questions for builders, reviewers, and leadership

The Product Learning Path connects Academy concepts to practical Mandaitor use. By this point, you should understand why delegated authority matters, how identity and proof concepts support verification, why agentic tool calls need runtime checks, and how evidence supports governance. This chapter explains how those ideas become a product adoption journey.

Mandaitor should not be introduced as “one more API” before teams understand the operating model. The product is easiest to evaluate when a team first identifies a real delegation problem, then models its principals and delegates, then defines mandate boundaries, then verifies actions, and finally reviews evidence.

The journey from concept to implementation

Step	Main question	Product surface to explore
Identify use case	Which agent or workflow needs bounded authority?	Academy, examples, internal use-case workshop.
Map actors and resources	Who is the principal, who is the delegate, and what resources are affected?	Agent Identity Registry, tenant model, resource taxonomy.
Design mandate boundaries	What actions, constraints, time windows, and obligations apply?	Mandate templates, scopes, constraints, lifecycle settings.
Create mandates	How is authority granted and activated?	Mandate API, dashboard flows, approval workflows.
Verify actions	How does a runtime know whether a tool call is allowed?	Verification endpoint, MCP authorization pattern, SDKs.
Capture evidence	What proof, audit events, and trace data are retained?	Proof-of-Mandate, audit events, evidence packs.
Review and improve	Are policies too broad, too narrow, stale, or missing?	Compliance dashboard, Trust Portal, review workflows.

Concept-to-product route

Follow the first Mandaitor adoption journey

Use this walkthrough as a practical checklist. Each step begins with a plain-language design question, then maps that question to a Mandaitor product surface that users can explore during evaluation.

01

Academy + workshop

Identify one bounded use case

Begin with a real workflow where an agent, service, or human delegate needs limited authority rather than broad application access.

• Name the business action that creates value.
• Describe the risk if the action happens outside authority.
• Keep the first scope narrow enough that success and failure are visible.

Use-case briefRisk signalSuccess criterion

02

Agent Identity Registry

Map principals, delegates, and resources

Separate the authority owner from the actor that performs the work, then connect both to the resources that will be affected.

• Record the principal whose authority is delegated.
• Register the delegate identity at the agent, service, or workflow level.
• Name the resource categories that verifiers will evaluate.

PrincipalDelegate DIDResource taxonomy

03

Mandate templates

Define mandate boundaries

Turn the workflow into explicit authority: permitted actions, resources, constraints, time windows, obligations, and escalation rules.

• Prefer verifiable constraints over informal policy notes.
• Add lifecycle states so authority can expire or be revoked.
• Include obligations when the delegate must retain or submit evidence.

ActionsConstraintsLifecycle

04

Mandate API

Configure and issue the mandate

Create the mandate in a form that can be inspected by people and evaluated by runtime systems before sensitive work executes.

• Use approval flows where the authority grant itself needs review.
• Expose human-readable context for operators and reviewers.
• Avoid replacing narrow mandates with one broad super-token.

Create mandateApproval stateReadable summary

05

Verification API

Connect the agent identity to runtime checks

Ensure the agent or tool client asks for a decision before acting, using the registered identity, requested action, resource, and contextual facts.

• Pass the delegate identity and requested action to verification.
• Include context such as amount, tenant, project, or time window.
• Treat deny and escalation decisions as normal product paths, not edge cases.

Pre-action checkContext payloadAllow / deny / escalate

06

Proof-of-Mandate

Capture proof and audit events

Store enough evidence for another system or reviewer to understand what authority was checked and why the decision was made.

• Persist the mandate reference and verification result.
• Record reason codes for denied or escalated requests.
• Link runtime events to evidence packs for later review.

ProofReason codeEvidence pack

07

Compliance Dashboard

Review posture and improve policy

Use dashboard signals to see whether mandates are healthy, stale, too permissive, incomplete, or producing avoidable exceptions.

• Inspect gaps before expanding to higher-impact workflows.
• Compare runtime decisions with expected test cases.
• Turn recurring exceptions into better templates or escalation rules.

Status panelsEvidence completenessPolicy iteration

Start with a concrete use case

A strong first Mandaitor use case has a clear principal, a clear delegate, a bounded action set, and visible risk if the action exceeds authority. Avoid beginning with a vague goal such as “make all agents trusted.” Start with one workflow where authority can be described.

Use case type	Good first question	Example mandate boundary
Finance operations	May an agent create or submit a payment request?	Create payment requests below a threshold for approved vendors.
Customer operations	May an agent update a customer record?	Update non-sensitive fields for assigned accounts during business hours.
Construction validation	May an agent approve or submit validation artifacts?	Submit validation packages for a specific project and role.
Procurement	May an agent request a quote or place an order?	Request quotes broadly but place orders only below an amount cap.
Internal knowledge work	May an agent access documents?	Read project documents for a specific case, excluding restricted folders.

The goal is not to automate everything immediately. The goal is to select a workflow where the value of explicit authority, verification, and evidence is obvious.

Map the actors before writing policy

Many implementation mistakes happen because teams write permissions before they understand actors. Mandaitor distinguishes the principal who owns authority, the delegate who acts, the relying verifier that evaluates authority, and reviewers who inspect evidence later. Those actors may be people, agents, services, tenants, counterparties, or governance roles.

Actor	Design question	Common mistake
Principal	Whose authority is being used?	Treating the agent account as the true owner of authority.
Delegate	What actor performs the action?	Failing to distinguish a model, agent runtime, workflow, and tool client.
Resource	What is affected by the action?	Using broad resource names that make verification imprecise.
Verifier	Who decides whether the proof is sufficient?	Assuming every downstream API will trust the same evidence in the same way.
Reviewer	Who must understand the action later?	Capturing logs but not decision reasons or mandate context.

Move from broad goals to testable mandates

A mandate should be narrow enough to evaluate but expressive enough to support real work. If it is too broad, it becomes a disguised super-token. If it is too narrow, users will constantly request exceptions. The product learning path should therefore include test cases before production use.

Test case	Expected outcome	Learning value
Valid action inside scope	Verification returns allowed and produces evidence.	Confirms the happy path.
Valid actor but wrong resource	Verification denies or requests a different mandate.	Confirms resource boundaries.
Correct action after expiry	Verification denies due to lifecycle status.	Confirms time and lifecycle controls.
Amount above threshold	Verification denies or requests escalation.	Confirms contextual constraints.
Missing evidence requirement	Dashboard shows a gap or incomplete record.	Confirms review and evidence expectations.

Connect product surfaces to learning outcomes

Each product surface should be understood as part of the authority lifecycle. This helps users avoid treating Mandaitor as a collection of disconnected features.

Product surface	Academy concept it operationalizes	What success looks like
Mandate creation	Verifiable delegation and mandate policies.	Authority is bounded, understandable, and lifecycle-managed.
Agent Identity Registry	Decentralized and persistent identity concepts.	Agents and services can be distinguished and tied to mandates.
Verification API	Runtime authority checks.	Tool calls are evaluated before sensitive execution.
Proof-of-Mandate	Credential-style evidence.	Relying systems can inspect proof rather than trust broad tokens.
Audit events	Evidence capture.	Reviewers can reconstruct decisions.
Compliance dashboard	Governance visibility.	Teams can see status, gaps, and readiness signals.

Suggested adoption phases

A measured adoption path reduces risk. Teams should begin with one or two bounded workflows, collect evidence, inspect false positives and false negatives, and then expand to more sensitive actions.

Phase	Goal	Exit criterion
Discovery	Understand actors, risks, and resources.	A concrete delegation scenario is documented.
Pilot	Test mandates and verification with limited blast radius.	Allow/deny decisions match expected policy in test cases.
Evidence review	Confirm that records are useful to humans.	A reviewer can understand why actions were accepted or denied.
Integration hardening	Add lifecycle, revocation, monitoring, and escalation.	Failure modes are documented and handled.
Expansion	Apply the model to broader or higher-impact workflows.	Dashboard and evidence processes scale beyond the pilot.

What to read next

Use this chapter as the bridge into the implementation docs. If you are still uncertain about the conceptual model, return to Foundations, Mandate Policies, and Agentic Authorization. If your team is ready to evaluate maturity, continue with Development Status.

Progress

Save your learning progress

Mark this lesson as complete to update the Academy overview without requiring an account.