0004. Model adapter capabilities as a domain×direction map¶
Date: 2026-07-10 Status: Accepted
Context¶
An adapter can support up to four directions of data flow:
| Direction | Meaning | Today |
|---|---|---|
PullIn |
Conflux actively queries the adapter (e.g. bulk export from WooCommerce) | present |
PushIn |
Adapter reports to Conflux (e.g. webhook from WooCommerce) | present |
PullOut |
Adapter reads Conflux (e.g. rapidmail reads via REST) | present, but bound to App |
PushOut |
Conflux actively writes to the adapter (e.g. write order status back to WooCommerce) | missing entirely |
Today this is rigidly tied to the system type, not expressed as data. The existing
System.capabilities field already means something else — the data domains a system deals in
(Products/Orders/Customers) — so direction cannot simply be folded into it without conflating two
different meanings.
Decision¶
Direction is modelled as its own field: a new SyncDirection enum stored on System as a map of
data domain → supported directions, e.g.
{"orders": ["pull_in","push_in","push_out"], "customers": ["pull_in","pull_out"]}. This lets
"WooCommerce can push order status back but only read customers" be expressed. The existing
capabilities field stays untouched.
Consequences¶
Per-domain granularity is, for now, only truly exercised by push-out; until then it is effectively adapter-wide. It is modelled as a map now regardless, because widening a flat boolean structure into a map later would be a more expensive migration than modelling it correctly up front.