Governance built into the model

Define a control once and bind it to the model. Classifications and policies follow the data down the lineage to every place it lands, so governance is part of the architecture rather than a document beside it.

Governance usually lives in a spreadsheet that describes the system from the outside and is wrong within a quarter. NeoArc makes governance part of the model itself, so it is connected to the real data and travels with it.

Classify what data is

Build the vocabularies your organisation governs by, classifications like PII, domains, lifecycle stages, as reusable taxonomies, then tag entities and properties with them. Mark a field as PII once, on the model, and that meaning is attached to the real thing rather than asserted in a document elsewhere.

Bind controls to where they apply

A policy captures what you do about data: retention, masking, encryption, access, residency, and more. You define it once and bind it where it applies, at five levels of precision: the whole model, a single source, a classification, an entity, or one specific property. Bind a control to a classification and it automatically reaches every field carrying that classification, including ones added later.

It flows to every projection

This is where model-first pays off for governance. Because every projection is wired back to the model, a classification or control set on a model field appears on every database column, schema field and API token that draws from it, all the way down the chain. You answer "is PII reaching this database, or this public endpoint?" by reading the architecture, not by interviewing teams.

Reach you can see

NeoArc shows you how far each policy and classification reaches across the model, so restructuring a vocabulary or tightening a control is a deliberate, visible act rather than a leap of faith. Governance becomes a computed property of the architecture, continuously, instead of a periodic audit that is out of date the day it is signed off.