The EDM Reference Model defines a Domain as the discipline a document was created in — Quality, Clinical, Regulatory, Safety, Manufacturing. Serious life sciences organisations run several at once, and each discipline owns its own document structure. Quality owns SOPs. Clinical owns study documents. Regulatory owns submission content.
That ownership is supposed to decide who may change the document structure underneath a domain. In most document systems it is a label on a record and nothing more.
What “governance” usually means in practice
Ask what happens when a Clinical data manager decides to rename a document type under Quality’s SOP structure, and the honest answer in most deployments is: it renames.
Structure changes tend to sit behind a general administrator permission rather than one scoped to a discipline. Anyone who can configure, can configure everywhere. The domain label describes the intention and enforces nothing — which becomes visible the first time two disciplines share a system and one reorganises the other’s structure.
This is not usually negligence. It is that discipline-scoped permissions are more work than a single administrator flag, and nobody feels the absence until an organisation is large enough to have genuinely separate discipline owners.
How DnXT makes it a real boundary
In DnXT’s compliance domains, a permission is a stored, auditable fact: a domain, a person or group, and a level — none, read, write, approve, administer. Administrators grant them from a dedicated screen, and they can be granted to user groups rather than only to individuals, so the arrangement survives people joining and leaving.
Creating, renaming, deactivating or deleting anything in the document structure then requires administrator rights on the domain that owns it.
Ownership does not have to be restated at every level
Only a document type carries a domain directly. Subtypes and classifications inherit it from their parent — so “Quality owns SOPs” holds for everything beneath the SOP type without anyone having to say so again at each level.
This matters because document structures get deep. A model that needs a separate permission for every level is one that drifts out of alignment within a month, and then gets worked around.
One rule closes the obvious loophole: moving something into a different domain requires administrator rights on the destination as well as the source. Otherwise a Quality owner could move a document type into Clinical and carry on editing it from the other side — a privilege escalation that looks exactly like a routine reorganisation.
It only takes effect where somebody has set it up
This is the decision that makes a governance feature safe to deploy rather than an incident.
A workspace where nobody has been given a domain permission has not adopted domain governance, and its library carries on as before. Switching enforcement on everywhere would mean that on the morning of the release, every customer who had never configured a domain discovers nobody can change their document structure.
Administrators are exempt before any of the rules are consulted — so it is not possible to configure yourself out of your own workspace, which is the single most common way a permissions rollout goes wrong.
Governance is not the same as access control
Two things get confused constantly, and separating them makes both easier to reason about.
Domain governance answers who may change the structure — the document types, the classification tree, the shape of the library. It is a configuration question and it belongs to a discipline owner.
Per-document access answers who may see and act on a particular document. That is a separate mechanism, driven by roles, access rules and what each role may do at each stage of a document’s life.
They interact — somebody may own Quality’s document structure without being able to read every Quality document, and that is correct — but building them as one thing produces something that does neither job cleanly. DnXT keeps them separate on purpose.
A note on how these capabilities get delivered
One choice is worth mentioning for anyone running a platform assembled from several systems: the permissions are held by the part of the platform that uses them, rather than added to shared foundations.
Changing shared foundations forces a coordinated release of everything built on them. A governance feature that requires a whole-platform release is a feature that arrives late, or arrives in a bundle where it cannot be tested on its own. Keeping it local to the part that makes the decision is what lets it ship and be verified independently.
The question to ask a vendor
If a product claims a governance boundary, the useful question is not “is it implemented”. It is: what would visibly fail if it stopped working?
A permission check that is never actually consulted is indistinguishable, from the outside, from one that does not exist — except that it is worse, because everyone looking at the configuration screen believes they are protected.
So ask for the demonstration, not the description. Sign in as a Clinical user, open Quality’s document structure, and try to rename something. The answer takes thirty seconds and it is unambiguous.
DnXT builds eCTD publishing, submission planning, document management and dossier review software for regulatory operations teams. Book a demo to see domain governance enforced end to end against your own submissions.
