Semantic domains
A semantic domain is a named meaning space — staging, pointer, sentinel, versioning,
and so on. The Semantic Engine maintains a constraint graph over concepts in those domains. When an
agent asserts something that conflicts with an existing concept (for example: “commits may use raw
git while CAP is on”), semantic_enforce surfaces the contradiction before the commit.
Why it exists
- Agents forget prior constraints within a long session.
- Docs, rules, and code often encode the same idea three incompatible ways.
- Governance needs a machine-checkable place to say “this concept belongs to domain X and implies Y.”
Core domains
# Core semantic domains agents reason about
staging | semantic | pointer | sentinel
versioning | deployment | canonical | data-array
efficiency | impact | policy | health| Domain | Owns | Docs |
|---|---|---|
| staging | Atomic Commit-Scopes | Staging scopes |
| pointer | Path → home maps | Pointer domains |
| canonical | Singular SoT per concept | Canonicalization |
| data-array | Ordered / unique lists | Data arrays |
| versioning | Semver bump policy | Versioning |
| deployment | Environment promotion | Deployment |
| sentinel | Halt / remediate reflexes | Showcase |
| efficiency · impact | Token cost and outcome maturity | Engine registry |
Agent usage
// MCP
semantic_enforce {}
// Failures name the conflicting concepts and suggested next tools.Each engine in the registry declares its semanticDomain so hosts can filter tools and docs by meaning space.