White paper — NDMO compliance by architecture: mapping the 15 domains to an agentic data platform

Executive summary

The National Data Management Office (NDMO), under the Saudi Data and Artificial Intelligence Authority (SDAIA), has published the most comprehensive national data management framework in the region: the Data Management and Personal Data Protection Standards, spanning 15 domains, 77 controls, and 191 compliance specifications. They apply to government entities and to the private organizations that handle government data — which, in practice, covers a large share of serious enterprises in the Kingdom.

Most organizations attack these standards as a documentation program: a compliance office, a wave of consultants, a wall of artifacts describing a data estate that has already changed underneath it. Globally, that approach has a well-documented failure rate — Gartner expects 80% of data and analytics governance initiatives to fail by 2027, and the root cause is consistent: governance run as a project next to the data work rather than inside it.

This paper makes a different argument, in four parts:

1. Most NDMO domains do not ask you to believe anything. They ask you to produce artifacts — catalogs, lineage, classifications, quality evidence, audit trails.
2. Artifacts can be manufactured by hand after the fact, or they can fall out of the architecture as a byproduct of doing the work. The first approach decays; the second compounds.
3. Mapped domain by domain, an agentic data platform with governance built into the execution path can automate or materially accelerate roughly two-thirds of the framework’s evidence burden — while a handful of domains remain, correctly and permanently, organizational.
4. The practical consequence: teams stop spending their scarcest people on evidence manufacturing and spend them on the judgment calls only humans can make.

We write this from the region, not about it. Celvari was built inside enterprise engagements across Egypt and the Gulf, and we are bringing our headquarters to Saudi Arabia — because the Kingdom is where the most ambitious national data agenda in the world is actually being executed.

---

Part 1 — The framework, read plainly

The NDMO standards are organized as a three-level hierarchy: domains → controls → specifications. The fifteen domains are:

1. Data Governance
2. Data Catalog and Metadata
3. Data Quality
4. Data Operations
5. Document and Content Management
6. Data Architecture and Modelling
7. Reference and Master Data Management
8. Business Intelligence and Analytics
9. Data Sharing and Interoperability
10. Data Value Realization
11. Open Data
12. Freedom of Information
13. Data Classification
14. Personal Data Protection
15. Data Security and Protection

Two things are worth noticing before any vendor conversation.

First, the scope is the whole lifecycle. This is not a privacy law with a data inventory attached. The domains run from architecture and modelling through operations, quality, analytics, and value measurement, all the way to open data and freedom of information. An estate that satisfies this framework is not “compliant” in the narrow sense — it is simply well run. That is exactly how the framework is meant to be read: as a description of what a trustworthy national data estate looks like, control by control.

Second, the framework is evidence-oriented. Read the specifications and a pattern emerges: a catalog that reflects reality; lineage you can show; quality rules that demonstrably run; classifications applied to actual columns; access decisions you can defend; an auditable account of how any number came to be. These are artifacts, not aspirations. And that observation carries the whole argument of this paper, because artifacts have a cost structure — and the cost structure depends entirely on how they are produced.

Part 2 — Why the conventional program fails

The conventional NDMO program looks like this. A compliance function is stood up. The 15 domains are divided among workstreams. Each workstream interviews data owners, inventories systems, drafts policies, and fills templates. Twelve to eighteen months later, the organization holds a complete set of artifacts.

Then the trouble starts, for one structural reason: the evidence was produced separately from the work it describes. The catalog was written by people who interviewed the engineers, not by the systems the engineers use. The lineage diagrams were drawn, not traced. The quality rules exist in a policy document, not in a gate that can stop a bad build.

Separately produced evidence decays the moment it is finished. Every new pipeline, every schema change, every new report makes the documentation slightly more wrong. So the organization faces a permanent tax: either staff a team to chase the estate forever, or let the artifacts drift until the next audit forces a heroic refresh. Most organizations oscillate between the two, which is the most expensive option of all.

This is not a criticism of the framework. It is a criticism of an implementation style — one the data industry has repeated for two decades, which is precisely why the global failure statistics look the way they do. The NDMO standards simply raise the stakes: here, the requirements are written down, versioned, prioritized, and enforced. An implementation style with a built-in decay problem will meet a compliance regime with a built-in review cycle, and it will lose.

Part 3 — The architectural alternative

There is a different way to produce the same artifacts: design the platform so that doing the data work generates the evidence as exhaust.

Five design principles make that real. They are the principles Celvari is built on, but they are worth stating platform-neutrally, because they are the right questions to put to any vendor:

1. Governance in the path, not beside it. Controls must be gates the work passes through, not reports written about the work afterwards. If a quality rule can fail without stopping anything, it is documentation, not governance.

2. Metadata as exhaust, not as a project. The catalog, lineage, and classifications must be produced by the act of building — captured at the moment a transformation is generated, not reconstructed by interview afterwards.

3. Deterministic, versioned artifacts. What the AI produces must be reviewable: plain, versioned SQL on your own engine, not opaque templated logic. Auditors, regulators, and your own engineers must be able to read what runs.

4. Humans at decision points, not on the assembly line. The framework requires accountability — a person who approved the thing. Architecture should concentrate human attention at the approval moment, with the full evidence (intent, generated logic, test results, quality findings) in one view, rather than spreading people thin across manual build steps.

5. Everything traced. Every agent step, every transformation, every check, every approval — logged and replayable. In a regulated environment, “how was this number produced?” must be answered by a trace, not an archaeology project.

