# Invariants

Enforcing invariants on domain model may involve complex mechanisms (in terms of resources and time), including even external services, not to mention sophisticated `validation functions` like
- each store has a unique ID number
- check digit meets an identification number
- email is a proper email
- device type X has ABC additionally built-in, whereas Y does not
- conditionally applicable rules

On the other hand, invariants may also take more straightforward roles, i.e.:
- address email conformance, whether it is mandatory or optional. It is -
- specify whether a data value must conform to one or many from an exhaustive list of values
- date is within the proper date range

Ensuring business rules from the governance and economic layer is to enforce invariants within the solution (technology) layer; that is, the captured data meets business requirements. Aside from invariants, data also has semantics that describe its mechanical characteristics. Therefore, the `validation` process consists of ensuring semantics and invariants. Although executed against the same data, these two are distinct concepts that serve different purposes. The former ensures quality in the business sense and the latter in the mechanical sense, extremely useful for any postprocessing, including analytics, transformations, and harmonization.

Semantics brought by OCA, as opposed to invariants, preserve the additional meaning of captured data. It makes explicit what so far was implicit, that is, the data "type", format, unit (if applicable), and encoding — furthermore, human reasoning oriented label and description. OCA makes them first-class citizens.

To reiterate, business doesn't care about the data semantics. However, business is `implicitly` very much affected by how the data was captured, its semantic quality, and the enrichments that OCA metadata brings. While invariants are explicit and semantics implicit from the business perspective, when we speak about data postprocessing, business cannot ignore data semantics.