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