One more principle sits underneath all five, and in the Saudi context it may matter most: the AI layer never touches the data directly. In Celvari’s architecture, agents reason and instruct; a governed execution layer runs the work under its own credentials and security policies. Only metadata, generated SQL, and prompts cross that boundary. Production data stays in your engine, in your environment — cloud, on-prem, or air-gapped — inside your borders.

Part 4 — The fifteen domains, mapped

Honest mapping needs honest vocabulary. We use four levels:

• Automated — the platform produces the required artifacts as a byproduct of normal operation.
• Accelerated — the platform does the heavy lifting; your team directs and approves.
• Supported — the platform provides real inputs, but the substance of the domain is human judgment.
• Organizational — the domain belongs to policy, law, or operating model; a platform can only make the underlying data trustworthy.

#	NDMO domain	Level	How it lands
2	Data Catalog and Metadata	Automated	Estate profiled and cataloged by AI; every new data product arrives pre-cataloged with ownership and column-level lineage
3	Data Quality	Automated	Rules in a registry mapped to tables, columns, and dimensions; a hard DQ gate runs before code is generated; failures stop the build
4	Data Operations	Automated	Full operational trace: every agent step, transformation, test, and approval logged and replayable
13	Data Classification	Automated	Every column classified on entry; PII and sensitive data flagged automatically at column grain
6	Data Architecture and Modelling	Accelerated	Models generated as versioned, readable SQL with lineage — living architecture documentation instead of stale diagrams
8	Business Intelligence and Analytics	Accelerated	Governed natural-language query with SQL shown on request; standard BI and API access to governed products
9	Data Sharing and Interoperability	Accelerated	Data products as governed, contract-like sources; open formats and APIs; sharing agreements remain yours
10	Data Value Realization	Accelerated	Cost and build-time tracked per data product, per agent — the domain most programs satisfy with a slide gets actual numbers
14	Personal Data Protection	Accelerated	Automated PII discovery and flagging, access enforcement, and audit trail feed the PDPL program; the legal program itself is yours
15	Data Security and Protection	Accelerated	In-your-environment deployment, the agent/data boundary, RBAC and SSO; your enterprise security program remains the frame
5	Document and Content Management	Accelerated	Agents ingest dictionaries and policy documents, extract terms and definitions with confidence scores, and publish them into governed metadata
1	Data Governance	Supported	The enforced path, stewardship queues, and evidence make the operating model workable — but owners, stewards, and accountability are appointed by you
7	Reference and Master Data	Supported	Canonical glossary definitions linked to real columns; conflicting definitions surfaced for a steward — the ruling is human
11	Open Data	Supported	Governed, quality-gated products are publishable by construction; what to publish is policy
12	Freedom of Information	Organizational	A legal process. The platform’s contribution is honest: when a request comes, you can actually find and trust the data

Three observations on the table.

The “Automated” rows are the expensive rows. Catalog, quality, operations evidence, and classification are where conventional programs burn the most person- months, because they demand estate-wide, always-current coverage. They are also exactly the artifacts that decay fastest when hand-made. Automating precisely these four is what changes the program’s economics.

The “Accelerated” rows are where audits are won. An auditor does not ask whether you have a security policy; they ask you to show that this dataset’s access is controlled and that transformation is what you claim it is. Accelerated domains put that demonstration one query away.

The “Supported” and “Organizational” rows are not a weakness of any platform. They are the point. Freedom of information is law. Open data is policy. Governance operating models are leadership. A vendor claiming to automate them is telling you something important about their credibility. What architecture changes is where your people spend their time: on those judgment calls, instead of on manufacturing the evidence for the other eleven domains.

Part 5 — What this means for a real program

We are deliberately not publishing a fictional case study with invented percentages. But the structural consequences of this architecture for an NDMO program are straightforward to reason about:

The evidence stops decaying. Because catalog, lineage, classification, and quality artifacts are produced by the work itself, they are current by construction. The permanent “chase the estate” tax — the thing that kills year-three programs — largely disappears.

Compliance stops competing with delivery. In the conventional model, the same scarce engineers either build data products or document the estate. When the documentation is exhaust, that conflict dissolves — and delivery itself gets faster, because the governed path is also the automated path.

The audit posture inverts. Instead of preparing for reviews with a documentation sprint, review-readiness becomes the resting state: the trace, the catalog, and the quality evidence exist because Tuesday happened.

Sovereignty is a property, not a promise. Because the platform deploys into your infrastructure and its AI layer never touches production data, residency and sovereignty questions are answered by the architecture diagram, not by contractual assurances about someone else’s cloud.

Part 6 — The honest boundary

No platform makes you NDMO compliant, and this paper should not be read as that claim. Compliance is carried by your organization: named owners, appointed stewards, ratified policies, legal processes, and leadership attention. Several domains are organizational forever, and correctly so.

What architecture determines is the cost and durability of everything else. The question to put to any platform — ours included — is not “are you NDMO compliant?” It is: “which artifacts does your architecture produce as exhaust, and which will my people still manufacture by hand?” The answer to that question, multiplied across 191 specifications and every year the program must survive, is the real total cost of the framework.

Where this goes

The NDMO standards are frequently described as a burden. We read them the opposite way: as the region’s clearest blueprint for what a trustworthy data estate looks like — arriving at precisely the moment AI has made trustworthy data the binding constraint on every national and corporate ambition. The organizations that treat the framework as an architecture target rather than a paperwork target will come out of this cycle with the strongest data foundations in the region, at a fraction of the conventional cost.

That conviction is why Celvari is bringing its headquarters to the Kingdom.

If you are facing an NDMO program — or midway through one that is grinding — bring us one of your priority specifications. Book a working session and we will show you, on a real requirement, what it looks like when the evidence writes itself.