Axiom Laravel Package

Product Decisions This Supports

• Build vs. buy for rule/expression logic: Axiom (gosuperscript/axiom) sits in the space of evaluating declarative expressions inside a Laravel app — the kind of thing teams otherwise hand-roll as if-ladders, JSON rule configs, or a homegrown DSL. This release is a signal that the semantics layer is still being actively corrected (operator resolution order), which matters if you're deciding whether to lean on it for business rules versus writing your own evaluator.
• Feature feasibility for configurable business logic: Use cases include admin-editable conditions (pricing, eligibility, feature gating, notification routing) evaluated at runtime. v0.6.10 specifically fixes precedence between presence checks and equality overloads — i.e. expressions where "is this value set?" and "does this value equal X?" could resolve ambiguously. If your product intends to expose condition builders to non-engineers, correctness of exactly these edge cases is the difference between a trustworthy feature and a support queue.
• Roadmap risk assessment: Pre-1.0 (0.6.x) with rapid patch releases indicates an unstable API surface. Plan for pinned versions and a re-validation step on every bump; do not place it on a critical path with a fixed launch date without a fallback.
• Buy-vs-build cost modelling: Adoption cost is small (Composer install, Laravel service provider conventions implied by the ecosystem), but the hidden cost is semantic validation — you must build a test suite that encodes your business rules so that bugfix releases like this one are provably non-regressive for you.
• Correctness-over-features signal: This is a fix, not a feature. For a PM, that's a positive maturity indicator in a narrow sense: the maintainers are resolving semantic ambiguity rather than expanding scope. It supports a "watch, don't commit" stance rather than "adopt now."

When to Consider This Package

Consider it when:

• You have recurring, user-configurable conditional logic that would otherwise be duplicated across controllers, jobs, and Blade views, and you want a single evaluation engine rather than bespoke if statements.
• Your team is Laravel-native and values ecosystem fit (service container, config, testing helpers) over a generic standalone expression library.
• You can pin the version ("gosuperscript/axiom": "0.6.10" or a tight constraint) and accept a review cycle on each patch.
• You have the appetite to write conformance tests for your own rule set — particularly around presence/null handling and equality against typed values, which is precisely what this release touched.
• The logic is internal or admin-facing, where a subtly wrong evaluation is recoverable and observable, not silently charged to a customer.

Look elsewhere when:

• You need a stable, documented public API with backward-compatibility guarantees — 0.x releases make no such promise.
• The rules are simple and few; plain PHP or Laravel's validation/condition APIs will be cheaper to own than a DSL plus its upgrade treadmill.
• You need auditability, versioned rule sets, or a rule authoring UI out of the box — an expression evaluator is a primitive, not a rules product, and the surrounding scaffolding is your build.
• Performance is a primary constraint at high evaluation volume; expression interpretation generally trades throughput for flexibility, and there's no evidence here of caching or compilation guarantees.
• The workload is compliance-sensitive (credit, eligibility, medical) and you cannot tolerate a semantic reinterpretation landing in a patch release.

How to Pitch It (Stakeholders)

To executives: Axiom is a small, focused Laravel library for evaluating business rules written as expressions instead of hard-coded conditionals. The latest release (v0.6.10) is a correctness fix — it removes an ambiguity where "is this value present?" and "does this value equal X?" could resolve in the wrong order. That's the right kind of release for a library like this: it's tightening semantics, not adding surface area. The strategic case is optionality: it lets us move pricing, eligibility, and gating logic out of code and into configuration without building and maintaining an expression engine ourselves. The caveat is maturity — the package is pre-1.0 and the semantics are still being refined. My recommendation is a time-boxed pilot on a non-critical rule set, with the version pinned and a small conformance suite around our own conditions, before we consider it for anything customer-facing or revenue-affecting.

To engineering: This is a patch release on a 0.x package — no new features, no deprecations, no migration work. The change fixes operator resolution ordering so presence checks are evaluated ahead of equality overloads; if we have any rule that tests both existence and equality on the same operand, behaviour may shift, and that's the one thing worth a regression test. Recommend pinning an exact version, adding a composer update gate that runs our rule conformance tests, and treating each 0.x bump as a potentially behaviour-changing release until 1.0 lands.