Skip to content

Roles

A plugin's roles decide what it may do on the bus: the operations it may call, the queries it may ask and the deliveries it hears. This page is each role's entry: the person or desk whose job it does (its persona), its function and duties, what it leaves to which other role, and what it holds at contract v24. Then the principles a plugin must fit, and the method that turns an idea for a plugin into the least roles it needs, with worked examples.

Roles are fixed, and nobody can change a role's grants, not even for one plugin. So an idea is mapped to the least roles that hold what it needs, or reshaped until it fits. What a plugin is and how its grants are made is in Plugins, roles and grants.

Every part of this page is generated from boundaries/roles.json in meridian-schema, which an agent can read as it is; /llms.txt lists this page's sections and every operation, for an agent to start from.

Proposed entries

The entries for reference are proposed: its persona, function, duties and what it leaves to others may still be revised. Its scope is generated from the contract, and is exact.

The 14 roles

Role Function Persona At contract v24
connectivity Venue connectivity, an edge the desk's connection to a broker or venue Publishes 10, reads 12, hears 5
compliance Pre- and post-trade rules the compliance officer Publishes 5, reads 21, hears 15
custody Custodial data, an edge the operations staff who rely on what a custodian, prime broker or broker says Publishes 8, reads 7, hears 1
data External data ingress, an edge the firm's data management Publishes 8, reads 10, hears 3
ems Execution management the execution trader Publishes 9, reads 15, hears 9
confirmation Confirmation and affirmation, an edge the middle office Publishes 1, reads 5, hears 1
oms Order management, with tax-lot selection the trader or desk managing orders Publishes 14, reads 17, hears 12
operations The post-trade pipeline the middle and back office Publishes 10, reads 19, hears 16
portfolio Portfolio construction: the investment decision the portfolio manager; on the sell side, the salesperson as the client's manager's proxy; a market-making strategy Publishes 3, reads 19, hears 13
reporting Reporting, analytics and valuation, and an outbound edge whoever reads results: managers, clients, risk, regulators Reads 19, hears 12
servicing Non-trading transactions, an edge asset servicing Reads 5, hears 1
settlement External settlement rails, an edge the settlements team Reads 5, hears 1
signal Signal generation research, a quant, an enterprise data manager — a person's or an agent's Reads 11, hears 6
reference Reference and terms data a firm's reference-data team, or an enterprise data management vendor's agent Publishes 1, reads 7, hears 1

An edge role connects the deployment to something outside it, and may keep that outside party's raw records in storage of its own, to reconnect and rebuild from. Every other role keeps nothing it cannot lose. No plugin's storage is a channel to another plugin.

connectivity

Venue connectivity, an edge. Connects the firm to a broker or venue, sending placements in the venue's own form and reporting what the venue says.

compliance

Pre- and post-trade rules. Checks acts against the firm's rules before and after the trade, each verdict naming what it checked, and posts standing approved limits execution may act within.

custody

