Philterd

Talk to the Team

Tell us about your stack and the privacy problems you're trying to solve. We typically respond within one business day.

Prefer email? support@philterd.ai

Prefer to skip the form? Pick a time on our calendar →
or send a message

Please do not enter PII or PHI in this form. If you need to share an example, use a sanitized one.

Reference and how-to

Authoring Redaction Policies with PhiSQL

PhiSQL is a readable query language that compiles to a Phileas redaction policy. An introduction to the syntax and how it maps to the policy JSON.

A redaction policy is a JSON document that tells Philter and Phileas what to detect and how to transform it. The JSON is precise, but it gets verbose, and a small policy change can be hard to read in a diff. PhiSQL is the alternative: a readable, declarative query language that compiles to that same policy JSON. It is an authoring language, not a separate engine. If you have written SQL, it will feel familiar.

This guide introduces the syntax and shows how it maps to the policy. For the full grammar and every supported statement, the PhiSQL specification is the canonical reference; this is the on-ramp. If you would rather start from the JSON, see Writing your first redaction policy.

PhiSQL compiles to a policy

A PhiSQL document is a sequence of statements. The smallest useful one names a policy and gives one rule:

POLICY ssn_only;
REDACT SSN WITH MASK;

That compiles to exactly this redaction policy JSON:

{
  "identifiers": {
    "ssn": {
      "ssnFilterStrategies": [
        { "strategy": "MASK" }
      ]
    }
  }
}

The two are equivalent. PhiSQL is the readable form; the JSON is what Philter and Phileas load. Seeing them side by side is the whole idea: a REDACT <entity> WITH <strategy> statement becomes an entry under identifiers with its filter strategy.

The core statements

A handful of statement shapes cover most policies.

Name the policy. Every document starts with a policy name:

POLICY clinical_notes;

Redact an entity with a strategy. The strategy is how a detected value is transformed:

REDACT SSN WITH MASK;
REDACT CREDIT_CARD WITH LAST_4;
REDACT EMAIL_ADDRESS WITH HASH_SHA256;

The strategies map to the ones in the schema: REDACT, MASK, ENCRYPT, FPE_ENCRYPT, HASH_SHA256, SHIFT, LAST_4, and more.

Pass strategy options. Strategies take named parameters:

REDACT SSN WITH MASK(maskCharacter = '#', salt = TRUE);
REDACT DATE WITH SHIFT(days = 30, futureDates = FALSE);

Cover several entities at once, or give one entity more than one rule:

REDACT SSN, EMAIL_ADDRESS WITH MASK;

Apply a rule only under a condition. A WHERE clause gates a strategy on confidence, so you can treat high- and low-confidence detections differently:

REDACT CREDIT_CARD WITH LAST_4 WHERE CONFIDENCE >= 0.9;
REDACT CREDIT_CARD WITH REDACT WHERE CONFIDENCE < 0.9;

Detect names with a model. DETECT PHEYE wires in the PhEye name models, either against a service or a local model directory:

DETECT PHEYE
  LABELS ('person', 'email address', 'phone number')
  MODEL '/models/ph-eye-pii-base'
  WITH REDACT;

Ignore known-safe terms across the whole policy:

IGNORE TERMS ('TEST', 'EXAMPLE', 'SAMPLE');

A worked policy

Putting it together, a small but realistic policy reads top to bottom:

POLICY support_transcripts;

REDACT EMAIL_ADDRESS WITH MASK;
REDACT PHONE_NUMBER WITH MASK;
REDACT CREDIT_CARD WITH LAST_4 WHERE CONFIDENCE > 0.85;
REDACT SSN WITH REDACT;

DETECT PHEYE LABELS ('person') WITH REDACT;

IGNORE TERMS ('Acme Corp');

Each line is one decision, in plain reading order. The compiled JSON expresses the same policy in the structure Philter and Phileas load; PhiSQL just makes the intent easier to read, review, and diff.

When to use PhiSQL

PhiSQL is one of three ways to author the same policy. Choose by how you prefer to work:

  • PhiSQL when you want policies that read like code, live in version control, and review cleanly in a diff. Compile them to JSON as part of your build.
  • Hand-written JSON when you are already generating policies programmatically or need a field PhiSQL does not yet surface. Start from Writing your first redaction policy.
  • The Redaction Policy Editor when you want to build and tune a policy visually with no code at all.

All three produce the same policy, so you can move between them.

Where to go next

Frequently asked questions

Is PhiSQL a separate engine or runtime?
No. PhiSQL is an authoring language, not a runtime. It compiles to the same Phileas redaction policy JSON that Philter and Phileas already execute. Anything you can express in PhiSQL is just a more readable way of writing that JSON.
Do I have to use PhiSQL?
No. You can hand-write the policy JSON, build it visually in the Redaction Policy Editor, or write PhiSQL and compile it. Every path produces the same policy. PhiSQL is for people who would rather read and diff a few lines of a query language than a JSON tree.
Where is the full PhiSQL reference?
The canonical, versioned specification (grammar, catalog, and worked examples) is the PhiSQL docs. This guide is an introduction; that site is the reference.

Related reading