Wam Prolog Laravel Package

Product Decisions This Supports

• Build vs. buy vs. don't build the rules layer. This package is the "cheap experiment" arm of that decision: it lets you test whether a declarative rule layer actually improves the product before committing to a rules platform, a JVM-based engine, or hand-rolled PHP conditionals.
• Feature feasibility for logic-heavy requirements. Useful for spiking things like eligibility determination, compliance/validation checks, scheduling and constraint problems, pricing/entitlement matrices, or config validation — domains where the requirement is naturally a set of facts plus rules rather than a pile of if statements.
• DSL and extensibility roadmap. If you're considering exposing a query or rule language to power users, internal ops, or integrators, this gives you a concrete reference implementation to react to — what "real" Prolog semantics (unification, backtracking, cut) look like — before you design your own narrower DSL.
• Architecture: embedded inference vs. external service. A pure-PHP WAM means inference runs in-process, inside a queue worker or CLI command, with no sidecar, no JVM, and no network hop. That is a genuine architectural option worth pricing out against calling out to SWI-Prolog or a hosted rules engine.
• Scoping the decision, not the feature. The realistic output of an evaluation is a go/no-go on the approach, not a production commitment. 32 stars, a 0.35 score, and zero dependents mean this is a reference implementation and a prototyping tool, not a foundation.

When to Consider This Package

Consider it when:

• You need actual Prolog semantics — backtracking search, unification, cut, recursive rules — not just forward-chaining if/then rules that a small PHP library already covers.
• The workload is offline, batch, or admin-triggered: nightly eligibility runs, report generation, validation on save, CLI tooling. Not per-request inference on a hot path.
• The fact base is small to moderate and fits comfortably in memory per job; you are not modeling a large knowledge graph.
• Zero external runtime dependencies is a hard requirement — no JVM, no extra service to deploy, operate, or secure.
• You have Prolog literacy on the team, or a deliberate learning budget, and can read the source when behavior surprises you.
• You're doing a time-boxed spike (days, not sprints), a teaching/demo artifact, or a reference implementation to benchmark against.

Look elsewhere when:

• Latency or throughput matters. A WAM in userland PHP will be orders of magnitude slower than a native Prolog. Benchmark before any design depends on it.
• You need Laravel-native integration — service provider, config publishing, queue/console ergonomics, facades. This is a Composer library, not a Laravel package; you own all the glue.
• Supply-chain and longevity risk are unacceptable. Single maintainer, 32 stars, no dependents means no battle-testing, no downstream bug reports, and no realistic security response. Fine to vendor and fork for an experiment; not fine as an unexamined production dependency.
• You need rule versioning, auditability, hot-reload, or a business-user editing UI — those are product concerns this doesn't address at all.
• Nobody on the team writes Prolog. The failure mode isn't "it breaks," it's "nobody can debug it at 2am."
• A simpler rule library or plain PHP already satisfies the requirement. Most "we need a rules engine" requests resolve to a well-factored decision table.

How to Pitch It (Stakeholders)

To executives: This is a free, open-source PHP component that lets us prototype logic-heavy features — eligibility rules, compliance checks, scheduling — without buying a rules platform or adding infrastructure. The cost to try it is a few engineering days and no licensing spend. The caveat is maturity: it's a niche project with a single maintainer and essentially no production users, so I'm recommending it as a time-boxed spike to inform a build-vs-buy decision, not as a platform dependency. If the spike succeeds, we either vendor the code or budget for a mature alternative; either way we'll have real data instead of a guess.

To engineering: Composer-installable pure-PHP implementation of a Warren Abstract Machine — real Prolog (unification, backtracking, cut) running in-process, no JVM, no sidecar. It is not Laravel-aware, so assume you write the service provider and config yourself. Two things to validate in the spike: (1) performance on a representative fact base at realistic rule depth, and (2) maintainability — can the team read and debug the engine when rules misbehave. If we adopt, wrap it behind our own interface so we can swap in SWI-Prolog or a rules library without touching call sites, and vendor/fork it rather than depending on upstream for fixes.