Define the data service you actually need
Start with the instrument universe, receiving systems and permitted data use. Record whether the project needs live updates, a consumer-facing API, historical records or an operational reference. Each requirement can introduce different interface and validation work.
Identify who supplies the data and who controls its use rights. The implementation brief then separates the connection work, transformations and platform-side configuration from the provider’s data service and commercial permissions.
Agree the delivery workstreams
| Workstream | Delivery to define | Acceptance evidence |
|---|---|---|
| Source connection | Approved interface, environment and access owner | Connection and denied-access tests |
| Mapping | Instrument names, fields, precision and exceptions | Representative source-to-receiver samples |
| Platform/consumer setup | Required receiving configuration and dependencies | Observed results in each agreed receiver |
| Monitoring | Freshness, rejected input and connection alarms | Controlled exception and alert test |
| Handover | Mapping register, change procedure and escalation | Operator review of normal and failure workflows |
Instrument-specific configuration belongs in the test sample. A single successful update is not enough to accept a diverse symbol set.
See the proposed delivery method
Illustrative project: a brokerage changes the source for a defined instrument set. The review compares identifiers, sessions and field meanings, prepares the new mapping and observes both source and receiver during an approved validation window.
Acceptance records the tested symbols, known exceptions and recovery route. The existing source is retired only under the agreed transition plan. For a new environment, the same records establish a baseline that can be checked when instruments or consumers change. Use the project brief to share your platform, source arrangement, instrument set and intended outcome.