Ruler Bundle Laravel Package

Product Decisions This Supports

• Feature gating and entitlements without deploys: Because a stateless rule engine evaluates declarative conditions like account.plan == "pro" and account.seats <= 25, PMs can change eligibility criteria as a configuration change rather than waiting on a release train. The product lever is turnaround time on packaging and access decisions, not the engine itself.
• Pricing, promotions, and discount logic: Conditions such as "20% off if cart > $100 and customer is returning and region = EU" become reviewable data rather than scattered branching code. This shortens the loop between a growth experiment and its rollout, and makes campaign logic auditable in one place.
• Eligibility and risk gates: Trial starts, refund approvals, KYC thresholds, abuse flags, and moderation decisions all benefit from a single testable decision layer. PMs get a named surface to reason about policy instead of inferring it from application behavior.
• Build-vs-buy scoping for a rules capability: This package is a compact reference implementation of the minimum viable API — rule set, context, boolean outcome. It sharpens estimation for a first-party build and helps define what "good enough" looks like before committing to a vendor or a service.
• Roadmap sequencing for admin tooling: The pattern clarifies which decisions are worth externalizing now, and which need a business-facing rules editor later. It is a cheap way to validate demand for self-serve policy management without funding a platform team first.
• De-risking an architectural bet: Introducing a decision layer behind a single interface is a small, reversible investment. This package demonstrates the shape of that seam at near-zero cost, which makes the eventual build-or-buy call better informed.

When to Consider This Package

Consider only under narrow conditions:

• The stack is legacy Symfony 2 / early Symfony 3 and already pinned to that era, so an old bundle is consistent with the surrounding platform rather than an exception to it.
• Rules are flat, stateless, and boolean — a modest set of conditions over scalar context, with no persistence, history, versioning, or composition requirements.
• The decisions are low-stakes and reversible (internal tooling, back-office gating, staged experiment rollout), so a thin unmaintained wrapper is an acceptable failure domain.
• The goal is a timeboxed proof of concept to show stakeholders the decision-layer pattern before funding a real solution.

Look elsewhere when:

• The target is Laravel. This is a Symfony bundle: no service provider, no facade, no publishable config, no Laravel version constraints. Consume the underlying Ruler library directly as a standalone dependency, or port the pattern as a first-party primitive.
• There is any expectation of maintenance: 26 stars, 0 dependents, and a Symfony 2 target date the project to a defunct ecosystem. Assume no security patches, no PHP 8 guarantees, no issue triage, and no support path.
• Rules must be authored or edited by non-engineers, versioned, audited, hot-reloaded, or rolled back independently — none of that exists here.
• Decisions are business-critical or regulated (billing, credit, medical, compliance). An abandoned dependency is not an acceptable failure domain for revenue or regulated logic.
• Explainability is required — tracing why a specific decision fired. There is no provenance, no matched-rule reporting, no decision log without building it yourself.
• Complex composition is anticipated: nested rule sets, priorities, conflict resolution, weighted outcomes, decision tables. This engine is intentionally minimal; stretching it here is a rewrite in disguise.
• Performance at volume matters. Evaluation is linear in rule count with no compiled-rule cache or memoization, which is fine at tens of evaluations per request and a profiling target in the thousands.

How to Pitch It (Stakeholders)

One-liner for executives: We evaluated a small open-source rules engine that expresses policy — who qualifies for a discount, who gets access to a feature, who is auto-approved — as configuration instead of code. The pattern is worth adopting because it decouples business policy from release cycles. The specific package is not: it targets an obsolete Symfony version, has effectively no user base, and would leave us maintaining abandoned code on a decisioning path. Recommendation: treat it as a design reference, fund a short spike to validate the pattern, and make a build-versus-buy call on the results — not a production commitment.

For engineering: Do not install this bundle into a Laravel application; there is no supported path, and forking an end-of-life Symfony bundle to shim it into Laravel's container is strictly worse than a short port. Instead, isolate decision logic behind a single RuleEvaluator interface in our own namespace, with rules supplied as versioned data (PHP arrays or JSON, not framework config trees) so they are diffable and reviewable. Reimplement the evaluation core as a framework-agnostic, PHP 8, framework-free class in roughly 150–300 lines — RuleSet, Rule, Operator, evaluate(array $context): Decision. Bind it Laravel-natively with one service provider, one publishable config file for rule-set registration, and one injectable contract. If we prefer off-the-shelf, take the underlying Ruler library as a standalone dependency and skip the bundle entirely — but verify PHP 8 compatibility first, since the library is as old as the bundle.

Engineer the failure modes deliberately, because in this engine family they are silent by default: a missing or misnamed context key should fail loudly rather than returning a legitimate-looking false; operator type coercion under PHP 8 (string versus numeric comparison, null handling) is the highest-risk class of bug and must be pinned by contract tests; malformed rule sets and unknown operators should fail at load time, not evaluation time. Build provenance instrumentation from day one — rule-set version identifier, input hash, matched rule IDs, latency — or the first "why did this account get this outcome?" incident becomes unbounded.

Sequencing the ask: (1) Spike — encode three real production rules in a standalone evaluator and judge clarity and testability. (2) Benchmark — evaluation latency at realistic rule count and per-request call volume, confirming short-circuit ordering is controllable. (3) Decide — if rules stay engineer-owned, ship the ported evaluator as a first-party package with contract tests and a short rule-authoring guide; if business users need to author or change rules without deploys, stop, because this class of engine is the wrong end state and a hosted decision service or a policy language is the right comparison.

The decision for the group: adopt the capability — externalized, testable business rules behind a clean seam — and reject the dependency. The honest total-cost comparison is not "bundle versus build"; it is "abandoned code we now own" versus "code we wrote and already own." The latter is cheaper by construction. One named internal owner must be assigned to the decision layer, along with an escalation story for contested outcomes, before anything ships.