A subscription names the provider and the route names the source

The separation is the design, not a normalisation accident. A subscription names a provider and never a source, because the licence is with the provider and because the same instrument must map the same way whichever source serves it; A party takes a provider's feeds through a subscription states it. A route names one source per provider for the party, because two sources for one provider would deliver the same series twice; A party routes to exactly one source for each provider states it. The rights are display, non-display and derived, modelled on the subscription.

The step is subscribe_market_data, the eighth step of the profile, and its own arguments name one provider and one source as the default and then the parties that differ from it. In the shipped profile the default is bloomberg through bloomberg-a, which is exactly what the group, Hong Kong and the system party take. London and New York keep their own vendors and take Bloomberg as well, because only Bloomberg quotes the IR ladders and USD spots of all 20 funding currencies, and each party bootstraps its own funding curves. A party the step does not name takes the default, so a fifth entity added to the tenant is subscribed without the profile changing. The step's arguments are its own.

The step pages the tenant's parties, matches each against the rows it names by id or by full name, and writes the two rows for every party on the page. Three consequences follow.

• A party the step names twice takes both providers, one subscription and one route for each. A name the tenant does not hold is a failure: the step refuses rather than subscribing three of four parties.
• The rows are written idempotently. Re-running the profile looks for a subscription of that party and provider, and a route of that party and provider, and writes only what is missing, so a second run changes nothing.
• A subscription the party administrator later narrows is not widened by a second run of the profile, because the read finds the row. Whether the whole profile should overwrite a party's choices is a question the profile and the journey answer differently; see What the journeys leave undecided.

Source: acme_market_data_demand_and_subscription.puml. Regenerate with plantuml -tpng doc/knowledge/demo/acme_market_data_demand_and_subscription.puml.

A run does not ask a party for its data. It names an item and an as-of, and the service resolves the rest: the provider that carries the item, the party's route to a source of that provider, the vendor id the source announces, and then the generator that produces it. The tick comes back on the party's own stream, stored under the party, and the delivery is counted against the party, the provider and the item so that the bill follows the use. A simulated source carries a rate card of the same shape as a live one, so the demonstration shows the bill the same use would cost on a live source; A rate card on the source turns usage into a bill the platform shares states the general case.

The journey names the party administrator as the actor who changes a subscription, and no seeded role is called that: the write sits with Operations, which is the function that maintains the sources and the routes in this deployment. Manage market data subscriptions is the journey, and the permission matrix holds the whole table by role.