Sensitive Text Detect Bundle Laravel Package

Product Decisions This Supports

• UGC safety as a shippable feature, not a research project. The most common PM question in a Laravel product is "how fast can we ship comments/reviews/chat/DMs without opening a moderation vendor contract?" A sensitive-text detector is the cheapest credible v1: it turns a policy requirement ("we must screen user-submitted text") into a config item and a service call, unlocking a roadmap item in days rather than a quarter.
• Build vs. buy, resolved toward "buy time." This is the classic third path — adopt a small open-source component instead of building a lexicon/pattern engine ourselves or signing a moderation SaaS. The PM decision it enables is deferring the buy decision: ship the OSS baseline, instrument it, and revisit paid vendors only once you can quote real flag volumes and false-positive rates.
• Scope-cutting by content type. A text-only detector lets you carve a launch boundary — public text is screened, images and audio are explicitly out of scope for v1 — without blocking the release.
• Market/segment gating. Whether you can serve regulated or family/education segments often hinges on having any documented content control. A deterministic detector with an auditable word list is easier to defend in a policy review than an opaque model, which can change which segments enter the roadmap.
• Data-residency and on-prem decisions. Because detection runs in-process against your own rules, this supports the "we can deploy single-tenant, no third-party data egress" option — a decision that otherwise forces a vendor-architecture commitment.
• Pricing and packaging. Per-call moderation vendors create usage-based COGS that complicates seat pricing. A zero-marginal-cost local detector supports keeping moderation bundled into existing tiers.
• Risk posture for the 1.1.0 bump. Semver minor on an immature package implies additive change and no intentional breakage, but the release notes contain no changelog detail — do not treat 1.1.0 as a validated upgrade. The decision this supports is pin 1.0.1 in production and evaluate 1.1.0 behind a flag, not a blind bump.

When to Consider This Package

Consider it when:

• The stack is PHP/Laravel and you want moderation logic inside the existing application — no new service, no new vendor, no new data processor to add to the privacy policy.
• The requirement is keyword/pattern detection against a list you own and can edit: profanity, banned terms, competitor names, spam tokens, PII patterns. Deterministic and explainable beats clever here, because you can show a user or auditor exactly why a string was flagged.
• You need an auditable, editable ruleset — legal or trust-and-safety wants "show me the list" and wants to change it without a vendor ticket.
• Volume is unknown or low-to-moderate; you want the flag counts before committing to per-request pricing.
• You need a cheap pre-filter in front of an expensive model or human review queue, to cut cost per item.
• You're in a spike or prototype and want an integration you can throw away in a sprint if it disappoints.

Look elsewhere when:

• The requirement is semantic or adversarial: obfuscation (leetspeak, homoglyphs, spacing), context ("breast cancer" vs. the slur), sarcasm, multilingual coverage. Rule sets leak; assume users will probe them.
• Coverage must extend to images, audio, video, or link reputation.
• You need a contractual SLA, indemnity, appeals workflow, or a vendor who will sit in a regulatory review. This is a single-maintainer open-source bundle with thin release documentation — that is a support risk you're accepting, not a detail.
• Moderation is core to the product's value proposition rather than a compliance checkbox; then the false-positive/false-negative rate is the product and deserves a purpose-built system.
• Your organisation requires a security review, license review, or dependency-vetting gate that a young package is unlikely to clear quickly.
• Non-PHP services need the same detection; a shared rules service is better than two divergent implementations.

How to Pitch It (Stakeholders)

To executives: We can satisfy the baseline "screen user-generated text" requirement with a small open-source PHP component rather than a moderation vendor contract. That means no usage-based COGS, no new third-party data sharing, no procurement cycle, and a realistic path to shipping the feature this cycle. Read it as a floor, not a solution: it catches known terms, not intent, and it won't handle obfuscation or non-text media. The strategic value is optionality — we get real flag-volume and false-positive data to justify (or avoid) a paid vendor later. The main risk is maturity: the package is early-stage, documentation is thin, and the latest release (1.1.0) shipped without a usable changelog, so I'd pin the current version in production and trial 1.1.0 behind a feature flag.

To engineering: This is a contained integration — a dependency, a ruleset we own in config, and a service call at the write path, with no new infrastructure or network hop. Keep it behind an interface so we can swap in a vendor or a model without touching call sites, define the flag/no-flag response contract up front (block, mask, queue-for-review), and log decisions with the rule that matched so we can tune. Two asks: treat the ruleset as versioned configuration with its own review, and put a performance and false-positive baseline in place before we scale volume. And do not auto-merge the 1.1.0 bump — diff the upstream changes and review them as we would any third-party code.