Redactor Onnx Laravel Package

Product Decisions This Supports

• Shipping PII redaction as a product capability, not an infrastructure project. The onnx driver runs a token-classification model inside the PHP process via TransformersPHP, so we can offer "prose is classified and redacted before it leaves the app" without standing up or operating a Python inference sidecar. That removes an entire service from the architecture review, the on-call rotation, and the security questionnaire.
• Build vs. buy for data-masking. This is the concrete alternative to a hosted redaction/PII API. Decision inputs it changes: per-record vendor cost becomes per-CPU-cycle cost; a vendor DPA/subprocessor review becomes an internal model-artifact review; data-residency questions collapse because the payload never crosses a network boundary.
• Unblocks roadmap items that were previously gated on redaction. Most obviously: sending prompts/telemetry to third-party LLM providers, shipping support-ticket and log-export features to regulated customers, and analytics exports containing free-text fields. Also relevant to self-hosted/on-prem editions where calling an external API is a non-starter.
• Makes redaction cost predictable at the payload level. Because the driver implements BatchRecognizer, every prose value in a payload is classified in a single model call rather than one call per field. That is a direct input to pricing tiers, rate limits, and latency SLOs — we can model cost per request instead of per entity.
• Enables per-profile accuracy ownership. Model labels map onto the names the redactor's existing profiles already use, so we can tune which entity types are redacted per plan/customer without forking the driver.
• Turns deploy-time model provisioning into a known, schedulable step. redactor:onnx:warm means we can treat model download/load as part of the release pipeline rather than absorbing a cold-start penalty on the first production request.

When to Consider This Package

Adopt when most of the following hold:

• The application is Laravel/PHP and the redaction decision point is already in that request path — adding a sidecar would mean new network hops, new failure modes, and a new deploy target.
• Data cannot leave our boundary (regulated customers, on-prem, contractual prohibition on third-party processing), or the vendor per-record pricing does not survive our volume model.
• Throughput is moderate and latency budget is comfortable with CPU inference in-process; the single-call-per-payload batching behaviour fits our typical payload shape (many short prose fields).
• We are willing to own the model artifact: its size in the container image or artifact store, its memory footprint under PHP-FPM concurrency, and its accuracy as our responsibility rather than a vendor's.
• We need entity-level redaction (names, locations, and similar token-classified types) rather than regex/format-only masking, and we are prepared to build a labelled evaluation corpus to set our own precision/recall bar.

Look elsewhere when:

• Volume or latency requirements imply GPU inference or sustained high concurrency; in-process PHP inference is the wrong shape for that, and a dedicated service is cheaper to scale.
• Accuracy must track the state of the art continuously, or a vendor SLA/indemnity is a procurement requirement — owning a pinned model means owning its drift.
• Deployment targets are memory-constrained (small FPM pools, shared hosting) or cannot accommodate downloading and storing model weights at deploy time.
• Strict determinism and auditable third-party processing are required by compliance; "we run it ourselves" is sometimes a harder story to evidence than "we use an audited vendor."
• The stack is not Laravel, or the redaction boundary is naturally outside PHP.

How to Pitch It (Stakeholders)

For executives: this closes the gap that has been blocking our redaction-dependent roadmap — we can now mask prose PII inside the application with no new service to run, no third-party processor to onboard, and no customer data crossing our boundary. Commercially it converts a per-record vendor fee into infrastructure we already pay for, and it makes self-hosted/regulated deals sellable. The costs are real but bounded: model artifacts enter our release pipeline, inference memory becomes a capacity-planning input, and accuracy becomes our number to defend rather than a vendor's.

For engineering: it is a drop-in. The driver implements the existing BatchRecognizer contract, so it slots into the current redactor pipeline without touching call sites; the whole payload is classified in one model call, long texts are windowed at whitespace boundaries, and model labels are mapped to the profile names we already use. Add redactor:onnx:warm to the deploy pipeline to pay the download/load cost before traffic arrives. Two things to plan for: a golden corpus with expected entities so we can gate releases on precision/recall rather than vibes, and a load test under realistic PHP-FPM concurrency to establish the memory ceiling and the latency profile per payload size. Treat the pinned model version as a dependency we upgrade deliberately, not incidentally.