The Acme demonstration's market data and its approvals

The Acme tenant is the platform's fully populated demonstration: four legal entities, 73 staff, a market data subscription each, a trade population and the approval requests the trades raise. Two questions about it are hard to answer from the code, and this note orders the pages that answer them. First, where does an Acme party's market data come from, and who installs it. Second, who may decide the approvals the demonstration raises, and why the person who decides is never the person who asked.

The cluster is six pages. They are read in the order below, because each one assumes the vocabulary of the one before it: the providers first, then the catalogue they belong to, then the two rows that tie a party to a provider, then the profile that writes those rows, and only then the two pages about people — the roles they hold and the decisions those roles let them take. A reader who wants only the approval side can start at section five.

Read these three to be able to say, for any value on an Acme screen, which provider produced it, which source delivered it, and which row tied the party to that source.

1. Each Acme party takes one provider, and a simulated source serves it. Seven providers, six sources, and which of them each of the four entities takes. After this you can say why London reads demo and New York lseg.
2. The Acme catalogue is installed by the bundle, and the feeds generate the series. The 447 instruments, 447 mappings and 24 rate card components the system bundle installs, the feed collections that then run, and the 341 series they produce. After this you can say what a tenant may and may not write.
3. A subscription names the provider and the route names the source. The two rows, the rights on them, the flow a demand follows to a tick, and who may change them. This page carries the demand and subscription diagram. After this you can trace a run's market data end to end.

Read this one to be able to rebuild the tenant or to change one of its choices without touching code.

1. The acme_demo profile is nine ordered steps, and the steps are data. The nine steps in order, the dependency each order protects, and which of the demonstration's facts a person can change by editing a value. After this you can say what a variant of the demonstration would cost.

Read these two to be able to answer "who can do this" for any operation in the tenant, and "who decides this request" for any approval.

1. A persona may act because of its role, and no other reason. The role each Acme persona holds, the permission matrix by role, and the chain from account to role to permission. This page carries the role and permission diagram. After this you can place any persona in the matrix.
2. An Acme approval is decided by a permitted person who did not raise it. The four kinds, the four parts, their decide permissions, the personas that now hold them, the requester-not-decider rule, and the five places the journeys and the seeds disagree. This page carries the approval diagram. After this you can say who decides any request the demonstration raises, and what it still cannot decide.

The general subject is not here. The market data service, its adapters and its pipeline are Market Data Architecture; the approval record, its queue and its lifecycle are Approval requests; the role model is Role-Based Access Control. These pages are what an instance of all three looks like once a tenant is provisioned, and they link back to the general pages rather than restating them.

The demonstration's business content is elsewhere too. The books and desks are Book's subject, the trades are Trade's, and the screens a person uses are the user journeys.

• Knowledge — the index of all knowledge notes.
• Market Data Architecture — completes: the general subject this cluster instantiates.
• Approval requests — completes: the record these decisions are written to.
• Role-Based Access Control — completes: the model the matrix reads.
• Zettelkasten — exemplifies: the atomic-note method that shapes each page of this cluster.
• Market data journeys — answers: the journeys a party's market data is managed through.
• Setup journeys — answers: the journey that builds a tenant.