Redactor Onnx Laravel Package

Technical Evaluation

Architecture fit. The release adds an onnx recogniser driver that implements the redactor's existing BatchRecognizer contract, so it slots into the current recogniser abstraction rather than changing the pipeline. Two properties matter to a TPM:

• In-process inference replaces a sidecar hop. TransformersPHP runs a token-classification model inside the PHP process. This removes a network dependency, a separate deploy target, and a serialization boundary — a meaningful simplification of the production topology, at the cost of moving model risk into the request-serving process.
• Batch semantics align with the payload shape. Classifying every prose value in a payload in one model call is the right primitive for a redactor: fixed per-request overhead is amortised, and the driver's windowing at whitespace handles long texts that exceed the model's context.

The label-mapping layer (model labels → profile names the redactor already uses) is the correct seam: it means profiles, policy, and downstream redaction behaviour stay stable while the inference backend changes. That is the difference between a driver swap and a rewrite.

Integration feasibility. Moderate. Requirements introduced: a Composer dependency on TransformersPHP, a working ONNX runtime (native library/extension or FFI binding), a model artifact on disk, and a writable cache path. The redactor:onnx:warm command is the right shape for deploy-time provisioning, but it is also the main integration question — whether it runs at image build (preferred: hermetic, no egress at deploy) or at container start (risks slow boots, network dependence, and partial availability across replicas).

Technical risk.

Key questions. Which model and weights, under what licence, and how is the version pinned and checksummed? What is the token window and what happens at and beyond it? Is the recogniser invoked synchronously in-request or via a queue, and what are the p95/p99 latencies versus the current sidecar? What is the measured RSS delta per worker and the cold-start time after warm? Is the ONNX session safe under concurrent use in a single worker? How are character offsets mapped back for span replacement, and do they survive multibyte UTF-8? What is the documented behaviour when the model is absent, corrupt, or the runtime fails to load? Which PHP versions and OS/arch combinations are supported and tested? What is the rollback story to the previous recogniser? And, given this is a v1.0.0 native path, what field evidence exists beyond the maintainer's own environments?

Integration Approach

Stack fit. Strong, assuming the host application is already on the redactor's driver abstraction. Configuration-driven driver selection keeps the change small: publish config, select onnx, point at the model path, run redactor:onnx:warm. The artisan command integrates naturally into existing deploy pipelines and container build steps, which is a better fit than a sidecar that needs its own service definition, health checks, and network policy.

Migration path. Do not cut over in one step.

1. Spike in a single non-production service; measure latency, memory, and output equivalence against the current recogniser.
2. Bake, don't fetch. Run redactor:onnx:warm during image build so the model is in the layer, immutable and versioned with the image.
3. Shadow mode. Run the ONNX driver alongside the incumbent on sampled traffic, diff the span sets, and treat any divergence as a defect. This is the cheapest way to surface label-mapping and window-boundary bugs.
4. Feature-flag per environment, then canary a single production replica or a low-risk tenant.
5. Ramp traffic, keep the old driver wired and switchable by config for at least one release cycle.
6. Decommission the sidecar only after the ONNX path has held through a full traffic cycle.

Compatibility. Gate on: PHP minor version support matrix from TransformersPHP; presence and version of the ONNX native runtime in the base image; memory_limit headroom against measured model RSS; writable cache path and its persistence across deploys; and CPU architecture parity between CI and production. Alpine/musl images are the most common surprise.

Sequencing. Model artifact governance (version, checksum, registry) should land before the driver is enabled in production, not after — otherwise the first model update becomes an untracked production change. Observability (inference latency, failure counts, fail-closed events, model version in logs) should land in the same release as the driver, because this class of failure is otherwise invisible until an audit finds unredacted output.

Operational Impact

Maintenance. The team acquires a new class of deployable artifact: model weights. That implies a versioning policy, a checksum/integrity check, storage or registry, and a documented process for model upgrades independent of code releases. It also couples the redactor's correctness to the release cadence of two upstreams (TransformersPHP and the ONNX runtime), so dependency pinning and a periodic upgrade rehearsal become recurring work.

Support. Failures move from a separately observable service to application logs and worker behaviour. A runbook is required covering: warm failing at build or boot; model file missing or corrupt; native runtime load errors; OOM kills; and the decision procedure when inference fails in production. Include the exact config and log lines that identify the active model version.

Scaling. Inference is CPU-bound per worker, and memory scales with worker count — the opposite of the sidecar model, where a fixed pool of model processes served all workers. Budget for higher per-replica cost and plan horizontal scaling on CPU saturation rather than request rate. Bulk or backfill redaction should go through queue workers with their own concurrency limits, not the web pool. Without GPU support, throughput is a function of core count; get real numbers before committing to a capacity plan.

Failure modes.

• Fail-open redaction (highest severity): inference error yields unredacted output rather than a blocked response. Verify and instrument explicitly.
• Silent partial redaction: entity straddling a window boundary, or text truncated past the context limit, produces output that passes validation but leaks.
• Native crash: takes down the request/worker with no application-level handling.
• Memory exhaustion: pool-wide OOM under concurrency spikes.
• Cold start: replicas serving before the model is loaded; mitigated by build-time baking.
• Model/driver drift: label-mapping changes in a new model version silently reclassify entity types.
• Deploy-time network dependency: warm fetching at boot fails in egress-restricted environments.

Ramp-up. Roughly one to two sprints for an engineer familiar with Laravel but new to in-process ML: tokenisation and offset alignment, ONNX runtime platform quirks, and model artifact handling are the unfamiliar parts. The abstraction keeps the application-side surface small, which helps. Investment should go into the shadow-mode diff harness and the failure-mode runbook — those two artifacts are what convert a v1.0.0 native inference path from "works on my machine" into something supportable in production.