A bid data model that preserves meaning.
Explore a fictional JSON observation, its schema, and the separate identities needed for commands, events, and confirmed outcomes.
An observation is not a command
The object below is a fictional quote observation. It records what a source is imagined to have reported, not an instruction to transact. A real adapter must follow its provider’s actual field definitions and access conditions. Keep the provider’s original identity and enough evidence to interpret the normalized values.
{
"example": true,
"schema_version": "1.0",
"kind": "quote",
"source": {
"id": "example-provider",
"market": "stocks"
},
"asset": {
"id": "DEMO",
"type": "equity"
},
"bid": {
"value": "100.10",
"currency": "USD"
},
"ask": {
"value": "100.16",
"currency": "USD"
},
"observed_at": "2026-09-15T12:00:00Z",
"received_at": "2026-09-15T12:00:00.120Z"
}| Field | Meaning |
|---|---|
example | Explicitly identifies this fixture as fictional. |
schema_version | Version of this illustrative local contract. |
kind | The observation type; this example is a quote. |
source | The example provider and market identity. |
asset | A fictional instrument identifier and type. |
bid / ask | Decimal strings with an explicit currency. |
observed_at | The hypothetical time attributed to the source event. |
received_at | The hypothetical time the application received it. |
Download the local example files
Open the quote observation JSON, the illustrative JSON Schema, or the event fixture. These are static files that can be inspected locally. Opening them does not call an API, authenticate an account, or place a bid.
Keep commands in a separate model
A proposed command record needs an immutable ID, actor, account, destination, authorized payload, expiry where relevant, and the provider reference returned after submission. Do not reuse the source observation’s timestamp as approval evidence. Attach the observation that informed the decision as a reference rather than silently converting it into an instruction.
Define outcome states explicitly
Draft, authorized, submitted, acknowledged, rejected, expired, cancelled, and unknown are useful application-level starting points. Add the provider’s own more precise state instead of forcing every workflow into the same terminal labels. A completed commercial transaction and a delivered domain can require separate milestones.
Validate boundaries and retain evidence
Reject invalid units, missing required identifiers, and currency mismatches before the record enters a shared store. Keep decimal precision consistent and separate presentation rounding from stored values. Test version changes and unknown fields deliberately. The architecture article explains how these choices support a clearer integration.