History Laravel Package

Technical Evaluation

Architecture fit konekt/history is a model-audit package for Eloquent that persists create/update/delete events against a polymorphic subject, storing old/new attribute payloads (typically as JSON) in a dedicated history table. Functionally this is the same problem space as spatie/laravel-activitylog and owen-it/laravel-auditing, so the architectural question is not "can we audit models?" but "why this one?"

The material constraint is that the package sits inside the Konekt/Concourse ecosystem and expects konekt/concord — a module registry that imposes a directory and service-provider convention on the application. Adopting a module system to obtain audit logging is a disproportionate architectural commitment: it changes how every future package and domain module is registered, and it becomes load-bearing the moment the first model uses the trait. For a greenfield Laravel app with no other Concourse dependency, fit is poor. For an app already running Concord modules, fit is good — the marginal cost collapses and the package is idiomatic to that ecosystem.

Integration feasibility Mechanically straightforward: composer require, publish migrations, apply a trait to audited models, and optionally decorate the UI. Estimated effort for a two-model proof of concept is 1–3 engineer-days including schema review. The real cost is the Concord evaluation, which is a separate 2–5 day spike that must be justified independently of audit logging.

Technical risk The dominant risk is not code quality but adoption signal: 0 stars, 0 dependents, and a composite score of 0 means no observable production usage, no third-party bug reports, and no community answers when behaviour diverges from expectation. Concretely:

• Bus factor / abandonment. Konekt packages are maintained by a small author set with a broad portfolio; Laravel major-version support historically trails. Pin the exact version and budget for a fork.
• Laravel version coupling. Verify composer.json constraints against the target Laravel and PHP versions before any commitment; an unmaintained audit package that blocks a framework upgrade is a recurring and expensive failure pattern.
• Silent correctness gaps. Audit packages differ on what they capture: dirty-attribute diffs vs. full snapshots, updated_at-only touches, mass updates via query builder (almost universally missed), soft deletes, and pivot/relation changes. These gaps are discovered during compliance review, not during integration.
• Concord's own risk surface. A second unvetted dependency is introduced transitively.
• Unverified API. The public surface should be read from source rather than assumed; documentation for low-traffic Konekt packages is often thinner than the code.

Key questions

1. Does the org have an existing or planned Concord module architecture, or would this be the first and only Concourse dependency?
2. Is the requirement audit/compliance (immutable, complete, non-repudiable) or activity feed (human-readable, best-effort)? The former demands guarantees this package may not make.
3. Has anyone diffed konekt/history against spatie/laravel-activitylog (very large install base) and owen-it/laravel-auditing on the specific capture semantics we need — mass updates, DB::table() writes, restores, force deletes?
4. What is the framework upgrade cadence, and is a vendored fork acceptable to the team?
5. Which attributes contain PII, and is redaction a first-class requirement?

Integration Approach

Stack fit Requires a Laravel application on a PHP version compatible with the package's constraint set, and — critically — konekt/concord. The stack-fit decision table:

Migration path The trait-plus-table model is portable: history rows are self-describing enough that an export to an alternative schema (Spatie's activity_log, or an in-house audit_events table) is a straightforward mapping of subject type/id, event name, causer, and old/new payload. Design the application so that audit writes go through a thin internal interface (e.g. AuditRecorder) wrapping the package. That single indirection turns a package swap into a one-class change and is the highest-leverage decision available here. Backfill of pre-existing historical state is not provided by the package and should be scoped as explicit, separate work — or declared out of scope.

Compatibility Validate three things in a throwaway branch before any design work proceeds: (a) the package resolves cleanly against the locked Laravel/PHP versions; (b) konekt/concord boots without altering existing service-provider registration order in a way that breaks tests; (c) the generated migration applies and rolls back on the target database engine, including JSON column support. Treat a failed (a) as an immediate no-go.

Sequencing

1. Spike (2–3 days): install in a scratch branch, audit two representative models, confirm capture semantics against the requirement list.
2. Decision gate: benchmark against Spatie; document why the chosen option wins. Given the adoption differential, the default should be to justify not using Spatie.
3. Interface layer: define the internal audit abstraction and implement it over the chosen package.
4. Pilot: one bounded domain, one sprint, in a non-critical path.
5. Rollout: remaining models, gated on pilot telemetry (write latency, row growth, error rate).
6. Exit plan: document the swap path and the fork-and-patch procedure before rollout completes, not after.

Operational Impact

Maintenance Ongoing cost is dominated by dependency management, not by the audit feature itself. Assume the package will not track Laravel releases on your schedule and budget a fork-and-patch capability (vendored copy or composer path/VCS repository). Two dependencies (history + concord) must be tracked. A single-maintainer, zero-adoption dependency is a standing line item, not a one-time install.

Support There is no meaningful community to escalate to: no issue backlog to mine, no Stack Overflow corpus, no dependents to compare against. Support is effectively self-support via source reading. This is acceptable for a well-contained audit feature and unacceptable if audit is a compliance control with an SLA. Name an internal owner for the vendored fork.

Scaling Audit tables grow superlinearly relative to business data — every update on an audited model writes a row carrying a JSON payload that can be larger than the model row itself. Plan for:

• Write amplification on hot, frequently-updated models; measure p95 write latency with auditing on versus off before wide rollout.
• Storage growth: estimate rows/day from update volume on the top five models and size for 12–24 months, not 12 weeks.
• Query performance: polymorphic subject indexes are mandatory; retention and archival (partition by month, or move cold rows to object storage) should be designed in the first sprint, because retrofitting partitioning onto a large audit table is painful.
• PII: payloads capture whatever was in the model, including fields later subject to deletion requests. Redaction must be configurable per attribute, and if it is not natively supported, implement it in the interface layer. This is a GDPR/CCPA exposure, not a nice-to-have.

Failure modes

• Coupled writes: if the history write occurs inside the primary transaction, an audit failure rolls back a legitimate business write (availability risk); if outside, silent gaps appear in the audit trail (integrity risk). Decide which you prefer per use case and make it explicit configuration.
• Silent under-capture: query-builder mass updates, raw SQL, and seeded data bypass Eloquent events entirely. Audit completeness claims must be scoped to "Eloquent-originated changes."
• Concord boot failure blocking the whole application on framework upgrade — a blast radius far larger than the feature.
• Unbounded table growth causing slow writes and expensive backups months after launch.
• Abandonment: no security patches for a dependency embedded in the model layer.
• Migration churn: schema changes in the package across versions colliding with a customized local history table.

Ramp-up The package API is small — trait application, model configuration, querying history — so individual developer ramp-up is measured in hours. The organizational ramp-up is the real cost: the team must understand Concord's module conventions (days, not hours, for anyone touching bootstrapping), and every engineer must internalize what the package does not capture. Document the capture semantics and the "audit only covers Eloquent writes" caveat in the internal runbook before rollout — this single document prevents the most likely class of downstream misunderstanding.

Overall recommendation Do not adopt on the strength of the package itself; there is no evidence base. Adopt only if the organization is already committed to Konekt/Concord, and then behind an internal audit interface. Otherwise, evaluate spatie/laravel-activitylog and owen-it/laravel-auditing first, and require a written justification for selecting a zero-adoption dependency over them.