Ten sources. One Secure Agent Server. One cockpit.

The foundation

Built on the agent you already own, in the region you already chose.

Informatica’s customer-hosted runtime reads each system through its CDI connector — the whole catalog or a finite list of tables — and stages an incremental, read-only copy on the Secure Agent Server. Credentials live in IDMC Administrator, never in the cockpit.

A separate module follows table-and-column bindings to each system’s document store using the vendor’s documented interface — ContentVersion in Salesforce, ArchiveLink in SAP, File Cabinet in NetSuite, Microsoft Graph for SharePoint — so scanned invoices and case files are in scope, not just the rows that point at them.

An embedded analytical database plus an object store: read-only, versioned, on your host. Because everything downstream is computed from it, the corpus is a first-class screen, decided once and inherited by every other screen.

PIIScan 0.6.0 brings rules with published validators, a confidence floor, a deterministic rule fingerprint, two-key masking, OCR for scans and images, and a chained log. Discovery never modifies a source; document remediation is delivered as clean copies.

Erasure and retention execute where the data lives — Salesforce Privacy Center for Salesforce, native tools for the other systems. The cockpit reads Privacy Center telemetry back and runs a residual scan under the same fingerprint, so “done” is measured, not declared.

One pack per run and per request: fingerprint, counts, validator rejections, chained log, Privacy Center telemetry and the residual report — retained for a year or longer, never containing an original value. Optionally recorded into Informatica CDGC for classification, lineage and policy.

The life of a finding

Seven states, four places it can be deliberately left alone.

A candidate is matched, then validated against its published check, then measured against your confidence floor. A reviewer confirms it. It becomes policy scope. Privacy Center enforces it. A residual scan verifies that nothing remains. At four points along that path — failed validation, below the floor, rejected by a reviewer, under a legal hold — data is found, recorded and deliberately left alone, with the reason in the chained log.

The discipline is not in what the engine finds. It is in what it declines to act on, and in the fact that every one of those refusals is written down with a reason. That is the difference between a scanner and a control.

Design standard

Seven rules the cockpit follows.

• One actionOne primary action per screen. The button that changes state is the only filled button on the page.
• The rail is the journeyCorpus → Import → Scan → Review → Attest → Retention → Requests → Erasure → Evidence → DPDP. The left edge is the order of work.
• No value shownRecord IDs are enough to act. The screen says so, once, where it matters.
• Decide in the rowApprove or reject without leaving the row; the mouse is optional.
• Numbers say what they are“Floor”, not “average confidence”. “Rejected by validator, never reported”, not “stripped”.
• Danger needs intentMasking needs two keys. Bulk approval acts only on undecided rows and is a quiet button.
• Whitespace over bordersSpacing does the grouping. One shade, one radius, one hairline.

Screens and architecture per PDI engineering’s Kestryl Cockpit for DPDP design review, 3 September 2026. Engine behaviour per PDI’s published Kestryl pages and the PIIScan 0.6.0 operator documentation. Privacy Center capabilities per Salesforce Help and Object Reference.