Phylax documentation

Phylax is an automated parking-enforcement workflow for private lot operators. The end-to-end pipeline runs on operator infrastructure: ALPR capture -> KBA owner-data request -> ticket-letter generation -> payment reconciliation (via galanthus) -> human escalation on unresolved cases.

See the Phylax product page for the commercial model.

Primary legal references for the public data-flow description: section 39 StVG for KBA owner-data enquiries and GDPR Article 6 for lawful bases.

Contents

Phylax is configured per site. Most of the operational surface is deployment-specific, and first-deployment material is coordinated directly with the operator rather than published as generic reference. The sections below describe the public surface of the documentation. Sections marked (in preparation) are not published yet; the links lead to a placeholder page and can be scoped via procurement.

System overview (in preparation)

The pipeline stages - ALPR capture, owner-data enquiry (Kraftfahrt-Bundesamt / Flensburg), letter generation, payment reconciliation (via galanthus), escalation - and how each stage communicates with the others. Which stages run synchronously, which run on cadence, and what the operator sees in the escalation queue.

Deployment model (in preparation)

Phylax runs on operator infrastructure at the operator's site. This section documents the coordination surface: cameras and camera-hardware profiles, site networking, the operator-side Flensburg enquiry channel, the letter-sending service, and the reconciliation path. Per-operator deployment is coordinated through the commercial channel.

Camera and ALPR compatibility (in preparation)

Supported camera vendors, ALPR engines, capture formats, and the data contract between an ALPR source and the Phylax pipeline. At launch this section is sized to first-deployment hardware; additional camera profiles are added as the deployment base grows.

Letter pipeline (in preparation)

Template authoring for ticket letters, the enquiry-response handling for the KBA / Flensburg channel, the letter dispatch mechanism, and the reconciliation bookkeeping that ties an outgoing ticket to an incoming payment.

Sample redacted ticket letter (in preparation)

A redacted sample of a Phylax-generated ticket letter, showing the letter structure, the enquiry / response mapping, and the operator-branding slots.

KBA enquiry data-flow (in preparation)

The data-flow for the KBA owner-data enquiry step: what is sent, how the response is parsed, how plate-to-owner mapping is retained, and where the data lives at each stage.

Operator prerequisites (in preparation)

Checklist for a new operator: hardware, network, legal posture and permits, cameras, site access, and the commercial / DPA documents that need to be in place before a deployment begins.

Data-processing posture (in preparation)

How personal data flows through the pipeline (plate captures, owner data, ticket recipients, payment data), retention at each stage, and how the Phylax Data Processing Agreement applies. Legal bases: KBA owner-data enquiries under section 39 StVG; downstream processing under GDPR Art. 6(1)(f) legitimate interest. Sub-processors (where any) and their scope are listed on the DPA page.

Changelog

Release-by-release changelog for Phylax.

Evaluation path

Phylax is in first deployment. Evaluation for additional operators proceeds via procurement; evaluation requests use the subject line [Product evaluation] Phylax.

Early engagements are per-site deployments; Phylax is configured per site rather than offered as a self-service trial. A Data Processing Agreement is required for operators handling KBA personal data through Phylax. The DPA template is available as the Phylax Data Processing Agreement.

Source repository

Phylax does not have a public source repository at launch. Source licensing is negotiated per deployment; see procurement.