User Journey: Name a convention set

"No set on the list fits the Dubai swaps desk. I want one set, with a name that says what it is and a purpose a reader understands, and I want a report to be able to choose it."

The journey is done when a request for the set is waiting for Market Risk, and the person can read its name, purpose, description and the document it names for each kind. The set exists for a report to choose only after the request is approved.

This is a different job from Author a convention for a kind. That journey writes one document of one kind. This journey writes no term. It groups documents that already exist, one per kind, under a name.

The actor is the person who owns the market terms: a market risk owner, or a tenant administrator acting for them. Market Risk is the function that decides a convention change (Book types and the controls on each), so the maker and the decider are two different people.

The trigger is a report author who found no set that fits. The report prototypes (Create a report and Change what a report runs) draw a link out to this screen for that case. A person can also start here from the list of sets, with no report in mind.

The journey starts on the list of sets and ends when the request is raised and visible under My requests. It does not bind the set to a report: that is the act of the report author.

The journey keeps server state. A request waits on a second person, and the request carries the state. The person can leave the screen after the request is raised.

1. Read the sets that exist. The system lists every set with its name, its purpose, how many of the 26 kinds it covers and how many report definitions use it. A system holds few sets, so one page holds all of them. The person confirms that no set fits. Four conventions configurations exist today, by name and type, and none of them carries a purpose or a kind.
2. Describe the set. The person writes a name, a purpose and a description. The three are stored. The system refuses a name that another set holds, and the screen says so beside the field.
3. Choose a document for each kind. For each kind the set covers, the person picks one document from that kind's list. A kind left out is not covered. The screen shows the document's terms in words beside its key, because the key alone does not say what a document states. A kind of 320 documents is read by the person, because the filter takes the key only; see Find a convention by its terms.
4. Review the reach. The system shows how many kinds the set covers, which documents it names, and which report definitions would change if a report author moved them to this set. It states which kinds are tenant kinds. A document of a tenant kind is read by every party of the tenant, so the set reaches further than the party that made it.
5. Ask for approval. The person raises one request for the set. The request names Market Risk as the decider and carries the whole set as the pending change. The person cannot decide their own request.
6. Read it back as waiting. The system shows the request under My requests with its state. It states what the request did not do: the set does not exist yet, and no report can choose it.
7. Leave, or go on. The person returns to the list of sets. The decision is the journey Decide a convention change. The report author's choice is in the report prototypes.

One screen of five panels: the list of sets, the description, the document for each kind, the review of the reach, and the waiting request. The rail runs in order, and the last step cannot be returned past.

The screen draws a set as a name, a purpose and a list of documents. It does not draw the terms as editable fields, because a set holds no term. It shows the terms of each document in words so that the person can tell the documents apart.

A clickable prototype draws this journey: prototype, with its design note name-a-convention-set. It opens with no build and reads mock data only. The page marks each server gap this journey names.

reporting.v1.configurations.put exists, and it writes a name, a type code and an owning component. It cannot carry a purpose or a kind.

1. No set has a purpose or a description. The configuration holds a name, a type code and an owning component. The story Name the convention sets a report chooses records the gap and has not started the schema work.
2. No set names a document for a kind. A configuration has no children, so it binds 26 kinds in name only. A set needs one row for each covered kind with the key of one document. Until the row exists, a run reads the whole party document and not the set.
3. No default marker. The same gap blocks See the conventions a party uses and Change the convention a party uses for one kind. A set's child rows would be the first place a choice is written, and they would need an owner.
4. No approval kind for a set. iam.role_grant, refdata.book_change and refdata.counterparty_change are the only kinds seeded. Market Risk has a deciding part and a permission, inbox::approvals:decide_market_risk, and no kind names them for a convention. The controls note states the rule for a new convention or a change of its terms. It does not state a rule for a set, and the product owner confirms that rule.
5. A request holds no pending set. A request carries a reason and a kind. It does not carry the change, and nothing applies the change when the last decider approves.
6. The publish carries no correction. A re-publish does nothing where a row exists for 25 of the 26 kinds. A set that names a corrected document cannot rely on the publish to bring the correction to a tenant.
7. A set that names a tenant kind reaches every party. The screen can say so. Nothing in the server reports the scope.
8. No BFF route serves a set. The journey adds one, for example POST /api/refdata/convention-sets, which validates the name, reads the named documents and raises the request.

• Author a convention for a kind — the person needs a document that no list holds, before a set can name it
• Find a convention by its terms — the search that picks a document for a kind
• Decide a convention change — the second person's half of step 5
• See the conventions a party uses — read which document a run takes after the set exists
• Change the convention a party uses for one kind — correct a document a set names
• Reporting journeys — the report author who chooses the set

• Conventions journeys — the group this journey belongs to
• Name the convention sets a report chooses — the decision that conventions are named sets
• Book types and the controls on each — who decides a convention change
• User Journeys — the index

• User Journey Extraction Standard — the checklist this journey is written against
• Document type: user_journey — the sections this page fills