Provisioning operations and the plan

A starting point is the unit of the plan, and adding one is adding a row rather than changing code: the starting point orders the operations the run performs, declares the parameter schema its form is built from, and prefills the tenant details the run creates.

The plan has three carriers. Operations are the ordered steps a starting point names, and a run performs each once and expects it to be idempotent. Parameters state what the form asks for: a name, a label, a data type among string, integer, boolean and choice, the choices a choice offers, a default value, whether a person must supply it, and the order the form shows it in. Prefilled tenant details sit on the starting point itself.

Two starting points ship with the platform, and they show the split. The first is offered first, prefills no tenant detail, and takes a root LEI and the size of the counterparty set as form parameters; it orders publishing a bundle, importing a legal-entity hierarchy and provisioning a party. The second prefills the Acme identity and takes no form input, because its root LEI arrives as the argument of its import operation; it orders publishing a bundle, importing a legal-entity hierarchy, provisioning a party, loading staff, attaching images and starting market feeds. A starting point states the values it can; a parameter states the values a person must supply.

The step protocol fixes the catalogue of operations in code, because an operation is a code change rather than a row. The catalogue is publishing a bundle, importing a legal-entity hierarchy, provisioning a party, loading staff, attaching images, starting market feeds, and the completing operation that marks the tenant ready. The contract refuses an operation outside that catalogue.

The engine dispatches every operation of a run to one subject, iam.v1.ops.provision_tenant_step. One subject serves every operation, because the engine persists an operation's name and subject while the payload names the operation to perform. ores.iam serves that subject, so ores.iam owns the orchestration and a new operation needs no other component to change. The definition appends the completing operation after the starting point's operations, so "the tenant is ready" is an operation rather than a property of the definition.

A bundle is a named collection of datasets designed to work together. A member links a bundle to a dataset and states the order the bundle shows it in and whether it is optional. A dataset is the central registry of published data, and each dataset names the artefact type it publishes as.

An artefact type names the artefact a dataset stages, the artefact it publishes as, and the target subject that carries it. A publication resolves a dataset's artefact type and copies that subject into the workflow request verbatim, so the rows decide which service publishes a dataset.

The contract fixes which values a caller may vary in a publication, and each value names a data value the publisher may vary and nothing else. A bundle publication may opt the bundle's optional datasets in, supply the root LEI an LEI import starts from, scope the publication to a party, and qualify the published values by tier and jurisdiction. A plain dataset publication scopes to a party alone.

The party plan is shared, and it lists the publications a party provisioning runs. Each step names the bundle it publishes and the label it shows, and nothing more. The plan carries no value such as a root LEI; such a value arrives as a starting-point parameter or as an operation's argument, which keeps the party plan a list of bundles.

Reference data every party needs, the instrument conventions and the CRM topology, travels in the party_essentials bundle. The generic report set travels apart from it, in the party_reporting bundle: the tiered report definitions and the run settings they resolve. A starting point for parties that share one report design names both bundles. A starting point that gives each party its own report design names only party_essentials and publishes each party's own report definitions dataset through that party's bundle. The Acme demo does this, because a real group's legal entities do not run the same reports. The tier and jurisdiction qualifiers cannot express such a design, because the entities share a tier and differ in the desks they run.

A report configuration document is a header and the rows that reference it: a pricing engines document, a today's market document, a curve configuration. A dataset stages the whole document, one staging table for each live table. One shared publish copies the staged rows into the live tables for the party a publish names, and a thin function for each document says which tables it spans and in which order.

Every party gets the same staged document, and a live id is unique in a tenant, so the publish maps a staged id to a live id that depends on the party. The map depends on the staged id and the party and nothing else. A reference between two rows of the document therefore needs no lookup, and a republish finds the rows it wrote. The publish also writes the reporting configuration that the header names, because a definition binds the reporting configuration and the owner of the document finds the document through it.

A definition binds its documents by name. The dataset that stages the definitions stages the bindings beside them, each naming a definition and a document, and the definitions publish resolves the names for the party. The documents are therefore published before the definitions, and the definitions dataset declares its dependency on them. A binding to a document that does not exist is not written and is counted as skipped. A binding to the conventions creates the conventions configuration it names, because the conventions have no document of their own.

The run settings of a risk report are one more document of this kind, a header with no children. Reports that run the same analytics over the same scope in the same currency share one set of run settings, so a party holds far fewer sets than definitions. The dataset that stages them names the portfolio each set reads, and the publish resolves that name to the portfolio the party holds. A name that matches no portfolio refuses the publish, because a set that reads no books fails every run that binds it. The run document that ORE reads is not stored: the export builds it from the run settings and the bindings of the definition.