Rule Semantics

Go up to Terms and Definitions

Discussion

Rule semantics defines meaning through rules, conditions, constraints, decisions, obligations, prohibitions, permissions, derivations, validations, and consequences.

A rule expresses semantic content when it constrains what an artefact, system, actor, process, message, report, schema, ontology, or implementation behaviour means in a defined context. Rule semantics identifies the meaning of the condition, the required outcome, the prohibited outcome, the permitted outcome, and the consequence of rule satisfaction or violation.

Rule semantics differs from rule syntax. Rule syntax provides the form of the rule. Rule semantics defines what the rule means and how the rule constrains interpretation or behaviour.

Rule semantics also differs from implementation logic. Implementation logic executes or enforces selected rules. Rule semantics establishes the meaning that implementation logic preserves, validates, derives, or enforces.

Rules appear in several forms, including natural-language business rules, decision tables, validation rules, policy rules, conformance rules, Semantic Business Vocabulary Model (SBVM) vocabulary constraints, sbrm reporting rules, schema constraints, OWL axioms, runtime checks, and executable rule engines.

Rule-processing architectures express rule semantics through defined responsibilities. A policy administration point records or manages governed rules. A policy information point supplies facts, attributes, or context used during rule evaluation. A policy decision point evaluates rules and produces decisions. A policy enforcement point enforces decisions.

Rule semantic content includes:

Rule subjectsRule conditionsRule conclusionsBusiness vocabulary termsFact typesObligationsProhibitionsPermissionsConstraintsDerivationsDecision inputsDecision outputsValidation outcomesDecision outcomesExceptionsViolation conditionsRejection reasonsEvidence requirementsPolicy administration pointsPolicy information pointsPolicy decision pointsPolicy enforcement pointsTraceability to semantic sourcesA governed architecture preserves traceability from rule semantics to the conceptual model, vocabulary, policy source, schema, ontology, report model, implementation artefact, or conformance test that expresses or validates the rule meaning.

Definition

meaning defined through rules, conditions, constraints, decisions, obligations, prohibitions, permissions, validations, and consequences within a defined context

Source

DIDO Solutions usage, informed by business rule practice, policy modelling, validation practice, conformance testing, semantic modelling practice, and model-driven architecture principles.

Note

Rule semantics is not equivalent to rule execution. A rule engine, validation function, policy decision point, policy enforcement point, or runtime check expresses selected rule semantics in executable or operational form. The governed rule source establishes the intended meaning.

A rule violation carries semantic meaning when the violated rule traces to a defined concept, business vocabulary, policy, requirement, report model, schema, ontology, lifecycle, or other authoritative semantic source.

Example

An FX Demo specification defines the following business rule:

A confirmed FX trade has a settlement date that does not precede the trade date.

The rule contains semantic content because it defines a valid relationship between the trade date, settlement date, and confirmed lifecycle state.

Rule element	Example value	Rule semantic meaning
Rule subject	ConfirmedFXTrade	the rule applies to trades in the confirmed lifecycle state
Business vocabulary terms	confirmed FX trade, settlement date, trade date	the rule uses governed business meanings from the SBVM or another authoritative vocabulary source
Condition	settlementDate precedes tradeDate	the trade contains an invalid temporal relationship
Prohibition	settlement date before trade date	the lifecycle interpretation is not permitted
Expected validation outcome	Reject	the system rejects the trade message or state transition
Rejection reason	Settlement date precedes trade date	the rejection records the semantic rule violation
Semantic source	FX trade lifecycle rule	the rule traces to the governed lifecycle meaning
Conformance interpretation	non-conforming trade lifecycle interpretation	the failed rule identifies a semantic non-conformance

The rule-processing architecture assigns responsibilities for the same rule:

Rule-processing role	Example component	Rule semantic responsibility
Policy administration point	FX Policy Console	records and governs the settlement-date rule
Policy information point	Trade Attribute Service	supplies tradeDate, settlementDate, and lifecycleState
Policy decision point	FX Validation Decision Service	evaluates the rule and returns Accept or Reject
Policy enforcement point	Commit Guard	prevents commitment of a trade state when the decision is Reject

The same rule appears as executable validation logic in an implementation:

if settlementDate < tradeDate:
reject("Settlement date precedes trade date")

The code expresses rule semantics only because the implementation traces to the governed rule. Without traceability, the code represents an undocumented implementation decision rather than a governed semantic constraint.

© 2026 Dido Solutions, Inc. and Jackrabbit Consulting, Inc.