Regnant
Products/03 · MattaEarly Access

Matta.

A semantic platform, not a file.

Doc. MATTA/ESP

Class. Enterprise ontology

Status. Research preview

Register. Specification

One source of truth for enterprise master data. Matta unifies the customers, suppliers, employees, and contracts scattered across CRM, ERP, and HR systems into a single governed layer, duplicates resolved, quality enforced, every fact traceable to the system it came from. Ask what your business knows, and get an answer with receipts. This page reads like a specification because that is the standard the answer is held to.

Regnant · SYSTEM RECORDSystem03 / 07
“client” “account” “partner”GOVERNANCEOWL · SHACLONE DEFINITIONmachine-verifiablegoverned · traceable
○ “client” · “account” · “partner”hatch: governance, applied● one governed definition
Plate III: three names arrive, one meaning leavesRegnant · Sovereign AI · Dar es Salaam
A coffered concrete grid receding into shadow

Fig. 0: structure, held overhead. Every cell knows its place.

§00

Outcomes: what the enterprise gets

01

One golden record

The same customer in Salesforce, SAP, and the legacy database becomes one governed identity, duplicates found and resolved, not re-keyed by hand.

02

Audit-ready by default

Every fact carries its source system, timestamp, and confidence. When the auditor asks where a number came from, the answer is one query away.

03

The past, on demand

See the business exactly as it stood on any date, corrections are recorded, never overwritten. Compliance reviews stop being archaeology.

04

AI that cites its sources

Questions answered from governed facts with the evidence attached, and an honest “not found” instead of an invented figure.

§01

Competency: what the platform must always answer

  1. Q01What does “customer” mean across every system we run?
  2. Q02Are “client,” “account,” and “partner” the same thing?
  3. Q03Which employee approved this invoice: and were they authorized?
  4. Q04What is the full provenance of a risk classification?
  5. Q05How does a contract in the ERP relate to one in the legal system?
  6. Q06What can be inferred from what we already know?
  7. Q07What is inconsistent or missing in our data?
  8. Q08What changed in the meaning of “customer” between versions?
  9. Q09Which downstream dashboards break if a property is renamed?
  10. Q10What did we know about an entity 90 days ago?
§02

Architecture: the sectional cut

Competency questions, the business glossary, and named ownership. What the platform must be able to answer, and who is accountable for it.

Shared meaning: canonical definitions and SKOS vocabularies that business and systems agree on before anything is modeled.

Entity, Process, Event, Role, Location, Time. Frozen after release: fewer than two changes a year, each requiring a major version and architecture board approval.

Customer, Product, Order, Contract, Asset, Employee. Changes require architecture review and a minor version bump.

Finance, HR, Supply Chain. Domains evolve freely within their own minor version scope, and never import each other directly; cross-domain relationships route through the core.

ERP, CRM, and warehouse mappings. Application systems map to the ontology, never the reverse.

SHACL shapes and business rules. OWL, SHACL, and procedural rules each hold a strict, non-overlapping mandate. Every rule carries a plain-English explanation.

Triplestore, identity index, temporal facts. Identity gets its own service and data model. The graph remembers what was true 90 days ago.

Online/light on the critical path; offline/heavy never on it; a materialized inference database in between.

Federated query, semantic search, APIs, AI integration, governance, semantic diff, impact analysis, audit trail. The layer everything else exists to serve.

Fig. 2. Sectional cutDoc MATTA/ESPS3 frozen by policySheet 1/1

Reading the cut

Business intent at the surface; operations at depth. Every layer is independently versionable. The foundational layer is frozen by policy: the discipline, not the diagram, is the product.

§02b

Truth hierarchy: where a claim comes to rest

Drop a claim in

Running through all six. Pick one to hold it.

pick a claim,
SHACL gateviolates a shape → rejected outright
OWL gatecontradicts the ontology → alert raised, held for a steward
T1Assertedstated by an authoritative system
T2Inferredconcluded by the reasoner
T3Resolvedsettled by identity resolution
T4Derivedcomputed downstream

Authority is vertical. Drop the same claim twice, it lands in the same place. That's the deterministic part.

§03

Design principles: ten, non-negotiable

  1. P01Meaning is separated from implementation at all times
  2. P02No single giant file: every module independently versionable and testable
  3. P03The core stays small and stable; extensions live in domain modules
  4. P04Application systems map to the ontology, never the reverse
  5. P05Governance is first-class, not an afterthought
  6. P06Heavy reasoning is never on the critical path
  7. P07OWL, SHACL, and procedural rules each hold a strict, non-overlapping mandate
  8. P08Identity gets its own service and data model
  9. P09AI components consume only authoritative facts; probabilistic ones are explicitly labeled
  10. P10Every output must be explainable back to source facts and rules
§04

Governance: the ruleset

GOV-01

Foundational ontology frozen after release: target fewer than two changes a year; each requires a major version and architecture board approval

GOV-02

Core ontology changes require architecture review and a minor version bump

GOV-03

Domain modules evolve freely within their own minor version scope

GOV-04

Retired identifiers are never reused: marked deprecated and archived

GOV-05

No domain module imports another domain module directly; cross-domain relationships route through the core

GOV-06

Every class and property carries a label, description, created/modified dates, and a named steward

GOV-07

Every validation rule carries a plain-English explanation for business users

GOV-08

Every breaking change ships with a migration guide

§05

Functional groups: four mandates

01

Meaning

defines what things are

02

Rules

defines what must be true

03

Data

holds entities and facts with temporal and provenance context

04

Operations

reasoning, query, diff, APIs, governance, AI

§06

Deployment: the promotion path

dev
staging
uatsteward review
prod

Dual-run supported during breaking-change migration windows. Containerized, horizontally scalable, GitOps-managed.

§07

Roadmap: four phases

Phase 1

Foundation

Core ontology · glossary · triplestore · validation pipeline · tiered reasoning skeleton · governance process · portal

Phase 2

Domain & Integration

Finance / HR / Procurement ontologies · ERP & CRM mappings · identity resolution · temporal graph · federated query

Phase 3

Semantics & AI

Semantic diff service · knowledge-graph embeddings · hybrid semantic search · RAG grounding layer · explanation service · document extraction

Phase 4

Scale & Hardening

Supply chain / manufacturing / legal / security ontologies · full regression suite · graph-level access control · impact analysis · agentic tool interface

Matta preview

Matta preview