Audit Logger Bundle Laravel Package

Technical Evaluation

Release under review — 1.1.0 (minor, non-breaking). The changelog contains a single functional change: AuditLoggerInterface is now registered in the bundle's configuration (PR #40), plus one new contributor. There are no removals, deprecations, or config-key renames, so nothing in the prior assessment is invalidated. The change is worth noting because it touches the one question the previous assessment treated as decisive — whether the audit-writing core has a seam separable from Symfony.

Architecture fit — poor to moderate, marginally improved. The bundle remains Symfony-specific in its integration surface: config/bundles.php registration, compiler passes, a configuration tree, and kernel event subscribers. What 1.1.0 establishes is that there is a named contract, AuditLoggerInterface, and that it is bound through the bundle's DI configuration. That is a genuine seam — a consumer-facing abstraction rather than a concrete service — but it is registered via Symfony's container configuration, not a PSR-11 factory, so it does not by itself make the writer usable from a Laravel service provider. It also tells us the interface is Symfony-namespaced and therefore not a drop-in for our own contract. Net: the "is it cleanly separated?" question moves from unknown to partially answered, and remains unresolved.

Integration feasibility — conditional, unchanged. The existence of an interface raises the odds that the write path can be extracted, and it gives our spike a concrete starting point: inspect what implements AuditLoggerInterface and how much of that implementation's constructor graph is Symfony services (event dispatcher, token storage, Monolog channel). If the implementation is thin and its collaborators are PSR-compatible, wrapping it is a few days. If the implementation reaches into the kernel or security context, fall back to the previously recommended path — treat the package as a specification and reimplement the write path natively against its schema.

Technical risk — high, with one small positive. The adoption signals are unchanged: 0 stars, 0 dependents, single-vendor government provenance, no issue triage community. Against that, 1.1.0 is a real data point on cadence — a scoped, reviewed, merged PR from a new contributor, which is weak evidence of an active maintainer pool rather than a single caretaker. Two releases and two contributors is not a support commitment, and the 2026-04-14 date still warrants verification against tag history. Licensing is unchanged: EUPL-1.2, copyleft obligations triggered on distribution rather than network use. Internal SaaS is likely fine; on-premise delivery or distributing a modified bundle requires source disclosure and legal sign-off.

Key questions — updated:

• What implements AuditLoggerInterface, and what does its constructor require? This is now the highest-value question and is answerable in an hour of reading.
• Is AuditLoggerInterface PSR-3/PSR-15-aligned, or does it carry Symfony-typed parameters in its signatures?
• Is the interface binding overridable via the bundle config (i.e. can a custom implementation be injected), or is it hard-wired to the bundle's default?
• What is the conformance claim — NEN 7513, verified by whom?
• Durability and tamper-evidence: append-only storage, hash chaining, WORM backend, or plain DB rows?
• Release cadence and named owner at VWS; is there a stated support window for the 1.x line?
• Is the write path inline with request handling or asynchronous?

Integration Approach

Stack fit. Unchanged: assume Laravel 10/11, PHP 8.2+, Eloquent, queue worker. The 1.1.0 interface registration lives in the bundle's Symfony config tree and does not create a Laravel-compatible binding. If we adopt anything from upstream, it is re-hosted: config becomes config/audit-logger.php, DI wiring becomes a service provider, Doctrine entities become Eloquent models or query-builder writes.

Migration path. Still greenfield — there is no incumbent to migrate. Sequence, lightly revised:

1. Spike (2–4 days, reduced from 3–5). Read the 1.1.0 config registration and the AuditLoggerInterface implementation. 1.1.0 shortens this: we no longer have to discover whether a seam exists, only how deep the implementation's dependency graph goes.
2. Specification extraction (1 week). Derive the audit event schema and retention policy from the package and from NEN 7513 directly. The schema remains the durable asset.
3. Native implementation (2–3 weeks). Service provider, append-only table with hash chaining, queued writer with synchronous fallback for security-critical events, read API for auditors.
4. Conformance review. Gated on compliance confirming NEN 7513 actually applies to us.

Compatibility. Version 1.1.0 is additive over 1.0.0 with no breaking changes; if we had vendored 1.0.0 the upgrade is a no-op. We should still pin nothing to the bundle and vendor it behind an internal AuditLogger interface so the dependency is swappable in one binding. Mirror the upstream interface's shape where it is sensible, but define ours in our own namespace — do not let a Symfony-namespaced type leak into application code. Continue to watch PHP minor-version support; a small government team may lag on 8.4+.

Sequencing. Do not block feature work. Ship the internal interface plus a no-op implementation early, agree the event taxonomy, then swap in the real writer as middleware plus model observers. Use the 1.x stability of the bundle as a reference-spec target only.

Operational Impact

Maintenance. We would still own any fork. 1.1.0 is mildly reassuring — a clean, reviewed contribution from a new author suggests the repo is not abandoned — but it changes the budget only at the margin: one engineer at a fraction of their time tracking upstream, plus a larger fraction maintaining code we did not write and cannot steer.

Support. No commercial support, no SLA, no dependents to consult. A new contributor is not a named support owner. Our escalation path for audit-logging defects still terminates internally, and a silent write failure is a compliance breach rather than a bug.

Scaling. Unchanged. Write volume and retention dominate, not request throughput. Partition or choose a time-series-appropriate store from day one; retrofitting a monotonically growing audit table is painful. Measure the synchronous-write round-trip before enabling broadly.

Failure modes to design against:

• Silent drop. Action succeeds, log write fails. Fail-closed for high-sensitivity events; dead-letter plus alerting for the rest.
• Queue loss. Lost job equals a missing audit record with no trace.
• Clock skew and ordering. Out-of-order entries break hash chaining under concurrency unless serialized per subject.
• Schema drift. Our Eloquent models diverge from upstream, foreclosing future adoption of upstream tooling.
• License contamination. Distributing a modified bundle to a customer triggers EUPL obligations; a build-pipeline check is cheaper than retroactive legal review.
• Interface drift. If we mirror AuditLoggerInterface, a future upstream signature change becomes a divergence we must track manually — one more reason to keep our contract independent.

Ramp-up. Low to consume an interface, moderate to own the implementation. Expect 1–2 weeks for whoever takes the audit domain, most of it regulatory context rather than code.

TPM recommendation. Unchanged in substance, marginally more confident in the reference-spec path. Do not adopt the bundle as a dependency. 1.1.0 confirms a usable interface seam exists, which makes the specification-extraction step cheaper and slightly de-risks the spike; it does not change the licensing, support, or adoption picture. Use it as a reference specification for a small native implementation behind an internal interface, gated on compliance confirming NEN 7513 applies to us.