Model Violation Logger Bundle Laravel Package

Product Decisions This Supports

• Input-quality observability as a product capability. The underlying idea — capture every model validation violation with the model, rule, field, and submitted context — turns "the save failed" into a dataset. That dataset supports prioritization decisions: which fields reject the most real-world input, which rules are over-strict, and where form UX or API docs are failing users.
• Support and triage economics. Logged violations let support reconstruct a rejected submission without reproducing it. This is a direct lever on cost-per-ticket and time-to-resolution for anything with user-submitted data (onboarding, checkout, imports, admin edits).
• Build vs. buy: build. The concept is worth owning in-product (a validator listener or exception handler writing structured logs); this specific package is not the vehicle. A ~50–150 line implementation in the application gives you the same signal with your own retention, PII redaction, and schema.
• Roadmap input for validation strictness. Failure-rate by rule tells you whether to relax a rule, improve an error message, add inline guidance, or fix an upstream client that sends malformed payloads. It also surfaces contract drift between mobile clients and the API.
• Error-message and localization priorities. Ranking violations by frequency tells you which messages are worth translating first and which need rewriting — a small but concrete UX roadmap item.
• Not a feature differentiator. Nothing here is user-visible; treat it as internal instrumentation and scope it accordingly (a spike, not an epic).

When to Consider This Package

Consider the pattern, rarely the package.

Consider it if:

• You are maintaining a legacy Symfony 2.x application that already depends on it and you are not adding new surfaces.
• You want a reference implementation for how to hook the validator and emit violations — read the source, don't install it.
• You need a quick mental model of what fields to log (rule name, path, parameters, invalid value) before writing your own listener.

Look elsewhere — including for anything new — because:

• It is a Symfony bundle, not a Laravel package. It will not drop into a Laravel app; Laravel's ValidationException, exception handler, and logging channels already give you the hook points.
• Unmaintained: last release January 2015, no activity since, 4 stars, 0 dependents. No security response, no PHP 8 support, no PSR-3/logging-stack compatibility guarantees.
• Abandonment risk is asymmetric: the cost of adopting is low, but the cost of depending on it (upgrade blockers, audit findings, "why is this in composer.json") exceeds the value of the ~100 lines it replaces.
• You need PII-safe logging, sampling, and retention. A 2015 bundle predates modern data-handling expectations; you will end up wrapping or replacing it anyway.

Verdict: low score is correct. Use as a design reference only; implement in-house or use native framework hooks.

How to Pitch It (Stakeholders)

To executives (one paragraph): This is not a vendor or licensing decision — it's a cheap internal instrumentation idea borrowed from an old, unmaintained open-source component. Implementing it ourselves costs roughly a day of engineering and gives us a ranked list of which validation rules reject real users most often, plus the context to resolve "it won't save" support tickets without a reproduction. It reduces support cost and improves form/API quality; it does not change the product surface, and it carries no third-party dependency or procurement risk.

To engineering (the ask): Don't add the dependency. Spend a spike replicating its behavior:

1. Hook validation failures (Laravel: exception handler / ValidationException; Symfony: validator listener).
2. Emit one structured event per violation: model/entity, field path, rule name, sanitized value or hash, tenant/account, request ID, client version.
3. Redact PII at the source, sample if volume is high, set retention.
4. Ship a dashboard of top failing rules and top offending clients; review monthly.

Success criteria: median time-to-diagnose for validation-related tickets drops; you can name your top five rule-level failure drivers within one sprint; zero PII in logs.