Task: Create the role-request journey

A journey document that answers the question registration leaves open. Registration gives a new account one default role; a person who needs more has today no way to ask, because Change someone's access is an administrator acting on somebody else's record and Ask for more access does not exist. The journey records how a person asks, who answers, what they see while they wait, and what closes the request.

It is deliberately its own journey and not a step of Sign up. A registration ends at a confirmation; a role request may be made at any time afterwards, it may be refused, and it is answered by somebody else. Folding it into the door would make one journey with two actors and two endings.

• The journey document exists in the Access group and is named for the person's goal rather than for the entity, following Document type: user_journey.
• It carries every required section: goal, actor and trigger, steps, screens and wireframes, entities composed, operations and messages, what is missing, and related journeys.
• It names who answers the request, what the requester sees while they wait, how a refusal is stated, and what closes the request.
• It states whether the request holds server-side state. A request that waits on a person is a workflow instance; one that is answered in the same session is not.
• The Access hub links it, and Sign up and Know what I may do link to it under * Related journeys*.
• Every operation it needs is marked exists, partial or missing against the generated protocol.

1. Start from the person's goal: "I cannot do my job with the access I have."
2. Decide the shape with the product owner: a request that an administrator approves, or a request that self-service grants from a catalogue the tenant allows. The existing subjects bound what is possible: iam.v1.roles.assign needs iam::roles:assign and is an administrator's write, so a self-service grant is new server work.
3. Write the steps the person takes, then the steps the approver takes, as one journey with two actors or two journeys if that is what the design says.
4. Draw the wireframe, name the entities and the fields, and build the coverage table.
5. Record the gaps, including how the requester is told the answer and whether the account can hold a pending request at all.
6. Wire the document into the Access group hub and into the related journeys of the pages around it.

• The product owner's steer while reviewing the registration prototype: "we will give users some kind of default role. how does one ask for additional roles? add a task to create a journey to allow users to request changes to their roles. this can be separate from the sign up journey to make things easier."
• The product owner's decision on the shape (2026-09-30): a member asks and a tenant administrator approves, the four-eyes shape. A self-service grant from a tenant-approved catalogue was the alternative and was not taken. The decision is what makes the request wait on a person, and therefore what makes its state server-side.
• The default role itself is settled in Registration and Onboarding Defaults: a flag on the role row, nominated by the tenant administrator. This task owns the answer to "and what if it is not enough?".
• The implementation is not this task's. It lands in the Access group's story, which owns those screens; this task produces the design the implementation is built from.

Manual QA scenarios (scaffolded via compass add test_scenario) that verify this task. Link new ones here as they're created; the scenario doc itself links back via its "Verifies task" field.

The journey is Ask for more access, in the Access group, with one wireframe per actor.

• The shape. The product owner chose a request that a tenant administrator approves. A self-service grant from a tenant-approved catalogue was the alternative, and it was not taken.
• One journey, two actors. The request is one record with one lifecycle, and each actor owns one end of it. The screens stay apart, and the administrator's unprompted version of the same write stays Change someone's access.
• The state. A request waits on a person, so the document states that its state is a workflow instance in ores.workflow. That is the rule The entry journeys and the user_journey contract already state, applied to a request rather than to a provisioning run.
• The coverage. Five of the ten subjects the journey needs exist: iam.v1.roles.by-account, .list and .permissions for the reads, iam.v1.roles.assign for the grant, and workflow.v1.instances.steps for the progress. The five request subjects are missing. The page records seven gaps in all, of which the subject set and the engine's inability to wait on a person are the two that block the design; the other five are the self-approval guard, a flag for what may be asked for, notification, a joined request read, and a review window.
• Wired in. The Access hub lists the journey and describes it, and Sign up, Know what I may do and Change someone's access each link to it under * Related journeys*.
• A defect in the acceptance. The criterion names 0010510B as Know what I may do; that id is Register a service account. The link was added to Know what I may do, which is the journey the criterion means.