Broadway Sensitive Serializer Bundle Laravel Package

Product Decisions This Supports

• Data-protection posture for event-sourced systems. Once domain events land in an event store, they are effectively immutable: passwords, tokens, PII, and payment identifiers get baked into append-only rows. A sensitive-data serializer masks or replaces flagged fields at serialization time, so the event log itself stops being a compliance liability. This directly informs decisions on retention windows, DSAR/"right to be forgotten" handling, and whether we can keep events indefinitely for replay.
• Build vs buy on serialization hygiene. Field-level masking is a small surface area but security-critical and easy to get subtly wrong (nested objects, collections, partial replay). This package encodes an existing convention — Broadway's sensitive-data marker interface — so the team annotates fields once instead of maintaining a bespoke masking mechanism.
• Framework-fit decision, not a feature decision. The artifact is a Symfony bundle wrapping Broadway, not a Laravel package. The real decision it informs is "do we adopt Broadway as our event-sourcing core, or use a Laravel-native stack?" Masking is the forcing function that makes that question concrete.
• Audit-log and support-tooling roadmap. Masked events let us ship audit trails, admin viewers, and support tooling that can read the event log without exposing secrets to internal staff or downstream consumers.

When to Consider This Package

• Only if the stack is Symfony + Broadway and events carry sensitive fields. The bundle suffix means the value is in Symfony DI registration and configuration; there is no Laravel service provider or auto-discovery here.
• On Laravel, treat it as a reference implementation, not a dependency. Porting it means either adopting Broadway wholesale or reimplementing the masking pattern in a custom event serializer. Prefer a Laravel-native event-sourcing stack and implement masking as serializer middleware.
• Evidence from v1.0.1 is thin. The release is a patch whose notes contain only a full-changelog link — no described features, fixes, deprecations, or breaking changes. This is a maintenance-shaped signal, not a capability signal. Read the actual diff (v1.0.0...v1.0.1) before drawing conclusions.
• Look elsewhere if: you need active-maintenance guarantees (small-maintainer, low-velocity repository), framework-agnostic serialization, or a masking solution with its own published security review and disclosure process.
• Confidence caveat: this assessment is based on package identity and a single content-free patch release, not on source review, test coverage, or issue-tracker activity. Validate those before committing.

How to Pitch It (Stakeholders)

To executives: This is a small, focused utility that redacts sensitive fields before domain events are written to the event store. Its value is risk reduction against data-protection obligations — it shrinks the blast radius of a breach or an over-broad internal access grant. It does not add user-facing features or velocity.

To engineering: It is a Symfony bundle around Broadway's serializer, so adopting it in our Laravel codebase is not a composer require. The realistic path is to treat it as a design reference: adopt the marker-interface-plus-serializer-middleware pattern and implement it against whichever event-sourcing stack we standardize on. Cheap to replicate, expensive to get wrong — worth an explicit design note and a test that asserts sensitive fields never appear in raw stored payloads.

Recommendation: Do not adopt as a dependency today. Revisit if we standardize on Symfony/Broadway. Note that v1.0.1 carries no documented changes, so there is no evidence of breaking changes — and equally no evidence of active feature development.