Hub-and-spoke signal engine

Cortana’s architecture. The hub owns signal distribution, risk aggregation across layers, and the future API surface. Each trading layer is a spoke - consumes market data, produces signals, reports positions and performance back to the hub.

Why this shape

Retrofitting modular architecture after the fact is significantly harder than enforcing it from day one. The hub-and-spoke is not cosmetic. It is the same architecture required to commercialize Cortana as a signal data service later. Every architectural decision made today is made with that end state in mind.

Rules

• Each trading layer is a spoke.
• The hub owns signal distribution, risk aggregation, and the future external API surface.
• No spoke may directly depend on another spoke. All coordination happens through the hub. Spokes stay independently testable and independently commercializable.
• Execution is centralized through IBKR.
• Data, logging, and performance attribution centralize at the hub.

Why “no spoke-to-spoke”

If Layer 2 calls Layer 1 directly, then Layer 2 cannot be tested, validated, or sold separately. The coupling destroys modularity. The same rule makes each layer a discrete subscriber product later.

Implication for every change

Before any component lands, ask: does this plug into the signal engine cleanly? If not, it is not built correctly. No exceptions.

See Also

• projects/cortana.md
• concepts/publisher-not-advisor.md - shapes the hub’s external API design
• concepts/three-layer-thesis.md