See the data move.
Not just the claims.
Seven diagrams trace exactly what happens at the moment of access or share: where DataGuard sits, what the policy engine decides, how one source becomes a per-role view or per-recipient version, and how each decision turns into audit-ready evidence.
These flows are illustrative of the product's mechanics. Component names map to function, not to a literal service topology, and anything not yet shipped is marked planned.
A control plane.
Not another store.
DataGuard is a control plane, not a store. Your documents stay in your systems. At the moment of access or share, DataGuard decides what this subject may see, produces that view or version, and records the basis. Then it gets out of the way.
by role
intercept
decision
data discovery
redact / scope
record
One file, two roles,
different content.
No pre-split copies, no separate redacted files to manage. The role-specific view is produced at request time from the single source, and the decision is logged before it is shown.
- 1User · Billing → Enforcement
Open patient_record.pdf
- 2Enforcement → Policy engine
Decision request: subject, resource, action
- 3Policy engine → Classifier
What sensitive entities are in this doc?
- 4Classifier → Policy engine
SSN, diagnosis, billing codes
- 5Policy engine → Enforcement
Allow billing codes, redact SSN + diagnosis
- 6Enforcement → Storage
Fetch source
- 7Enforcement
Apply per-role transform
- 8Enforcement → User
Billing-scoped view, diagnosis hidden
- 9Enforcement → Evidence ledger
Log who, what, basis, policy version, hash
- Patient
- Jane R.
- Billing codes
- 99213 · 80053
- SSN
- redacted
- Diagnosis
- redacted
- Patient
- Jane R.
- Billing codes
- 99213 · 80053
- SSN
- •••-••-1782
- Diagnosis
- Type 2 diabetes
Each recipient
is a policy context.
The same source yields a different, scoped version per recipient: content, not just a watermark, and every version is recorded. Nothing leaves un-governed.
- 1Staff → Enforcement
Share claim_file to Insurer + publish summary
- 2Enforcement → Policy engine
Evaluate per recipient: context, agreement
- 3Policy engine → Transform
Insurer = claim fields only; Public = de-identified
- 4Transform → Insurer
Insurer-scoped version
- 5Transform → Public report
De-identified public version, metadata stripped
- 6Enforcement → Evidence ledger
Log both decisions, delivery, access events
single source
per-recipient
claim fields only
de-identified · metadata stripped
The policy isn't
written from a blank page.
Discovery drafts the policy, a human approves it, and it compiles to live rules. Time-to-value is the onboarding scan, not a six-month GRC project.
M365 · Google · Clio
find sensitive data
roles × data × actions
adjust / approve
to enforcement rules
every access & share
every decision
Evidence is a byproduct
of enforcement.
Every decision is hash-chained and mapped to the controls a regulator will ask about, exportable as an audit pack, not reconstructed after the fact.
who · what · basis · policy v · time
tamper-evident
The same three leaks,
with the product in the path.
The three scenarios from the narrative, now as flows: the red path ends in exposure; the path with DataGuard ends in a governed view or version and a logged decision.
The public report with hidden PII
The insider look
The wrong recipient
Subject × resource × action.
Always, and always logged.
Every decision is attribute-based: who the subject is, what the resource is classified as, and which action they are attempting. There is no hardcoded rule list behind it.
role + attributes: department, clearance, region, engagement
classification: PHI, PII, privileged, public + container
view · share-internal · share-external · export · AI-read
The per-role redaction mechanic exists in legacy ECM and vaults. What is unbuilt elsewhere is this bundle: everyday documents, internal and external, with a compliance-grade decision record, on the tools you already use.