Context
BSFG already defines ConfirmReceipt as durable commit in the target zone log. That leaves an important boundary question unresolved:
- does confirmation imply downstream consumer processing?
- does confirmation imply semantic validation?
- does confirmation imply business acceptance?
- does BSFG itself own projections or application state transitions?
If BSFG expands confirmation to include domain semantics, it stops being a boundary appliance and becomes part transport, part workflow engine, part business system.
Options Considered
| Option | Description | Benefits | Drawbacks |
|---|---|---|---|
| Boundary confirmation equals business acceptance | Make ConfirmReceipt mean the receiving domain processed and accepted the fact semantically. |
one acknowledgement appears to mean everything simple mental model for some clients |
couples transport to domain logic confirmation latency becomes application-dependent weak fit for generic replay substrate |
| Boundary confirmation equals consumer acknowledgement | Make ConfirmReceipt mean some consumer fetched and acked the fact. |
closer to delivery semantics aligns with some broker mental models |
still leaks consumer topology into boundary contract consumer absence changes transport meaning not stable across deployments |
| No distinction at all | Let each deployment interpret confirmation however it wants. | maximal local flexibility no extra architectural discipline required |
ambiguous contracts poor auditability cross-zone behavior becomes inconsistent |
| Boundary confirmation remains transport-local; business acceptance is modeled as downstream facts (Selected) | Keep BSFG confirmation at durable-commit scope, and represent semantic processing or acceptance using additional facts emitted by downstream systems. | clean architectural boundary uniform confirmation semantics domain workflows stay outside the transport substrate business acceptance remains replayable as facts |
more than one fact may be needed to tell the whole story clients must understand transport success vs business success |
Decision
BSFG does not treat transport confirmation as business acceptance.
ConfirmReceipt = durable commit in target zone log
not = consumer processed
not = business accepted
not = projection completed
If downstream systems need to express semantic outcomes, they do so by appending new facts, for example:
(message:123, received_by, Enterprise)
(message:123, validated_by, release-engine)
(batch:PlantA/B1042, accepted_by, release-engine)
(batch:PlantA/B1042, rejected_by, qc-review)
BSFG is therefore responsible for:
- durable fact transport
- idempotent append
- bounded fetch
- durable receipt confirmation
BSFG is not responsible for:
- semantic validation of business payloads
- projection success
- workflow completion
- domain approval or rejection decisions
Consequences
Benefits:
- transport contract remains uniform and auditable
- consumer topology does not redefine boundary semantics
- business workflows remain explicit and replayable as facts
- BSFG stays a boundary appliance rather than becoming an application platform
Tradeoffs:
- operators and clients must distinguish transport success from business success
- end-to-end workflow narratives require reading more than one fact stream event
- downstream systems must emit their own acceptance/rejection facts deliberately