Audit Api Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for audit trails. Audit logging looks like a weekend feature ("just write a row on save") until you need actor attribution, before/after diffs, tamper-evidence, retention policy, PII redaction, and a query surface for support and compliance. This package targets the capture-and-expose layer, which is the part most teams should not hand-roll.
• Compliance roadmap sequencing. If SOC 2, GDPR DSAR handling, or customer security questionnaires are on the roadmap, an audit trail is a recurring ask. This gives you a candidate component to scope against, rather than an unestimated "we'll build auditing" line item.
• Scoping the in-house remainder. Even if adopted, policy stays with you: what events are auditable, retention windows, redaction rules, who can read the audit API. Use this package to shrink the build to policy + integration rather than storage + API + diffing.
• Maturity signal has flipped from negative to neutral-positive. We are now at v0.9.12, up from v0.7.1. That is real forward motion: two minor versions and a run of patches since the last review, with actual code changes. Treat the earlier "tag hygiene only" read as superseded. The package is still 0.x, so semver says minor bumps may break — but the trajectory now reads as an actively developed project approaching 1.0, not an abandoned one.
• Upgrade cost is now a real budget line, not a hypothetical. Jumping 0.7 → 0.9 is exactly the churn we predicted. If we had adopted at 0.7.1, we would be doing a migration now. This validates the "wrap it behind our own interface" decision rather than undermining it — plan for one integration-touch per minor version until 1.0.
• Differentiation is shifting toward operator UX. The v0.9.12 change is a CLI display improvement (audit:logs renders the Changes column as pretty-printed JSON). That is a support-and-investigation feature, not a capture feature. It tells us the maintainer is optimizing for humans reading audit output — relevant if our primary consumers are support engineers and auditors rather than automated pipelines.

When to Consider This Package

Consider it when:

• You are on Laravel/PHP and need an append-only audit record with a read/query API, not just application logs.
• Your team is small and the alternative is 3–6 weeks of internal build for diffing, actor resolution, and a query endpoint.
• Pre-1.0 risk is acceptable and you can isolate it: wrap it behind your own AuditWriter/AuditReader interface so a swap is a one-file change. The 0.7 → 0.9 jump makes this non-negotiable rather than advisory.
• Human-readable audit review matters — support triage, incident postmortems, auditor walkthroughs. The pretty-printed diff output is aimed squarely at that.
• Compliance requirements are policy-level (we can demonstrate who changed what and when), not certification-level (vendor attestations, WORM storage guarantees).

Look elsewhere when:

• You need tamper-evident or cryptographically verifiable audit storage, WORM/immutable retention, or a vendor with a security policy, SLA, and pen-test reports.
• You need long-term support or a stable API guarantee today — 0.9.x is close to 1.0 but has not arrived, and no LTS commitment is evidenced.
• Audit volume is high enough that storage, partitioning, and retention become an architecture problem this package likely does not solve.
• Naming due diligence fails. The package is named ...-bundle, a Symfony convention. The audit:logs artisan-style command in the new release is meaningful positive evidence of Laravel-nativeness, but it is not proof — still verify service provider, config publishing, and facade/DI wiring. This remains a blocking check, downgraded from "likely problem" to "probably fine, confirm it."
• Maintainer activity is stale on inspection. This bar is now less likely to be met given the release cadence, but re-check for SECURITY.md and issue triage, which version bumps do not demonstrate.

How to Pitch It (Stakeholders)

To executives: Auditing is a recurring line item in security questionnaires and a prerequisite for compliance work we have already committed to. This package is a candidate to cover the capture-and-query portion cheaply instead of building it, and the project is now visibly active — it has moved from 0.7 to 0.9 with functional improvements, which retires the "is this maintained?" objection from the last review. It is still pre-1.0, so the proposal remains a time-boxed evaluation spike, not adoption as a platform dependency. No contract, no vendor lock-in, and we will isolate it behind an internal interface so removal is cheap.

To engineering: Small surface area — we integrate for event capture and the audit read API, and we keep policy (auditable events, retention, redaction) in our own code. The latest release is low-risk: a display change to the audit:logs Changes column (pretty-printed JSON diffs), no schema or API implications. Two asks before we commit: (1) confirm it is Laravel-native despite the bundle naming — the artisan command is a good sign but check the service provider and config publishing; (2) pin the exact version and wrap it, because 0.7 → 0.9 happened without us and will happen again before 1.0.