User Journey: Run the public sources

"I want to know whether the rates we use are actually arriving, and to do something about it when they are not — accept a publisher's terms, pause one that costs too much, fetch a range we missed — without asking someone to run a command." The journey is done when the person has read the state of every public publisher, has acted on each one that needed it, and knows which feeds started from which published value.

The actor is the system administrator, because every public publisher is system data and a person accepts its terms on the system's behalf. Reading the publishers and the fixings needs marketdata::publishers:read and marketdata::market_fixings:read. Accepting or declining terms needs marketdata::publishers:accept_terms. Pausing, resuming and starting a backfill need a permission the server does not define yet, and deleting a publisher's fixings needs a delete permission the server does not define yet.

The trigger is one of four events. A publisher's terms change, and the person must accept them again or stop using its data. A fixing a desk needs is late, and the person looks for the cause. A pair or a publisher is new, and the person checks that its data arrives before anyone builds on it. A bill or a coverage review says a publisher is not worth its cost, and the person pauses it.

The journey starts at Market data, then Public rates, and ends when the person leaves the screen. A person who came from a feed's page returns there, because that page carries the value a run started from.

The screen is the record screen shape of the Record screen standard: a list of publishers, one publisher's page with its fixings, and a pair comparison. This journey adds the operational facts the screen already has data for and the two acts the architecture can carry.

1. Read the publishers. The person opens Market data and then Official rates. The system lists every public publisher that has terms: its name, the kind of publisher it is, whether its terms are accepted at the version shown, the items it serves, and its freshness. The route that reaches it, Frankfurter or later another, is on the adapter's health, not on the row.
2. Read the freshness. For each publisher the row states the last fixing's date, the time it was received, and whether the next expected publication is late. A publisher that has never had a fixing says so in words rather than showing a blank cell.
3. Tell the three failures apart. An adapter that is not serving, a publisher whose next publication is late, and a publisher that has never had a fixing read as three different states, each with the sentence that says what to do. The adapter's state, heartbeat and the ids it refuses come from the adapter status read the marketdata service already answers.
4. Accept or decline terms. The person opens a publisher whose terms are not accepted, reads the terms page and the credit it asks for, and accepts them at the version shown or declines. The service refuses an acceptance of a version that changed since the person read it, and the screen reloads and says so. The service fetches a publisher only after someone accepts its terms.
5. Read a publisher's fixings. The person opens the publisher and reads its series as a table and a chart over a window, one item at a time. Each value keeps the publisher's own id of the item and the time it was received.
6. Compare a pair. The person compares one pair across every publisher, as published, inverted, or crossed through the publisher's base, and the screen names the route of each value.
7. Pause and resume. The person pauses a publisher that is not worth its cost, and the system stops demanding its items. The fixings the publisher already published stay, and a feed that started from one keeps its start. Resume restores the demand. Each act is audited with an actor and a reason.
8. Force a fetch. The person opens the Fetch tab, picks today, yesterday or a range, all publishers or one, one pair or every pair, and asks for it. The service asks the adapters for exactly that, and the screen says the fetch is running and names the days it has fetched. A range that overlaps what the store holds adds nothing, because the store skips a fixing it already has.
9. Delete the fixings of a publisher whose terms withdrew storage. When a new terms version withdraws permission to store, the person deletes that publisher's fixings. The deletion records who did it and when, and the screen says which feeds started from a value that is now gone.
10. See where a feed started. From a synthetic feed's page the person reads the publisher, the item, the value as published and the time it was received of the fixing the run started from. The screen links back to this one.
11. See who changed it. The person opens the publisher's history: terms acceptances and declines, pauses and resumes, backfills and deletions, each with its actor and its reason.
12. Read the availability of one underlying. The person opens the Availability tab and picks a pair. The system lists each publisher that fixes the pair, with the first and last date it holds, the count, and the gaps. A publisher whose terms are not accepted shows as a row with no data and the reason.
13. Compare the publishers. The person opens the Compare tab for the same pair. The system draws each publisher's fixing over the window on one axis, the difference of each against the others in basis points, and the largest disagreement. It names the publisher whose value is furthest from the rest.
14. Read one publisher's history for one underlying. The person opens the publisher and picks the pair. The system shows the fixings over the window, the corrections, the days with no value, and the feeds that started from a value, with the value each took.
15. Read a publisher's configuration. The person opens the publisher's record page. The Details tab shows its name, kind, terms page, credit, credential reference and whether storage is allowed. The History tab is the shared timeline: every version and every acceptance, with the person and the time.
16. Leave. The person returns to Market data.

Setup and reading are two jobs for two people. Connectivity configures who publishes, who supplies, and how a feed is delivered. Public rates reads the values and says whether they are arriving. A person moves between them through a link on the publisher's page and on the feed's page.

The journey uses the words of the model. Each word has one meaning and one example.

The schedule is not the reading screen's. The scheduler runs a job for each feed on the publisher's rhythm for the end_of_day service; a real_time feed is demand driven. The Fetch tab sends the same request on demand, so one request serves the schedule and the person.

Two screens. Connectivity draws the delivery tree: supplier → session → feed, with the adapter on the session. Public rates draws the publishers with a freshness line and the feed that serves each class, the publisher page, the fetch range dialog, and a pause dialog that names what stops and what stays.

Every step is judged against what the standard draws today, and what the server answers today.

• Pause and resume a publisher. The download follows demand, so the act is either a demand change or a new publisher state. The decision is Decide how a publisher is paused. Until it exists the screen states that a publisher is fetched because the system party subscribes to it, and names the subscription.
• A fetch on demand and on a schedule. The adapter contract carries announce, demand, tick and heartbeat, and no fetch request. One request must serve the scheduler's job and the screen's Fetch tab, and the design is Design the refresh request the scheduler and the screen share. Until it exists the screen offers only the window the service fetches on its own.
• Deleting a publisher's fixings. The durable table is never deleted today, because the terms in force when a value was stored keep it. A terms version that withdraws storage needs an act with an actor, which Decide how a publisher is paused carries alongside the pause.
• Freshness in one read. The fixings read answers one item at a time, so the screen reads the latest fixing of every item a publisher serves. A single read that answers the last fixing of each series would make the row cheap; until then the screen reads the publisher's best item and says which one it read. The row and the three states are Show each publisher's freshness and its adapter's health.

• Manage market data subscriptions — the party's view of the same publishers: which ones a party takes and what each costs.
• Keep the market data sources running — the sources under the publishers, their state and their routes.
• Watch the market and clear its exceptions — the quotes a subscription delivers, and the ones that failed.
• Author an FX price feed — the feed that starts from a fixing, and the choice of which items it may start from.

• Public publishers publish daily fixings through a supplier session — the publishers, the suppliers, the sessions, the store and the reader behind this screen.
• Market Data Architecture — the structure note that orders the market data cluster.
• Spot rate governance — why an official rate is not the live market, and who approves a rate set.
• The tick ingest pipeline — how a published value reaches the durable store.
• A source tick is stored once and entitled when it is read — the party entitlement a fixing read carries.

• Prototypes — the inventory the prototype answers to.
• Calibrate the synthetic ticks from free public sources — the task that made a feed start from a fixing and showed where it started.
• How do I add a PlantUML diagram? — how the wireframe above was drawn.