A composite attributes its use to the providers of its inputs

Table of Contents

1. Summary

A composite is an internal item that the service derives from several quote series by a rule. A blended EUR/USD spot from Bloomberg and LSEG is the first case. The composite is published by an internal source of kind derived. A party that uses it needs the derived right on every input provider, and its use is metered against those providers.

2. Detail

2.1. The model

A composite has an output item, a list of inputs, and a rule. Each input is a quote series of one provider. The rule is pluggable: an average, a median, a governed waterfall or a custom method.

2.2. The flow

The ingest loop recomputes a composite when an input series stores a new value. The result is stored in the series (output item, composite provider, party). The composite provider is an internal provider with one derived source. The composite follows the same routing and delivery path as any other item. See The ingest loop and the one pipeline.

2.3. Licensing

Each input provider's licence limits derived use. The system checks that the party holds derived on every input provider. A composite with a missing right gets no values and shows the reason. See Display, non-display and derived rights are modelled on the subscription.

2.4. Cost attribution

A composite has no rate card. Its use is metered as demand on its inputs, so each input provider's charge components see it. See A rate card on the source turns usage into a bill the platform shares.

2.5. Rule governance

The rule that blends spot rates is a governance decision. See Spot rate blending for the methods and Spot rate governance for the approval.

2.6. What is deferred

The first release can ship without any rule. The model exists so a later rule needs no schema change.

3. See also

Emacs 29.3 (Org mode 9.6.15)