Custodial data, an edge. Brings a custodian's, prime broker's or broker's statements, positions and cash into the street store, and keeps its own connection complete.

  • Persona: the operations staff who rely on what a custodian, prime broker or broker says.
  • Duties:
    • Reports the external accounts a connection reaches and its sync state (W2.8, W2.1).
    • Opens a statement per account, records each holding as the custodian reports it, and closes the statement (W2.2, W2.3).
    • Resolves the identifiers it reads, and reports an instrument it could not resolve; it never mints reference data (W3.1, W3.2).
    • Links the external accounts it reaches to the deployment's accounts, on its admin page (W6.4).
    • Keeps its own connection complete, every account reached and every statement taken, and keeps the custodian's raw records in its own storage (decisions/028).
    • Converts the custodian's codes into the contract's values at the edge: each account's kind, each holding's asset class and type. A code it cannot convert it sends as not known, with the custodian's code beside it as reported, and never as the nearest value (W2.8, W3.2).
    • Counts each asset once: the cash of a currency net of any holding the custodian also counts as cash, netted by its own named rule; and withholds, saying why on its page, a statement it cannot serve clean (W2.3).
    • States every holding's settled quantity and its pending quantities by value date, and names the custodian of every statement; what the custodian does not send it closes itself, by better input, a second source of its own, its page or a named rule, each value with its provenance and never presented as the custodian's (W2.2, W2.3).
    • References, on every row it sends, the raw record the row was converted from; the reference is followed only through its own page (W2.3, decisions/028).
    • Passes the custody suite in full: a plugin that falls short of the role is not verified, and declares nothing about what it supports (W8.1).
  • Leaves to others:
  • Storage: an edge role; it may keep its raw external records in storage of its own.
  • At contract v24: publishes report_external_accounts, report_sync_status, record_holdings_statement, record_holding, record_activity, re_resolve_activity, report_missing_instrument, link_external_account; reads resolve_identifier, read_accounts_for_linking, read_calendar, compute_date, list_replacements, list_templates, read_template; hears ReplaceMergedInstrument.

data

External data ingress, an edge. Puts market, reference and alternative data into the lake, its vendor's codes converted into the platform's attributes.

ems

Execution management. Works orders across venues, creating placements and coordinating requests for quote.

confirmation

Confirmation and affirmation, an edge. Confirms and affirms trades with external matching services.

oms

Order management, with tax-lot selection. Works committed orders — merging and splitting, coordinating compliance checks, setting execution instructions — and books and hands them off.

operations

The post-trade pipeline. Keeps the book right after the trade — opening balances, adjustments, reconciliation with the street, allocations after the hand-off and transfers.

portfolio

Portfolio construction: the investment decision. Makes the investment decision — what and how much — specifying portfolio parameters, risk analytics and proposed trades' overlap with the common optimiser and analytics components, and proposes orders and allocation instructions.

reporting

Reporting, analytics and valuation, and an outbound edge. Specifies and shows reports and analyses, the common analytics component computing them; sends reports and regulatory submissions out, keeping them as sent.

servicing

Non-trading transactions, an edge. Handles corporate actions, lifecycle events and coupons.

settlement

External settlement rails, an edge. Transmits a transfer it is named on over an external settlement rail and reports the outcome.

signal

Signal generation. Generates signals, masters data in the lake from several sources and creates scenario definitions.

reference

Reference and terms data. Gathers a security's terms from sources, reconciles them and fills its template, offering each value to the instrument store with its provenance.

  • Persona: a firm's reference-data team, or an enterprise data management vendor's agent.
  • Duties:
    • Gathers a security's terms from sources — vendor fields arriving through data plugins, custodians' reports — and reconciles them.
    • Fills a security's template, offering each value with its provenance, itself the source (W3.23) (W3.23).
    • Reads the template catalogue and the records it fills, resolves a security read-only, and hears the replacements, following each record it holds to the one it became (W3.1, W3.6, W3.22, W3.24) (W3.1, W3.6, W3.22, W3.24).
  • Leaves to others:
    • deciding a value: a person accepts an offer: dashboard
    • matching or minting an ID: core decides when a record has something to ask by, and the conductor sends it; the platform mints from its own source's values: instrument, conductor
    • defining a template, which the platform authors: the platform
    • prices and every other observation: data, signal
  • Storage: none; it keeps nothing it cannot lose.
  • At contract v24: publishes offer_template_fields; reads resolve_identifier, resolve_instrument, read_calendar, compute_date, list_replacements, list_templates, read_template; hears ReplaceMergedInstrument.

Roles held together

A plugin may hold several roles. It has one sidecar and one credential, and holds the union of their grants; the duties stay separate in the records. Sets a plugin commonly holds:

Who may use a plugin

