One mandate, one request, one explained decision
The easiest idea to show is a mandate: a person tells software which task it may perform, with what budget, for how long, and when to ask for confirmation.
- The person sets the boundaries. Agent, purpose, amount, duration, and limits.
- The agent presents a request. The request shows who is acting, what it wants to do, and why.
- A rule produces an outcome. Allowed, requires approval, or blocked—with a readable reason.
- The person stays in control. They can understand the outcome; pause and revoke are design principles, not live enforcement.
An example for discussion
A fictional mandate: a €300 budget for work equipment, valid for 30 days; purchases above €100 need the person’s approval. Show one €48 example request within the rule and one €129 request that requires attention or falls outside the mandate.
This is a demo concept, not a payment. The data and merchant are fictional. No agent, card, account, provider, or real purchase is connected; the result does not authorize or block real transactions.
The proof we care about
In a test, can someone tell who issued the mandate, what is allowed, and why the other request is stopped? Can they distinguish a policy outcome from a payment? This measures comprehension, not product-market fit.