Routing and liquidity are different questions
Order routing asks where an order should be sent. Liquidity provision asks who takes the other side. A venue can do one, the other, or both, and the platform keeps the two concerns separate because they have different risk profiles.
An adapter declares its scope, so a broker can see at configuration time what a given connection will and will not do. None is connected in this build; the scopes are described so the model is reviewable.
Order routing
A routing adapter translates a platform order into a venue-specific payload and sends it on. The venue matches it against its own book or passes it upstream. Routing rules can select between venues by symbol, size or a configured preference.
Liquidity provision
A liquidity adapter quotes or fills an order against external liquidity. Here the platform's exposure is the venue's exposure, which is why liquidity scope carries a different operational weight than pure routing.
Signal-only and internal venues
Not every connection moves capital. A signal-only venue contributes prices and streams without accepting orders, and an internal venue lets routing be exercised before any external connection exists.
These models exist so behaviour can be tested in isolation. A copy path can be exercised end to end against an internal venue without a live venue being involved.
Why the boundary is an adapter
Venue-specific behaviour is quarantined behind the adapter boundary so that everything above it — copying, risk, allocation and reporting — is written against platform types, not against one venue's quirks.
That is what makes the rest of the platform testable without a venue, and what lets a broker change execution routing without changing the records a console reads.