Activity Log Laravel Package

Product Decisions This Supports

• Build vs. buy for audit/activity trails. Every caseworking, permitting, approvals, or back-office service eventually needs "who changed what, when, and why." This package is a candidate to buy (adopt) instead of re-specifying that same trait + migration + timeline view in each repo. The decision it informs: do we standardise on one internal component, or let each team roll its own fourth variant?
• Feature scoping for a "History" / "Activity" tab. If the near-term roadmap includes record history for caseworkers or admins, this is a cheap way to ship it — subject/causer/event/properties is the standard shape of the requirement, and GOV.UK-styled rendering is the part teams most often underestimate.
• Portfolio consistency across GOV.UK-aligned services. For an organisation running several Laravel services in a public-sector style (Network Rail / DfT / arms-length body context), the value is standardisation of the audit record schema, not novel capability. That's a platform-team decision, not a product-team one — but it is triggered by product requests for auditability.
• Compliance and assurance positioning. Supports answering "can we demonstrate an audit trail?" for DPA 2018 / FOI / internal audit review. It does not satisfy evidentiary-grade requirements (tamper-evidence, signing, WORM storage) — decide that separately and be explicit in the risk register.
• Roadmap sequencing. Low integration cost means it can ride along with an existing story rather than earn its own epic; that makes it a "yes, if we're touching that service anyway" decision rather than a standalone investment case.
• Explicit non-use cases. This is not product telemetry, analytics, customer behaviour tracking, or a SIEM feed. Conflating audit logging with analytics is a common and expensive mistake; keep them separate in the roadmap.

When to Consider This Package

Consider it when:

• You are on Laravel/PHP and building services that follow GOV.UK Design System conventions — the stated target, and the only context where the bundled views and styling assumptions pay off.
• Your requirement is a plain append-only activity record (subject, causer, event, property bag, timestamps) surfaced as a timeline on a record page. That is exactly the shape most internal admin requirements take.
• You have more than one service needing the same thing. With one service, writing ~200 lines of trait and migration in-house is genuinely competitive and removes a dependency.
• You can treat the code as vendored source you own: pin the version, read it before merging, and accept that you may fork it. Given 0 stars, 0 dependents and no external consumers, that is the only defensible posture.
• You want to converge on a schema across teams so audit data can be queried or exported consistently later.

Look elsewhere when:

• You need regulatory-grade immutability — cryptographic signing, hash chaining, write-once storage, retention enforcement. This is a conventional Eloquent-backed log; it is not a tamper-evident audit system.
• You need mature ecosystem support, documentation depth, or a broad community to hire against. spatie/laravel-activitylog has orders of magnitude more adoption and is the safer default if the only requirement is "log activity in Laravel."
• You need high-volume or streaming event capture, multi-tenant partitioning, or SIEM/observability pipeline integration.
• You are not on Laravel, or not styling to GOV.UK — you'd inherit assumptions without the benefit.
• Your organisation requires vendor support, an SLA, or a security review with a named maintainer. A single-team, single-repo package with no external dependents will not clear that bar, and you should not pretend otherwise in a procurement paper.

How to Pitch It (Stakeholders)

To executives: "We keep rebuilding the same audit-trail feature in every back-office service. A fellow public-sector team has published theirs under MIT — it's small, it matches GOV.UK styling, and adopting it saves each team roughly a sprint of duplicated work while making our audit records consistent across services. The cost is low and the licence is permissive. The trade-off is that it's a small, single-source component with no external user base, so we should adopt it as code we own — pin it, review it, and be ready to maintain a fork. I'd recommend it for services already being touched, not as a standalone project."

To engineering: "It's a Laravel trait plus migration plus GOV.UK timeline views — subject/causer/event/properties. Before we merge it: read the source in full, check the migration against our schema conventions, pin the version, and confirm it doesn't conflict with our existing logging or observability stack. We treat it as vendored code with a fork path, not as a supported dependency. If anyone objects on maintainability grounds, the fallback is to copy the pattern in-house — which is the status quo cost we're trying to avoid."