The routing front door for Philter
Philter Router is the single front door in front of one or more Philter engines. Hand it a file and it selects the redaction policy and the engine from the file's attributes, then forwards the file to Philter for redaction.
A clinical record, a signed contract, and a support export each call for different redaction. One blunt policy applied to everything over-redacts some files and under-redacts others, and hard-coding which policy to use pushes that decision into every caller. Philter Router makes the decision once, in one place: it reads each file's attributes and routes it to the policy and engine built for it, with a default that redacts anything it does not recognize.
Each file gets the policy chosen from its own attributes, not one hard-coded by the caller. Onboard a new file type by adding a route to the config.
Philter Router is a single Java application driven by one YAML file. Build it, point it at your Philter engines and routes, and run whichever entry points you enable.
# Build the runnable jar (Java 25)
mvn package
# Run it against your config
java -jar target/philter-router.jar router.yaml
The examples directory ships complete, commented configs (minimal, folder watching, HTTP API, classifier routing, and network shares). Every option is documented in the installation guide.
Each route matches on content type (detected with Apache Tika from the file's actual bytes, not just its extension), filename extension, containing directory, and an optional classification. Within a route every field must match; a list inside a field is any-of. Routes are ordered and the first match wins.
An optional tier sends the extracted text to a local LLM (Ollama) and routes on the label it returns, for content that filename and directory cannot distinguish. The classifier runs at most once per file and the result is cached. Extracted text is classification-only: never written as output, never logged.
A folder-watcher redacts files as they land in watched directories (polling for network shares, low-latency notify for local disks); a Philter-compatible HTTP API redacts on request. Enable either or both from one config.
The HTTP API mirrors Philter's filter contract, so the Philter SDK and existing Philter clients work against it unchanged. It is send-only: redact and return.
A mandatory default policy catches every file that matches no route, and the router refuses to start without it, so no file is routed around redaction.
Runs inside your own infrastructure and forwards to your own Philter engines. Files and the text extracted for routing never leave your perimeter.
Built to run as an on-prem service or a Windows service, with the signals an operator needs to run it with confidence.
Every routed file is recorded to a structured audit log alongside the operational logs, so you keep a record of which policy and engine handled each file. Logs go to stdout by default; set router.log.dir to also write rolling files.
The HTTP API is a Spring Boot application with Actuator: GET /actuator/health for liveness and readiness and GET /actuator/prometheus for metrics, plus an OpenAPI 3 spec at GET /openapi.yaml.
Configuration is validated at startup and the router refuses to start when it is incomplete or unsafe, for example when the mandatory default is missing.
Routing is tiered, so expensive work runs only when a cheaper signal has not already decided the route: a file that fails a cheaper tier never triggers a more expensive one. A file that matches no route, whose language is not allowed, or whose classifier is unavailable, falls to a mandatory default policy, so nothing is routed around redaction.
If something here isn’t covered, get in touch and we’ll answer.
?p=.Three ways to get going: deploy the open source yourself, spin it up from a cloud marketplace, or work with our team directly. Pick the path that fits.