# Integrating FDC3 in TraderX: What Worked, What Was Flaky, What We Learned

> For the complete documentation index, see [llms.txt](https://deploy-preview-472--lucky-concha-f3599f.netlify.app/llms.txt).

State `014-fdc3-intent-interoperability` was our first end-to-end pass at wiring FDC3 interaction patterns into a live TraderX environment.

The goal was straightforward: prove that intent-style interoperability is practical in a realistic demo stack, not just in isolated snippets.

## Why This State Matters

This state shows that a single TraderX deployment can coordinate:

*   pricing and market-data context,
*   order-management workflows,
*   chart and news views on separate tabs,
*   and FDC3-based action routing between apps.

In short, it demonstrates the point of FDC3 in an environment people can actually run and explore.

For FDC3 background, see [fdc3.finos.org](https://fdc3.finos.org/).

## What We Built

To make the integration explicit and easy to understand, we introduced a separate Sail app that dispatches TraderX-related FDC3 events.

That gave us a clear place to:

*   map UI actions to FDC3 payloads,
*   push context on channels,
*   and route action-specific behavior without entangling every component.

It is not the final elegance target, but it is a practical and inspectable starting point.

## Where We Saw Flakiness

During integration and demo validation, we ran into several reliability pain points:

*   High-volume heartbeat and context-sync logs obscured signal during debugging.
*   `broadcast`\-driven button flows were less deterministic than `raiseIntent` flows in some paths.
*   Tab/channel context timing was easy to get wrong when multiple widgets were syncing state.
*   TradingView interactions exposed symbol-normalization mismatches across components.

One concrete pattern: raising intent from the trade list path behaved consistently, while some button-triggered paths required tighter alignment of context/action payloads before behavior was reliable.

## Symbology Lessons (and Why CDM Helps)

Symbol normalization turned out to be one of the biggest practical interoperability issues.

Even with a common ticker value (`AAPL`), differences in source assumptions and widget behavior can create subtle drift in how symbols are interpreted or propagated.

This is exactly where broader semantic normalization helps. A stronger shared model such as CDM should reduce these integration seams over time.

For CDM background, see [cdm.finos.org](https://cdm.finos.org/).

## Why This Is Still a Strong Result

Despite the rough edges, this state proves real value:

*   We can run a self-contained demo with FDC3 behavior that is visible and testable.
*   We can show intent/context propagation across independent app surfaces.
*   We now have a concrete baseline for hardening, not a theoretical design.

There is much more we can make it do, but this already demonstrates the core interoperability point with live, inspectable software.

## Spec + Code Links

*   State spec pack: [/specs/fdc3-intent-interoperability](https://deploy-preview-472--lucky-concha-f3599f.netlify.app/specs/fdc3-intent-interoperability.md)
*   Learning guide: [/docs/learning/state-014-fdc3-intent-interoperability](https://deploy-preview-472--lucky-concha-f3599f.netlify.app/docs/learning/state-014-fdc3-intent-interoperability.md)
*   Generated code branch: [code/generated-state-014-fdc3-intent-interoperability](https://github.com/finos/traderX/tree/code/generated-state-014-fdc3-intent-interoperability)
*   Compare vs parent (`012`): [code/generated-state-012-platform-convergence-c3...code/generated-state-014-fdc3-intent-interoperability](https://github.com/finos/traderX/compare/code%2Fgenerated-state-012-platform-convergence-c3...code%2Fgenerated-state-014-fdc3-intent-interoperability)