The same rule, implemented three ways
Every codebase that embeds its own validation embeds its own interpretation — and they disagree in exactly the edge cases that matter.
Platform / Engine API
The Engine API puts Smartta's decision boundary inside your own products, internal tools, and integrations — submit a workforce decision, get back pass, flag, or gate with the violations and an evidence reference. One rule engine, every surface.
Same Domain Packs · same pass/flag/gate boundary · same Evidence Ledger
The problem
Award logic in the rostering tool. A different version in the payroll integration. A third in the internal dashboard. Each one an approximation, each one drifting, each one your team's to maintain.
Every codebase that embeds its own validation embeds its own interpretation — and they disagree in exactly the edge cases that matter.
Your app checked something — but there's no decision record. When the question comes later, "the code validated it" isn't a defensible answer.
When the award or policy changes, every product carrying its own logic needs a code change, a deploy, and a regression cycle — per codebase.
How it works
The API surface is deliberately small — the depth is in the Domain Packs behind it, not in the integration work in front of it.
One rule engine, every surface
Instead of recreating workforce checks in every product and maintaining them forever, call the layer where the rules are encoded, expert-validated, and versioned once:
Build with Smartta
Talk to us about your use case, product architecture, and how Smartta can support your integrations, services, or developer workflows.