Redactable Models Laravel Package

Product Decisions This Supports

• Deletion-request fulfillment (GDPR Art. 17, CCPA/CPRA, LGPD, PIPEDA). Answers the recurring product question: "when a user asks to be deleted, do we hard-delete, soft-delete, or anonymize?" This package makes "anonymize in place" a first-class, one-line operation on an Eloquent model instead of a bespoke migration + job per table.
• Build vs. buy for the "right to erasure" path. The build alternative is a custom trait/service that walks every PII-bearing model, overwrites fields, and stamps a redacted_at. That is 1–3 engineer-days plus ongoing maintenance and per-model drift. Adoption cost here is far lower, so the decision becomes "adopt a small dependency" vs. "own internal redaction plumbing forever."
• Anonymize-not-delete product posture. Many products must retain the row for referential integrity, financial/audit records, or analytics continuity while stripping identity. This lets you ship a "close account and anonymize" flow without orphaning foreign keys or breaking historical reports — a real roadmap unblocker for account-deletion and tenant-offboarding epics.
• Scope decisions on what counts as PII. Implementing redaction forces a per-model attribute inventory (name, email, phone, address, ip, free-text notes). That inventory is itself a deliverable: it feeds the data map, privacy policy, DPIA, and security questionnaire answers. Treat it as a compliance artifact, not just code.
• Non-production data hygiene. Sanitizing production copies for staging/QA and for support-engineer reproduction is a legitimate secondary use case, and often the fastest way to justify the dependency internally.
• Support/impersonation and account-deactivation UX. Redaction gives a clean, auditable state ("this record has been redacted") that support tooling and admin panels can display, rather than ambiguous "user not found."
• AI/LLM and analytics pipelines. If prompts, exports, or feature stores are backed by these models, redaction is the mechanism that stops deleted users resurfacing in training sets or dashboards (within the systems that read from the DB).
• Explicitly not a decision this supports: intake, identity verification, SLA tracking, and evidence-gathering for data-subject requests. This is one execution layer of a DSR program, not the program.

When to Consider This Package

Consider adoption when most of these are true:

• The stack is Laravel with Eloquent models and PII is concentrated in a known, modest set of tables (roughly under a few dozen models).
• You need field-level anonymization with a durable "was redacted" marker, and you're comfortable with the redaction being destructive/irreversible — verify this against source before committing, since undo semantics are a governance decision, not a detail.
• Rows cannot be hard-deleted for legal, financial, or referential reasons, or you want to preserve aggregate history.
• You want a declarative, reviewable attribute map so the definition of "what we redact" lives in code and diffs in PRs — valuable for audit and for keeping redaction coverage from silently rotting as models gain columns.
• The team is small and the alternative is hand-rolled redaction logic with no tests. A maintained MIT package with a focused API is cheaper than internal ownership.
• You can accept community-maintained risk: ~115 stars, zero known dependents, single maintainer. Read the source (small surface), pin the version, and wrap it behind your own service/interface so it's replaceable.

Look elsewhere — or scope up — when any of these are true:

• Non-Laravel or non-Eloquent data. Raw query-builder tables, Mongo, Redis, queues, or polyglot services are out of scope and will be the actual gap in your compliance story.
• You need a complete erasure guarantee. Redaction touches the primary DB row only. Backups, read replicas, application logs, error trackers, search indices (Algolia/Elastic), warehouses (Snowflake/BigQuery), S3 exports, email providers, and third-party processors all retain copies. That is the bulk of the real work and none of it is here.
• You need crypto-shredding or encryption-at-rest key deletion as the erasure mechanism, or per-field encryption/tokenization.
• You need regulatory-grade evidence: immutable, queryable audit logs of who redacted what and when, retention policies, legal-hold exceptions, and DSR workflow with SLAs.
• Volume/queuing matters. Bulk redaction of millions of rows is a background-job and batching design problem, not a trait concern.
• You're already on a privacy platform (OneTrust, Transcend, Ketch) or a data-catalog-driven deletion orchestrator — don't duplicate it with a model trait.
• You need reversible redaction or a "break-glass" restore for legal proceedings.

Diligence checklist before adoption: confirm irreversibility, confirm redacted_at indexing and scopes for filtering redacted records, confirm behavior on relationships (cascade vs. manual), confirm it doesn't conflict with SoftDeletes (soft-deleted rows still hold PII), and check test coverage plus release cadence.

How to Pitch It (Stakeholders)

To executives (one paragraph): Customers and regulators increasingly expect us to be able to delete or anonymize personal data on request. Today that work is manual and inconsistent, which is both a compliance exposure and an engineering tax on every new feature that touches customer data. This is a small, MIT-licensed, Laravel-native package that turns "redact this customer's personal data" into a declared, reviewable, one-line operation per model — it shrinks the blast radius of a data breach, gives us a defensible answer in security questionnaires, and unblocks account-deletion and tenant-offboarding work already on the roadmap. Cost is near zero; the dependency is small and can be isolated. Important framing: it solves the database-row piece only — backups, logs, analytics, and third-party vendors need separate handling, so this is a meaningful first step, not a claim of full GDPR compliance.

To engineering (the honest version): It's a trait plus an attribute map and a redacted_at marker. Small API surface, easy to read in an afternoon, MIT, Laravel-native, no runtime services. Risks: single maintainer, ~115 stars, no visible dependents, so treat it as vendored-quality — pin it, wrap it behind our own RedactionService interface, and add contract tests so swapping it out is a day's work. It will not cover backups, log scrubbing, search-index purging, warehouse deletes, or DSR workflow; plan those as separate line items. Also decide deliberately whether redaction is destructive, and make sure soft-deleted rows are in scope, because that's the classic hole teams ship.

Recommendation: Adopt as the database-layer primitive for a broader data-erasure initiative. Fund it as a thin slice of a larger compliance epic, with the attribute inventory treated as a shared deliverable between product, legal, and engineering.