Argument 2How it works

Two packages, one seam.

The package installed in your production org contains no DML against customer objects. Not gated. Absent. Write capability lives in a second package that is only installable in sandbox and scratch orgs. The two meet at a metadata registry, never at an import statement.
The topology

One codebase reads. A separate codebase writes. They meet at a metadata registry.

fig. 02 · production ↔ registry ↔ sandbox
fig. 02two packages · one seam
Production orgread-only
orgwarden-core
INV-2
SCHEMA · DETECT · ACCESS · CONTENT
dispatcher · registry client · records
write code against customer objects
ABSENT · enforced by static scan
Masking templates
pure data · REDACT Job_Request__c rows
Status = Template · inert without handler
Sandbox orgread + write
orgwarden-core
same code as production
orgwarden-redact
INV-3
RedactHandler · the only DML in the product
WRITE · sandbox-only at runtime
DML
Sandbox customer objects
receives DML from RedactHandler
only after dry-run + write-gate
Handler__mdtthe seam · INV-4
JobTypeHandlerClassIsWriteAvailable in
SCHEMAcore.SchemaHandlerreadprod + sandbox
DETECTcore.DetectHandlerreadprod + sandbox
ACCESScore.AccessHandlerreadprod + sandbox
CONTENTcore.ContentHandlerreadprod + sandbox
REDACTredact.RedactHandlerwritesandbox only
On refreshtemplates copy from prod to sandbox · the redact package does not · clones land as Blocked / AWAITING_HANDLER until the admin installs redact
A
orgwarden-core (production-safe)
Every read handler: SCHEMA, DETECT, ACCESS, CONTENT. Dispatcher. Metadata registry. Contract objects. Zero Database.insert, .update, or .delete against customer objects, enforced by static scan in CI.
B
Handler__mdt (the seam)
Custom metadata that maps JobType → HandlerClass. Core dispatches REDACT jobs by looking up a row it does not own. If the row's handler class is not loaded, the job parks in Blocked / AWAITING_HANDLER and never Failed. That state is load-bearing.
C
orgwarden-redact (sandbox-only)
One handler class. The only place in the product with DML against customer objects. Runtime hard-gate: Organization.IsSandbox == true, or the dispatcher throws before a chunk ever runs.
Sandbox refresh, drawn

The five steps from a sandbox refresh to a redaction. The dispatcher never guesses. It parks the job until the missing piece arrives.

Masking templates live in production as pure data, so no write code is needed to hold them. On refresh they arrive in the sandbox already copied. Then this sequence runs when an admin starts it. Nothing runs on refresh by itself: there is no scheduled job and no post-copy hook.

fig. 02csandbox refresh · five steps
Step 1template
Templates copied
Refresh mirrors production into sandbox. Templates arrive. The redact package does not.
Step 2requested
Clones requested
An admin clones a template to Requested, from the Org Warden app or by importing a Console-composed definition. The dispatcher walks the queue.
Step 3blocked
Blocked, not failed
No handler for REDACT yet. The job parks in Blocked / AWAITING_HANDLER. Nothing destructive is attempted.
Step 4install
Redact installed
An admin installs orgwarden-redact into the sandbox. The registry now resolves REDACT.
Step 5ready
Dry-run, then gate
Blocked jobs re-dispatch. The dry-run runs first. Only then does the five-check write gate open.
Records are the API

Every job is a queryable record.

A job is a Job_Request__c with Job_Target__c rows and Job_Result__c rows. Both packages work with zero control-plane connectivity. The web app orchestrates and mirrors. It never owns. If Org Warden's Console vanished tomorrow, you could keep dispatching jobs from the Salesforce UI.

Job_Request__cJob_Target__cJob_Result__cHandler__mdt
Downstream

A finding is a record, so a control can be scoped from it.

Because findings land as queryable records inside your own org, the list of fields that hold PII is available to your reporting, your change process, and your admins without an export from us. That list is what a control needs. Encryption at rest can be mandated on exactly those fields. Field-level security can be trimmed against the access map that produced them. Field audit history can be enabled where regulated data actually sits rather than everywhere or nowhere.

Org Warden applies none of it. Core is read-only in production by construction, so every change lands through your own change process, with your own approvals. What Org Warden provides is the scope, the evidence behind the scope, and a drift row the next time something lands outside it.

Free baseline scan

Scan one org free. See where your PII lives.

No install-to-buy. You get a Baseline Report (the same artefact paying customers get) for one Salesforce org. Metadata-only, always. Your data never leaves your org.

Work email · we reply within 1 business day
Next argument · 3
Security. What crosses the wire, and what doesn't.
INV-1 through INV-8. Eight testable invariants that make the whole thing verifiable.