Doctrine Entity Logger Bundle Laravel Package

Product Decisions This Supports

• Auditability and compliance features. The package provides entity-level change logging for Laravel/Eloquent models. This directly supports roadmap items like "who changed what, when" history views, admin activity feeds, and audit exports — commonly required for SOC 2, HIPAA, GDPR, and financial/enterprise procurement conversations.
• Build vs. buy for audit trails. An audit log looks trivial and is not: retention, tamper-evidence, diffing, actor attribution, and query performance all accumulate cost. This package is a candidate to avoid a bespoke build, reducing scope on a recurring "we need history on X" request.
• Opt-in scoping is now a first-class product decision. As of v0.2.0, logging is enabled only for entities carrying the LoggableEntity attribute. That turns "which data is audited" into an explicit, reviewable declaration in code rather than an implicit global default. This is good for compliance scoping and data-minimization/privacy posture — you can point auditors at a bounded, enumerable set of audited entities.
• Feature sequencing. Because logging is per-entity, coverage can ship incrementally: annotate the highest-risk models first (billing, permissions, PII), validate query cost and retention behavior, then expand. This de-risks a roadmap item that would otherwise be a single all-or-nothing migration.
• Use cases this unlocks: customer-facing change history on records, internal support tooling ("what did the customer change before they filed this ticket"), access-review evidence, and forensic reconstruction after incidents.

When to Consider This Package

Adopt when:

• You are on Laravel with Eloquent models as the primary system of record, and the audit need is at the entity/record level rather than the infrastructure level.
• You want explicit, opt-in audit coverage — the v0.2.0 attribute model is a fit if your compliance narrative benefits from a small, defensible, code-declared scope.
• You need to ship history/audit capability in weeks, not quarters, and a per-entity log covers the requirement without a platform investment.
• You can absorb pre-1.0 churn: v0.2.0 changes default behavior (entities not annotated will no longer be logged), so pin the version and budget a re-annotation and regression pass on upgrade.

Look elsewhere when:

• You need database-level or out-of-band capture (CDC, triggers, log shipping) — application-layer logging misses direct SQL writes, migrations, and backfills, which is often exactly what auditors ask about.
• You need event sourcing or full state reconstruction, not a change log.
• Write volume is high on the entities in question; per-model logging on hot tables needs a performance and storage-retention evaluation that a pre-1.0 package may not have documented. Verify indexes, async/buffered writes, and retention/archival story before committing.
• You require tamper-evidence (append-only guarantees, hash chaining), configurable PII redaction, or built-in retention policy management — treat these as build/extend work, not assumed.
• You need to audit non-entity events (auth, jobs, API calls) or span multiple services. This is a model-scoped tool; a broader audit pipeline is a different purchase.
• You need vendor stability guarantees — no 1.0, no LTS, small maintenance surface. Acceptable for internal tooling; a harder sell for a contractual compliance dependency.

Open evaluation items before commitment: documentation of the LoggableEntity attribute contract (what it captures, how it handles relations, soft deletes, and bulk operations), upgrade/migration guidance for the v0.2.0 behavior change, and observed query overhead on your largest audited table.

How to Pitch It (Stakeholders)

For executives: This is a small, low-cost component that gives us record-level change history — the evidence layer behind audit requests, access reviews, and "who changed this" support workflows. It removes a recurring engineering build from the compliance roadmap and lets us scope exactly which data is audited, which is what auditors prefer to see. It is pre-1.0 and maintained by a small surface, so it is appropriate for internal and product audit needs, not as a sole control for regulated attestation without a review of retention and tamper-evidence requirements. Recommendation: adopt behind a version pin, start with our highest-risk entities, and revisit once we've measured cost.

For engineering: Laravel-native entity logging, opt-in per model via a LoggableEntity attribute. The v0.2.0 release makes that attribute the sole gate — anything previously logged implicitly will go silent until annotated, so treat the upgrade as a behavior migration: pin the version, enumerate intended-audited models explicitly, and add a test asserting coverage so future models don't drift out of scope. Small integration surface, no infrastructure to run. Before broader rollout, confirm behavior for bulk updates, relation changes, and soft deletes, and benchmark write overhead on our hottest audited table.

Ask: one engineer-week to annotate priority entities, write coverage tests, and benchmark; decision gate at the end on whether to expand coverage or evaluate a heavier audit platform.