Skip to main content
At the end of every session, Masker produces a compliance report — the artifact you hand a prospect’s security team, your privacy counsel, or a HIPAA auditor. It is designed to answer one question: what PHI flowed through which systems, and how do we know?

​
Two formats, one source of truth

Every session report is generated as two consistent artifacts derived from the same event chain:

Masker Audit Schema v1 JSON

Machine-checkable. Used for automated compliance pipelines, programmatic verification, and integration with your SIEM or GRC tooling.

Auditor-ready HIPAA PDF

Human-readable. Structured for security reviewers, privacy counsel, and external auditors. Self-contained — no external links required to interpret it.
Both formats share the same merkle_root_hex. This is how you prove to an auditor that the PDF and the JSON describe the exact same event chain — the root hash is the cryptographic binding between them.

​
What the report contains

The PDF and JSON report surfaces the following sections, in this order:

​
The audit chain structure

Masker writes every detection event to an HMAC-chained, append-only journal:
Each event in the JSONL chain carries a sequence number, a link to the previous hash, and its own hash covering both content and provenance:
Each event records:
  • seq — monotonically increasing sequence number
  • kind — event type (detection, redaction_applied, etc.)
  • detector — which detector fired (e.g., ssn_v1, usphone_v2)
  • placeholder — the token assigned to this PHI span
  • prev_hash — SHA-256 hash of the previous event, linking it into the chain
  • curr_hash — SHA-256 hash of this event’s content combined with prev_hash
  • ts — ISO 8601 timestamp
What is not in any event: the original PHI value, the token value, or any payload contents. Leaking the audit log does not leak PHI. The log records that a detection occurred — not what was detected.

​
Fail-closed guarantee

If the journal append fails at any point, Masker returns AuditUnavailable and stops processing the request. There are no quiet drops. You will always know when the chain cannot be extended.

​
How to download your report

1

Open the Reports tab

In the Masker portal, navigate to the session you want to report on and click the Reports tab.
2

Select a format

Choose Download PDF for the auditor-ready report or Download JSON for the machine-readable Masker Audit Schema v1 record. Both are available from the same one-click interface.
3

Verify the merkle_root_hex

Both downloads display the same merkle_root_hex. Confirm they match before sending to an auditor — this proves the PDF and JSON describe the same chain.
You can also generate reports programmatically:

​
Verifying chain integrity

There are three levels of verification, from quickest to most rigorous.
Open the PDF. Check the Safe Harbor coverage table, redaction counts, and sample masked transcripts. This is what most stakeholders do for routine review.
Every report includes the audit root hash for the start and end of its window. In the portal, navigate to Audit log → Verify hash and paste the hash. Masker re-walks the chain and confirms the count and integrity. This is the screenshot you send an auditor for a quick proof.You can also call the API directly:
The response is:
The literal string "chain ok" in the message field is the programmatic signal that the chain is intact.
For an external auditor who needs to verify without trusting Masker’s infrastructure: request the audit key (provided under a separate signed envelope) and the raw JSONL event log for the session. The auditor can recompute the HMAC-SHA256 chain from scratch using any standard implementation.The masker audit verify command in the public repository performs this recomputation and can be run offline:
The MASKER_AUDIT_HMAC_KEY is set at deploy time. Never log it, never commit it, and treat it like a signing key. Losing it means future events cannot extend the chain.

​
Honest limits

  • Reports can only show what was logged. If audit.log_events is disabled (it should not be), the chain has gaps and the report says so explicitly.
  • Reports cannot verify upstream behavior. Masker proves what it sent to your LLM provider; it cannot prove what that provider did with it. The LLM provider’s own BAA and SOC 2 cover that leg.
  • The configuration snapshot in a report reflects the active policy at generation time, not at the time of every individual call within the window. The raw audit log itself records the policy version on every event.