People are not roles. Who may use a plugin is a person's level on a role of it, granted by a deployment admin in access groups: write on a plugin's operations and read on its custody, say. A plugin never grants it, and an agent never reaches for a role to give a person access (decisions/026, decisions/027, decisions/033). The levels, the same for every plugin:

  • read: sees what the plugin shows for that role
  • write: also acts through the plugin in that role
  • admin: administers that role's side of the plugin: its settings and admin pages

How a deployment admin grants them is in Access; what each opens is in Who may use a plugin.

What every plugin does

Whatever its roles, every plugin makes these calls to its sidecar, through the SDK:

Principles

These are Open Meridian's design philosophy. A request must fit them before any role is chosen.

  1. The roles are fixed and their grants generated; nobody changes them for one plugin. A request that needs a grant no role has is reshaped, or becomes a request to revise the contract for every plugin of that role (decisions/020).
  2. A grant is the minimum a job function needs, and several roles may hold one row. A role is chosen for its duty, not for a grant it happens to hold (decisions/020).
  3. A plugin talks only to its sidecar. Never to the bus, to another plugin, or to another plugin's storage (decisions/004, decisions/028).
  4. Vendor knowledge stops at the plugin. Convert at the edge, declare coverage, keep a vendor's mechanics to yourself; what the contract lacks grows the contract, in terms that name no vendor.
  5. Core records; it does not police. Core is general and plugins are specific. A plugin may narrow what core allows, never widen what it forbids.
  6. The book is the record. The street is what custodians say. The book is verified against it daily, and never overwritten by it (decisions/012).
  7. Ownership passes at two hand-offs, and the owner closes a gap. Ordered equals allocated from portfolio to oms; executed equals allocated from oms to operations. A gap is answered by the role that owns it, under separation of duties.
  8. An optimiser proposes; it never orders. A what-if trade reaches the book only by being proposed.
  9. Stateless compute; storage only at the edge. A plugin holds nothing it cannot lose. An edge role may own storage for its raw external records, and that storage is never a channel to another plugin (decisions/028).
  10. People's access is the deployment's to grant. read, write or admin, per role of a plugin, by a deployment admin. No plugin administers the deployment (decisions/020, decisions/026, decisions/027, decisions/033).
  11. Identity is the deployment's own, and deployment data never reaches the central plane. A plugin resolves identifiers and reports what it could not resolve; it never mints an instrument's or an entity's identity. The deployment's instrument store mints its own IDs and matches what plugins report to them, a person at the dashboard completes and merges them, and a global ID the platform holds joins a record as an identifier, never as its key (decisions/030, accepted 2026-10-02) (W3.1, W3.2, W3.7, W3.10, decisions/030).
  12. Every action is a typed operation a person could take; automation is a plugin's, chosen by the user. Core offers only typed operations, each one something a person could do by hand. Automating them (closing a cleared break, assigning, resolving by policy) is a plugin's behaviour, built from those same operations, off until the user turns it on for their workflow, and run as a service account a plugin admin set up, so the journal says who acted.
  13. A plugin sees only the accounts and the users granted access to it. No plugin reads the firm's whole account list or user list; each sees the accounts in its own scope, and the people granted access to it on them.
  14. The common data model sets the standard; a plugin conforms to it. Specific, accurate and interpretable: a plugin sends what its source states, in the model's fields, and leaves a field empty rather than guess; the model does not loosen to fit a vendor.

From an idea to the least roles

Because roles are fixed and their grants generated, an idea for a plugin is mapped to the roles it needs, the fewest that will do, or reshaped. An agent building a plugin follows these steps, and says what it found at each:

  1. Restate the request as acts and data. What the plugin must cause, what it must read or hear, what it shows and to whom, what it keeps.
  2. Test it against the philosophy. An act that breaks a principle is reshaped before any role is chosen: name the principle and the shape that fits.
  3. Give each act to the role whose duty owns it. From the roles' duties and what each leaves to another, not to a role whose scope merely includes it.
  4. Give each datum to the least role among those that act. Or, where no chosen role reads it, to the role whose duty needs it.
  5. Take the union, and drop a role another chosen role already covers. Keep two duties in two plugins where separation of duties needs it (principle 7), and say which other plugins the deployment must already run.
  6. Check the version. For each row needed, does the contract version the SDK pins grant it? If not, say what brings it, or that the contract lacks it and a revision would have to add it, in terms that name no vendor.
  7. Name the people's access separately. Who uses the plugin, and at which level.

