Entity Audit Bundle Laravel Package

Product Decisions This Supports

• Compliance and audit-trail commitments. Entity-level revision history (“who changed what, when, and to which field”) is the backbone of GDPR/CCPA subject-access responses, SOX-style change controls, HIPAA-style access review, and internal fraud/insider investigations. If audit trails are on the roadmap or a customer/security-questionnaire requirement, this is the category of tool that satisfies it.
• Build vs. buy vs. fork. This is a maintained fork of the long-established Sonata EntityAuditBundle lineage. The realistic decision is not “adopt vs. build from scratch” but “adopt a fork vs. build thin Doctrine listeners in-house.” In-house listeners look cheap for a week and expensive for two years — revision tables, revert logic, and relation handling are the parts teams underestimate.
• Data-recovery and versioning features. Enables product features beyond compliance: “restore this record to its state on March 3,” diff views in admin, change-history tabs on detail pages, and safe rollback of bad bulk imports or migrations.
• Support and incident response. Cuts mean-time-to-diagnose for “the price changed and nobody knows why” tickets. This is a measurable support-cost lever, not just a checkbox.
• Architecture fit is a gate, not a detail. Despite the brief framing this as a Laravel package, this is a Symfony bundle for Doctrine ORM. It is not usable in an Eloquent/Laravel codebase. That single fact should dominate any roadmap conversation before scope, effort, or licensing are discussed.

When to Consider This Package

Adopt-candidate when all of the following hold:

• The stack is Symfony + Doctrine ORM; Laravel/Eloquent teams should stop here and evaluate owen-it/laravel-auditing or spatie/laravel-activitylog instead.
• The audit requirement is entity/row-level history with revert, not tamper-evident logging, not event sourcing, not user-session analytics.
• The team accepts LGPL-2.1. In PHP this needs a legal read: PHP include-style linking makes the “separate work” argument weaker than in C, and a fork you modify carries distribution obligations. Get sign-off rather than assuming.
• You can tolerate low external adoption (effectively no stars, no dependents) and are willing to pin a version, vendor the code, and own patches. Treat the fork as an internal dependency with an external upstream, not as a community-supported library. Update from v2.1.0: the fork has now merged upstream 1.23.0, which is real evidence of a functioning upstream-tracking cadence — a modest but genuine de-risking of the “fork quietly dies” scenario. It does not change the adoption profile; it makes the “own it deliberately” plan more credible.
• Write volume is compatible: audit tables roughly double write amplification on audited entities. Confirm the high-traffic tables are either excluded or the DB can absorb it.

Look elsewhere when:

• You need a vendor SLA, security review evidence, or a supported release train — a low-adoption fork cannot supply these, even one that tracks upstream; budget internal ownership and read the upstream changelog yourself, because merge commits do not summarize behavior changes.
• The requirement is immutable/tamper-evident audit (hash chains, WORM storage) for regulated environments — this records revisions, it does not prove non-repudiation.
• You need sub-second querying at scale over billions of revisions, or cross-entity event correlation — that is an event-streaming/warehouse problem.
• Laravel, Eloquent, or non-Doctrine persistence is in play, or the team is on an ORM migration path.
• A SaaS audit log (e.g., a managed compliance platform) is already contracted and the internal history is redundant.

How to Pitch It (Stakeholders)

One-line summary: A free, mature-lineage audit-trail component for Symfony/Doctrine apps that gives record-level history and revert — high value, low license cost, and now demonstrably still pulling in upstream fixes, but it must be owned internally because the community around this fork is essentially empty.

For executives: Audit trails are recurringly requested by enterprise buyers, security questionnaires, and auditors. Buying or building this is a one-time cost against a repeated sales blocker. The component itself is free (LGPL-2.1), derived from a long-standing open-source project, and the latest release is a straight merge of the upstream 1.23.0 line — so the maintenance story is “small but alive,” not “abandoned.” The honest framing: cheap to adopt, cheap-ish to own, but it is not a supported product — we should staff roughly a fraction of an engineer to track upstream and patch, and we should not put it on a path where a compliance auditor asks “who maintains this?” The v2.1.0 merge is a good data point that our upstream-tracking runbook would actually work, not a reason to reduce that staffing.

For engineering: Drop-in Doctrine integration, revisions stored in companion audit tables, revert and diff support. v2.1.0 contains no new features and no breaking changes — it is an upstream sync to 1.23.0, so treat it as a maintenance signal rather than a capability upgrade; read the upstream 1.23.0 changelog for behavior deltas before bumping a pinned version. Two decisions still gate us: (1) license review of LGPL-2.1 in a PHP include context, and (2) a timeboxed spike on write amplification and relation handling for our two largest audited entities. Recommend pinning a version, vendoring or mirroring the repo, and adding a short internal runbook that includes “review upstream merges on each release” — if the spike fails or legal blocks, the fallback is thin custom Doctrine listeners scoped to the three entities that actually matter.

Recommendation: Proceed to a timeboxed technical and legal spike in the next sprint; do not commit to the roadmap until both clear. If it clears, list it as an internal dependency with a named owner — not as a third-party integration — and schedule a recurring review of upstream merges like the one shipped in v2.1.0.