ADR-023: Shift from SBVR to SEA-DSL Policy

Status: Accepted Version: 1.0 Date: 2025-10-01 Supersedes: N/A Related ADRs: ADR-004 Related PRDs: N/A

Context

Original architectural documents (ADR-004, SDS-001) specified SBVR (Semantics of Business Vocabulary and Business Rules) as the formal logic execution layer. However, implementation reality has diverged:

• The actual DSL uses “SBVRish” logic (quantifiers, modalities) but is not strict standard SBVR.
• “SBVR” implies a specific OMG standard dependency that is not actually present.
• The DSL supports 3-valued logic and specific “Unknown” semantics that differ from standard SBVR implementations.

Decision

We will formally rename and reframe the logic layer:

1. Concept Rename: “SBVR Rule” -> “SEA-DSL Policy”.
2. API Rename: /sbvr/rule/evaluate -> /policy/evaluate.
3. Role Change: SBVR is downgraded from a runtime dependency to an optional import/export projection target.

Rationale

• Clarity: Removes “interface drift” between specs and code.
• Flexibility: Allows SEA-DSL to evolve its specific Deontic/3-valued logic requirements without being constrained by strict SBVR compliance.
• Accuracy: The DSL is not strict SBVR; claiming otherwise creates confusion.
• Compatibility: SBVR remains available as a projection target for interoperability.

Constraints

• MUST rename “SBVR Rule” to “SEA-DSL Policy” in all new documentation
• MUST rename /sbvr/rule/evaluate API to /policy/evaluate
• MUST treat SBVR as optional import/export projection target only
• MUST NOT claim SBVR standard compliance for runtime execution
• MUST reference ADR-004 Compatibility Profile for SEA™ DSL ↔ SBVR mapping

Quality Attributes

• Documentation accuracy and consistency
• Flexibility for DSL evolution
• Clear separation of runtime logic from projection targets
• Reduced confusion about standard compliance

Bounded Contexts Impacted

• Semantic Core
• Policy Evaluator
• API Layer
• Documentation

Consequences

Positive

• Documentation Refactor: All existing specs referencing SBVR must be interpreted as referring to the SEA-DSL Policy layer.
• Clarity: Removes “interface drift” between specs and code.
• Flexibility: Allows SEA-DSL to evolve its specific Deontic/3-valued logic requirements without being constrained by strict SBVR compliance.
• Compatibility: See ADR-004 for the detailed Compatibility Profile between SEA™ DSL and SBVR.

Negative

• Requires documentation updates across existing specs
• May cause temporary confusion during transition

Additional Notes