How to read a pattern
Every card in the library follows the same sections in the same order. This page walks through them one at a time, with a published card as the example throughout.
Every pattern is built from the same parts, in the same order, so a reader who knows one card can scan all the others. The excerpts on this page come from one published card, Fine-grained scope negotiation, which lets a person authorize an agent to do exactly one bounded thing, such as lodge a tax return.
A pattern belongs to a territory: one of nine areas where AI agents change how users and government deal with each other. The territory page states the shared condition its patterns respond to, as a policy challenge and a design challenge; each pattern inside it works on that challenge from one angle. Everything else lives on the card.
The name and the framing
A card opens with its identifier, its name, and a maturity badge. The identifier places it: card 2.1 is the first pattern in Territory 2, Delegation & Authorization. The name says what the pattern is in plain words. The short passage under the name is the framing: what the pattern concerns and the ground it covers, in a sentence or two. Everything that follows expands on it.
Letting a user grant an agent exactly one bounded permission (lodge this return, touch nothing else) in a form the service can enforce. If the agent misbehaves, the harm stops at the boundary of the one permission the user granted.
The impact of agents
The card then states its own problem: the condition it expects as the use of AI agents grows, and why that condition troubles good governance. The section reads forward, describing where practice is heading rather than a present complaint, and it is written from the government system's point of view. The rest of the card responds to what this section names.
As users authorize agents to act in government services, they will need to grant a single, bounded permission, such as "submit my annual tax return for the 2025 financial year but not access my superannuation records," rather than a coarse read-or-write grant. Conventional authorization scopes are blunt strings that cannot carry that nuance, so the difficulty is expressing and granting authority narrow enough to bound one transaction.
What must be verified
This is the confidence someone needs before they can rely on the interaction: an agency acting on a submission, a person depending on an agent that acts for them. The section names what government must be able to verify in this pattern's situation, and the policy scope it works within when it asks for it. It stops at the requirement; the mechanism that delivers it appears under Response surface.
An agency needs each grant to be inspectable enough to confirm, at the point the agent acts, that it did exactly what the user authorized and no more. The service defining the scope catalog must enforce that boundary at the point the agent acts.
Protecting access
A requirement that raises confidence can also close the path for a person who can't meet it, and a new control can shut people out even where nothing is demanded of them. This section names who is at risk of losing the outcome, what form the loss takes, and what keeps the path open. It's held to the same standard of specificity as the verification section on every card: named groups, a concrete consequence, a concrete remedy.
The scope screen risks excluding users with low digital literacy, low reading confidence, or little time. A long list of granular permissions can deter them, or they approve everything unread. Either way, they end up with a broader grant than they intended. Whoever can't set up the delegation alone needs a supported route, or this pattern's protection never reaches them. Keep the path open with a plain-language summary on every scope, a pre-selected standard bundle as the default fast path, and an assisted-digital route (phone or in-person) for users who can't complete the grant alone. The scope-toggle consent screen must let each permission be operated by keyboard and assistive technology, with its granted-or-withheld state announced, not only shown.
Response surface
The response surface is the designed response the pattern proposes. A surface here is broader than a screen: it can be a moment in an interaction, such as a consent screen; an arrangement of a service, such as a supported phone route; or a policy setting, such as where a burden of proof falls. A label on the section names which of those levels the response sits at.
Some cards carry a working example that can be operated on the page (the example card holds a working consent screen). Others describe the response as a brief for one to be built. Some record no response yet, and the empty section is information too: it marks a challenge no one has answered.
A consent screen that renders a scope object as a plain-language permission a user can grant or narrow, with a sensible default bundle.
Maturity
Maturity records how developed the response is, at one of three fixed levels. Established means it runs in production in comparable government or regulated settings. Emerging means it exists in pilots, standards, or limited deployments. Frontier means it has been proposed or demonstrated, and no one yet operates it at scale for this purpose. The level is a claim about evidence rather than importance, so each one is earned by a citation.
Where parts of one response sit at different levels, the card shows a ladder, one level per part, instead of a single badge. The example card is one of these: the permission format is proven elsewhere, and its use in government services is not.
Precedents, and what carries over
Most cards rest on precedent: somewhere the response, or something near it, has already run, cited with the jurisdiction and the year. The card then assesses what carries over to agent use: how far that precedent moves into the situation the card describes, and the gap where it doesn't.
RAR's JSON authorization objects are directly transferable to government service
scoping. A government service catalog could define authorization_details types
for each service action (lodge, view, amend, withdraw). GNAP's async interaction
model suits agents that operate without a browser session. Open Finance UAE shows the
structures work in production in the financial sector. The remaining gap is
government-side: no government currently publishes a machine-readable catalog of
actions that could populate these structures.
Where things go wrong
Near the foot, the card names the concrete failure that follows when the challenge goes unanswered, and the response that limits it. Some cards instead draw a scope limit — naming plainly where the pattern does not reach.
Without scoping, the failure is an over-broad grant: an agent given general access reaches far beyond its task. Scoped, revocable grants narrow the blast radius, so an agent authorized only to lodge the 2025 return cannot reach superannuation or trigger a debt-recovery action. A service that defines only coarse-grained scopes can still call a grant 'narrow' while it reaches far beyond the task described, since the plain-language summary is only as honest as the scope catalog behind it.
Sources, and the foot of the card
Every precedent and factual claim on a card traces to a listed source. Each entry names the instrument or case, then says what it establishes, with the link inline.
Up to three lists can follow the sections. "Reads alongside" names the patterns this one depends on. "See also" points to kindred patterns — ones that answer a neighboring question or serve the same process at a different moment — without implying a dependency. "Seen in practice" links any case study that bears on the card. Beyond those, each card stands alone: none assumes you have read another.