UnityBridge

A normalisation + MCP layer for trade data. Heterogeneous messages — FIX, venue JSON, broker CSV — land in different shapes; UnityBridge maps them all to one normalised record and exposes that over MCP, so an LLM or agent can query it in plain English without touching the raw plumbing.

This mirrors the job Quod's Unity layer does: a normalised, real-time data layer that any downstream consumer (including AI) can read against one schema.

   FIX 4.4 ─┐
   JSON     ├─► normalizer ─► NormalizedOrder ─► OrderStore ─► MCP tools
   CSV      ┘   (detect +        (one schema)     (query +      query_orders
                 parse +                           aggregate)    aggregate_latency
                 validate)                                       ingest_stats

What's real here

• parsers/fix.py, parsers/venue_json.py, parsers/broker_csv.py — three real parsers with correct field maps (FIX tags 11/55/54/38/44/30/39, venue key aliases, positional CSV). Each maps to the same NormalizedOrder.
• normalizer.py — format detection, dispatch, pydantic validation, latency enrichment, and error capture (malformed messages are recorded, not dropped silently — the success rate is a real metric).
• store/order_store.py — filterable query + aggregates (p50 latency by venue, reject rate, counts by status), computed, not hard-coded.

Quick start

make install
make replay N=500          # replay a synthetic feed, print normalisation stats
make mcp                   # serve query tools over MCP
make test
docker compose up

Status

Reference skeleton. Parsers, normaliser and store are real and run offline on a synthetic multi-format feed. # INTEGRATION: markers show where the live Unity / Kafka bus replaces the synthetic generator.