Capstone Pilot Workbook
Capstone Pilot Workbook
- Understand foundations, mandates, verification, evidence packs, dashboard signals, governance controls, and product maturity language.
- define a bounded Mandaitor pilot use case
- translate Academy concepts into concrete pilot artifacts
- separate a useful first pilot from an overbroad production rollout
- prepare a reviewer-ready evidence and governance checklist
The Academy now ends with a practical exercise. The Capstone Pilot Workbook turns the concepts from the previous lessons into a first bounded Mandaitor evaluation that can be reviewed by product, engineering, security, and governance stakeholders. It is intentionally smaller than a full implementation plan: the goal is to define one credible loop from delegated authority to verification, evidence, and review.
A useful pilot should not attempt to authorize every agent, every tool, and every business process. It should select one workflow where the authority boundary is understandable, the action risk is real, and the resulting evidence can be inspected by a human reviewer. This makes the pilot educational, technically testable, and governance-relevant at the same time.
Capstone scenario
Imagine a team evaluating Mandaitor for an AI agent that can prepare customer-support refunds. The agent can draft the refund action and call an internal tool, but the organization wants proof that the agent has delegated authority for the specific account, amount, reason, and timeframe before the refund executes. Reviewers also need evidence when a refund is approved, denied, or escalated.
You can replace this example with your own workflow. The exercise still applies if your first pilot is procurement approval, CRM update delegation, support-tool access, back-office automation, marketplace checkout assistance, or another bounded agentic workflow.
Design one complete Mandaitor pilot loop
Work through these milestones in order. Each milestone produces an artifact that can be reviewed, tested, and improved before the pilot expands.
Choose the authority boundary
Define one action the agent may request, who can delegate that authority, and what the agent must never do without additional review.
- A one-paragraph pilot use-case statement.
- Principal, delegate, verifier, and reviewer roles for the workflow.
- A short list of allowed, denied, and escalation-required actions.
- Is the pilot narrow enough to test safely?
- Can a non-engineer explain what the agent is allowed to do?
Model the mandate and policy
Translate the boundary into mandate scope, constraints, lifecycle state, and runtime verification expectations.
- A draft mandate scope with action, resource, amount, duration, and context constraints.
- Three verification examples: allow, deny, and escalate.
- A decision log explaining why each example should produce that result.
- Are constraints specific enough to prevent authority drift?
- Does the verifier reject actions outside the mandate instead of relying on post-hoc review?
Define evidence and dashboard review
Specify which audit events, Proof-of-Mandate details, and evidence-pack fields a reviewer needs after each verification decision.
- A minimal evidence-pack outline for the pilot.
- A reviewer checklist for approved, denied, and escalated actions.
- Dashboard signals that should indicate healthy, missing, or stale evidence.
- Can a reviewer reconstruct why the action was allowed or denied?
- Does the evidence support both operational debugging and governance review?
Set pilot gates and ownership
Define what must be true before the pilot starts, expands, or stops, and assign owners for policy, evidence, and operational response.
- Entry criteria for starting the pilot.
- Expansion criteria for adding another action or workflow.
- Rollback criteria and named owners for policy updates, evidence review, and exception handling.
- Would the team know when to pause the pilot?
- Are ownership and escalation paths visible before real tool access is granted?
- The first workflow is narrow, understandable, and testable without relying on implicit trust in prompts.
- The pilot has at least one allow case, one denial case, and one escalation case before expansion is discussed.
- Evidence can be inspected by a reviewer who was not involved in building the integration.
- Ownership, monitoring, and rollback expectations are explicit before the workflow is treated as production-ready.
Pilot readiness checklist
The checklist below helps decide whether the capstone is ready to move from classroom exercise to a practical evaluation. Treat every unchecked item as a learning opportunity, not as a failure. A pilot is strongest when it reveals missing assumptions before the workflow becomes operational.
Before you run the first pilot
Use this checklist with product, engineering, security, and governance stakeholders before granting real tool access to the agentic workflow.
Bounded use case
The pilot names one workflow, one primary action type, and the conditions under which the agent may request that action.
Role clarity
Principal, delegate, verifier, reviewer, and operational owner are identified in language that stakeholders can understand.
Verification examples
The team has documented at least one allow, deny, and escalate case before wiring the workflow into broader operations.
Evidence review
A reviewer can read the evidence pack and explain which mandate, policy, constraint, and runtime context drove the decision.
Dashboard interpretation
The team knows which dashboard signals indicate healthy evidence, missing evidence, stale authority, or a governance gap.
Expansion candidate
The team has identified a second workflow, but expansion waits until the first pilot satisfies evidence and ownership gates.
Capstone worksheet
Use the following worksheet in a team session. It is deliberately short so that the output can fit into a product brief, implementation ticket, or governance review note.
| Prompt | Your pilot answer |
|---|---|
| Which agentic workflow are we testing first? | |
| Who grants authority, who acts, and who verifies the action? | |
| Which action is allowed, which action is denied, and which action requires escalation? | |
| Which mandate constraints matter most: amount, resource, duration, purpose, geography, customer segment, or another condition? | |
| What evidence must be visible after each verification decision? | |
| Which dashboard or review signal would cause us to pause the pilot? | |
| Who owns policy updates, evidence review, exception handling, and rollback decisions? | |
| What must be true before we add a second workflow? |
Review rubric
A strong capstone answer reads like a controlled experiment. It does not promise that Mandaitor solves every governance issue immediately, and it does not treat successful tool execution as proof of safe authority. It shows that the team understands the difference between authentication, delegated authority, runtime verification, evidence, and operational readiness.
| Rating | What the answer demonstrates |
|---|---|
| Needs refinement | The workflow is broad, roles are unclear, or the evidence cannot explain why a decision was made. |
| Pilot-ready | The workflow is bounded, the verification examples cover allow/deny/escalate, and reviewers can inspect the evidence path. |
| Expansion-ready | The first pilot has stable ownership, repeatable evidence review, clear dashboard signals, and documented criteria for adding another workflow. |
Why should the first Mandaitor pilot focus on one bounded workflow instead of every agentic action at once?
- Because a narrow pilot makes authority boundaries, verification decisions, evidence quality, and ownership easier to test before expansion.
- Because governance only matters after a product is already in production.
- Because agents can be trusted automatically once they authenticate.
Reveal answer
A bounded pilot creates a complete loop that can be understood, verified, reviewed, and improved. It exposes whether the team can define authority, enforce policy, inspect evidence, and operate the workflow safely before adding more actions or higher-risk processes.
Save your learning progress
Mark this lesson as complete to update the Academy overview without requiring an account.