The roles found go in the plugin's pyproject.toml, and a deployment admin approves them when it is launched. For the worked example “Show my positions' value”, below:

[tool.meridian]
roles = ["reporting"]

See Plugin manifest.

Worked examples

Each names what it needs and the contract version that grants it. Where a request breaks a principle, it says which, and the shape that fits.

“Show my positions' value”

  • Least roles: reporting
  • Why: Valuation is reporting's duty: it reads the book's positions and the lake's prices. Not portfolio, since no decision is made; not operations, which writes the book, and whose street is the custodian's view rather than the firm's.
  • People: read
  • Needs:
  • Available: The book's positions from v8, each lot with its cost and acquisition date from v9; prices with the market data revision. Until then a value cannot be shown from the platform's own prices, and an agent says so.

“Rebalance my accounts to a model”

  • Least roles: portfolio
  • Why: Comparing targets with positions and proposing orders is the investment decision. One vendor's plugin may hold portfolio, oms and ems for unattended trading, and the duties stay separate in the records; the mandate's limits stay compliance's.
  • The deployment also runs: an oms plugin to work the orders and a connectivity plugin for the broker
  • People: write
  • Needs:
  • Available: Positions at v8; orders from v22, the order path's first revision. Until a common model language exists, the model is the plugin's own data and does not move with the firm.

“Trade bonds by request for quote”

  • Least roles: ems, connectivity
  • Why: ems, or connectivity, or both. Coordinating a request for quote across dealers is ems's; speaking to the venue that carries it is connectivity's. A trader's quote screen is ems alone, the venue's adapter connectivity alone, and a vendor offering both in one plugin holds both. The order still comes from portfolio and is worked by oms. The request's parameters, its due, firm-until and expiry times among them, are standard fields of the order path, converted by the connectivity plugin at the edge, never a venue's extras.
  • The deployment also runs: a portfolio plugin to decide and an oms plugin to work the order
  • People: write
  • Needs:
  • Available: With the order path's revisions, and a bond's terms with its template. A price in percent of par is a gap in the contract today, which an agent names.

“Reconcile my broker statement”

“Post-trade compliance alerts”

  • Least roles: compliance
  • Why: Alerts are compliance's, and they are the kernel's records: it hears orders, executions, bookings and positions. Not reporting, which records no alert.
  • People: read
  • Needs:
  • Available: Orders and executions from v22, the order path's first revision; bookings and the alert from v24, booking's revision; the compliance language's first terms, restrictions and limits, with v26.

“Make my book match my broker automatically”

  • Reshaped: it breaks principle 6. As asked it needs the book's positions written from the street, a grant no role has.
  • Instead: operations reconciles, records each difference as a break, and resolves one by an adjustment entry with its reason, which a person can review.
  • People: write
  • Needs:
  • Available: v7 and v8.

“Let my plugin give my analyst access to account X”

  • Reshaped: it breaks principle 10. As asked it needs to administer the deployment's access, which no plugin may.
  • Instead: The plugin's page says what to ask for; a deployment admin grants the analyst read on the plugin and the account in the dashboard.
  • Available: Now.

“Read the raw broker responses my custody plugin keeps”

  • Reshaped: it breaks principles 3 and 9. Another plugin's storage is never a channel.
  • Instead: If the information matters beyond that plugin, it is proposed for the contract in terms that name no vendor; until then it stays with its plugin and its page.
  • Available: Only by a revision of the contract.

Generated from boundaries/roles.json in meridian-schema at a6a0af7, contract v24.