The acme_demo profile is ten ordered steps, and the steps are data

Table of Contents

1. Summary

A tenant is built from a starting point, and a starting point is an ordered list of steps held as rows. The one the demonstration uses is acme_demo: eleven steps that install the system data, publish the system's curves, publish the tenant's own datasets, import the LEI hierarchy, provision the parties, load the staff, set their passwords, attach their pictures, subscribe every party to its market data provider, schedule the reports each party publishes and generate a trade population. Nothing in that list is code. A variant changes a row's arguments, and a tenant that wants a thinner book or a different feed changes a value rather than a build.

2. Detail

2.1. The fifteen steps

Order Step What it creates
5 system_provision publishes the system's own datasets into the system tenant, which every tenant reads as an overlay
6 publish_system_curves bootstraps and publishes each IR curve the system tenant holds a config for, from its synthetic quotes. These are the system's reference set: no tenant prices from them
8 start_auto_approval turns the tenant's auto-approval on, so the publishes below close without a person. Every screen says so while it is on
10 publish_bundle the base bundle, the marketdata.reference_vintage_2026_05_05 bundle, the GLEIF counterparty set at the profile's chosen size, and the ORE counterparty aliases
15 build_calendars the business days of every calendar a currency or a pair convention names, to 2060
20 import_lei_hierarchy the Acme LEI hierarchy, whose root is 9695ACMEGROUP0000030, as the tenant's four parties
30 provision_party each party's own reference data, from the party_essentials bundle
40 load_staff the staff of each of the four entities: 73 accounts, each with its role, job title, manager, business unit and contact record
45 set_staff_passwords one development password for every staff account, set through the server's own password API
50 attach_photos each account's picture and each party's logo, copied from the system tenant's templates
60 subscribe_market_data one subscription and one route for every party, at the provider and source the row names
65 publish_party_curves each entity's own copy of the 20 curve blueprints, bootstrapped from the quotes its own subscriptions deliver and published under auto-approval
70 schedule_reports a scheduler job and a run grant for every report definition each party publishes whose schedule is a real cron, so the catalogue ticks without a person acting
80 generate_trades one trade population per trading entity, each booked into that entity's own book by its own traders
9000 end_auto_approval turns auto-approval off after every other step, so people decide from here on

The run then closes with complete_provisioning, which the workflow adds rather than the profile: it hands the tenant to its own administrator, clears the bootstrap flag, and declares the run done.

2.2. Why the order is what it is

Five dependencies decide it, and all but the curves have a failure behind them.

  • The system data comes first, because a tenant is built on a system that already makes sense: a coding scheme validator resolves its scheme in the system tenant, and a template image is read from there.
  • The system's curves come straight after the system data, because their quotes come from the feeds that data starts. The step runs beside the tenant's own setup rather than before it, and it asks again for a curve whose quotes have not arrived yet, for up to two minutes.
  • The staff come after the parties, and the passwords and pictures after the staff, because a password or a picture names an account that must already exist. Attaching a picture to an account that is not there is the step failure that taught this order.
  • The market data comes after the staff and the parties, because the step acts as a party and writes a party's rows: a subscription written before the party exists has nothing to hang from.
  • The schedule comes last but for the trades, because it reads what the earlier steps published: a party's report definitions arrive with the bundles the staff step names, and a schedule names the party whose consent its runs act under. A step that ran before the definitions existed would schedule nothing and say nothing.

2.3. Which parts are data, and which are code

A person wants They change
A different counterparty set size the profile's counterparty_size parameter
A different feed for one party the party's row in subscribe_market_data
Fewer trades, another book, another asset class a value in the generate_trades config
A report scheduled, or left on demand its definition's schedule, in the catalogue the party publishes
Another staff population, another office the seeder's OFFICES table, then regenerate the datasets

The last row is the boundary: the staff, the business units, the portfolios and the books are generated by the Acme seeder rather than written by hand, so a new office is a table entry and a regeneration. The seed profile names the datasets and the arguments; the seeder produces their contents. A change to the shape of the organisation is a seeder change and a regeneration, and a change to what the profile does with it is a value.

2.4. What the profile leaves to the system

The profile publishes a set of datasets and follows the workflow that publishes them, but it writes no catalogue row, no role and no permission. The providers, the sources, the vendor instruments and the mappings belong to the system bundle, and the roles and the permissions belong to the IAM seeds. A tenant is therefore a reader of both, and a fault in either shows up in every tenant at once. See A system bundle installs the catalogue and the simulator installs its own universe and the permission matrix.

2.5. The staff the profile now loads

Seventy-three staff accounts, of whom 31 hold the trading role, 16 the operations role, 4 the controller role and 4 the finance role, with the rest split between the viewer, sales and support roles. The controller and finance accounts exist for the approval parts of the same name: before them, no seeded person held either part's decide permission, so a book change could only be answered by a tenant administrator. The approval model says who decides what, and the permission matrix says which role each function holds.

3. What this note does not cover

The two rows the market data step writes are the subscription and the route. The steps a person sees while the run happens, and the screens that report it, belong to New tenant.

4. See also

Emacs 29.3 (Org mode 9.6.15)