Product Decisions This Supports
- Audit trail / compliance roadmap. Automatically capturing Doctrine entity changes (create/update/delete with old and new values) is the foundation for SOC 2, SOX, HIPAA, and GDPR "who changed what, when" requirements. This package makes that a config-level feature rather than a sprint-sized build.
- Build vs. buy for change-data-capture. The capability is genuinely commodity: a Doctrine event subscriber plus a log table. This package lets you defer a custom build and reallocate that engineering time — but the build is small enough that "buy" only wins if the package is maintained.
- User-facing activity feeds and history panels. "Last edited by X on Y" and per-record change history are low-cost, high-perceived-value features once change data is being persisted.
- Support and forensics workflows. Reconstructing how a record reached a bad state, and enabling manual/scripted rollback, directly reduces time-to-resolution on data incidents.
- Scoping a data-governance epic. Use it as a spike to validate retention policy, field-level redaction (PII must not land in a log table verbatim), and access control on the audit store before committing to a permanent architecture.
- Architecture decision: application-level vs. infrastructure-level capture. Application-level logging (this package) is portable and semantic; database triggers or CDC are more tamper-resistant but opaque. This package forces that tradeoff into the open early.
When to Consider This Package
Consider it when all of the following hold:
- The product is on Symfony with Doctrine ORM — this is a Symfony bundle, not a Laravel package. A Laravel/Eloquent codebase cannot use it without introducing
laravel-doctrine, which is a large architectural commitment for one feature.
- You need entity-level change history quickly for an MVP, internal tool, or a non-regulated audit requirement.
- You can accept 2022-era code (last release Feb 2022, 8 stars, 0 dependents) and are willing to vendor/fork it and own it.
- Volume is modest and you are comfortable with write amplification on every persisted change.
Look elsewhere — or build in-house — when:
- Stack mismatch: Laravel/Eloquent. Use an Eloquent observer/
Auditable trait pattern, or a dedicated Laravel audit package, instead.
- Maintenance risk is unacceptable. Eight stars and zero dependents means no community safety net; a Symfony or Doctrine major-version bump will likely strand it silently.
- You need tamper-evident or high-assurance audit (append-only storage, hash chaining, WORM, separation of duties). This is an application-level logger, not a compliance-grade audit system.
- High write throughput or large BLOB/JSON columns, where per-change row copies are a cost problem.
- You need first-class PII redaction, retention, and legal-hold tooling — that is a platform concern, not a bundle concern.
- An existing platform capability already covers it (event sourcing, CDC/Debezium, warehouse history tables, or your DB's native temporal tables).
How to Pitch It (Stakeholders)
To executives (one paragraph): Regulatory and enterprise buyers increasingly ask for provable change history. This is a small, MIT-licensed library that gives us that capability in days instead of a quarter, for Symfony/Doctrine services. The catch is maturity: it has a single maintainer, no downstream adoption, and no release in three years. My recommendation is to use it as a time-boxed prototype to validate requirements — not as a production dependency we rely on unowned. The strategic value is the specification it produces, not the artifact itself; if we adopt it, we adopt it as a vendored, internally-owned fork.
To engineering (the ask): Spike it in one non-critical service, then answer three questions: (1) does the captured payload give us the fields and old/new values we actually need, including relations? (2) what is the write and latency cost per transaction at our realistic volume? (3) how much work is it to fork and pin against our current Symfony/Doctrine versions? Budget one engineer-week. Note explicitly that the stack is Symfony/Doctrine — this does not transfer to our Laravel services, which would need a separate native implementation.
The honest risk statement to carry into the decision: low adoption, stale release cadence, and zero dependents mean we will be the maintainers on day one. Approve adoption only with an owner assigned, a fork in our org, and an exit path — either "replace with in-house subscriber (≈1–2 weeks)" or "migrate to a supported audit platform." If no owner is available, the correct decision is to build the thin in-house version rather than inherit an abandoned one.