Context
BSFG facts carry canonical JSON payloads and may include an optional schema reference in the envelope. This leaves an architectural question: should the boundary substrate enforce business-schema validation before accepting a fact, or should validation remain the responsibility of producers and consumers?
The decision affects:
- whether BSFG remains domain-agnostic or becomes schema-governing middleware
- how fast new bounded contexts can evolve
- how failures are classified at the boundary
- whether transport durability depends on domain-model readiness
Options Considered
| Option | Description | Benefits | Drawbacks |
|---|---|---|---|
| Strict boundary validation | BSFG validates every fact object against a registered schema before append. | strong uniform gatekeeping bad payloads fail early |
boundary becomes domain-coupled schema registry becomes mandatory infrastructure transport availability depends on schema lifecycle |
| Best-effort validation when schema is present | BSFG tries to validate only when an object_schema hint is provided. |
partial protection more flexibility than strict enforcement |
ambiguous contract different payloads get different boundary behavior still drags schema logic into the transport layer |
| No schema reference at all | Carry raw canonical JSON only and omit schema references entirely. | maximal transport neutrality minimal metadata surface |
weak interoperability hints harder downstream evolution and governance less diagnosable payload contracts |
| Optional schema reference; validation stays outside BSFG (Selected) | BSFG accepts canonical JSON payloads, may carry an optional schema hint, but does not perform business-schema validation itself. | keeps boundary substrate domain-agnostic preserves transport durability independence supports schema governance without transport coupling lets bounded contexts evolve independently |
bad domain payloads may still be durably transported producers and consumers must own validation explicitly |
Decision
BSFG does not perform business-schema validation as part of the boundary append path.
boundary acceptance = transport validity + idempotency validity
not = business-schema validity
An envelope may include an optional schema hint, for example:
object_schema = "urn:bsfg:schema:batch.step_completed:v1"
That hint is carried for downstream interpretation and governance, but BSFG itself remains agnostic. Producers, consumers, and downstream domain services are responsible for:
- validating payloads against expected schemas
- enforcing compatibility rules
- rejecting or correcting semantically invalid facts in their own bounded contexts
Consequences
Benefits:
- the boundary appliance remains transport-centric rather than domain-governing
- schema governance can evolve independently of the durable transport substrate
- new bounded contexts can start using BSFG without waiting for central schema enforcement
- transport outages and schema outages do not collapse into one failure mode
Tradeoffs:
- semantic correctness is not guaranteed by the boundary layer
- downstream systems must emit their own acceptance, rejection, or correction facts deliberately
- organizations that want strict schema governance must implement it outside the core BSFG append path