Writeback
Status: ✅ Decided — grounded in ADR-0010
Writeback is the kernel’s mechanism for propagating approved changes back to external systems of record — GIS, ERP, OSS. It is a first-class kernel concern, not an afterthought, because closing the loop to external systems of record is a core differentiator.
The kernel models writeback as a WritebackIntent with a full state machine: pending → dispatched → confirmed / failed → compensated. The saga semantics — idempotency keys, compensation, dead-letter handling — are implemented against the intent, not against a specific foreign connector. This separation is deliberate: the kernel part of writeback (intent lifecycle, saga, compensation) is exactly what the proof should demonstrate; the foreign connector part (idempotency against a specific external API, partial failure handling for a specific system) is what consumes integration teams.
In the proof: the dispatch layer targets legacy SmartInventory as the initial “real-ish” connector, which ADR-0009 already treats as just another connector. Real customer GIS/ERP/OSS connectors are deferred post-proof. Building them later is additive: they implement the dispatch interface that the intent/saga already drives.
See also
- Concepts — Writeback
- Legacy Connector — SmartInventory as the proof’s stub target
- ADR-0010 — writeback decision
- ADR-0009 — legacy as connector
Open questions
- The saga/workflow engine (Temporal or equivalent) is an implementation detail to confirm during the proof. ADR-0010 notes the dependency but does not decide the engine.