The Decision Layer Your Software Has Always Needed — Introducing BaaS: Business Logic As A Service

The Problem Nobody Talks About Enough

Every software system that matters makes decisions.

Whether it is a payroll engine calculating net pay after statutory deductions, an insurance platform pricing a policy, an e-commerce system applying layered discounts, or an AI agent deciding what action to take next — the engine underneath is always making decisions governed by rules. Rules that encode your company's knowledge. Rules that reflect regulations, market conditions, product logic, and hard-earned institutional experience.

And here is the uncomfortable truth that most engineering teams quietly live with: those rules are buried.

They are buried in conditional statements three levels deep inside a service class. They are buried in stored procedures written by a developer who left the company four years ago. They are buried in Excel sheets that finance teams maintain in parallel to the software, because updating the software takes a sprint and a half. They are buried in the heads of subject matter experts who can barely communicate them to the engineers who are supposed to implement them.

This is not a technology failure. It is an architectural failure — one that the industry has been stumbling around for decades without ever quite solving it cleanly.

The rule engine design pattern was supposed to be the answer. In many ways, it was the right idea. Separate the what from the how. Let business rules live outside the application code, in a place that is readable, testable, and adjustable without a deployment. Give business stakeholders visibility into the logic that governs their systems.

But it did not reach its potential. Not even close.

Why Rule Engines Failed to Deliver

To understand why the rule engine space never fully matured into what it promised to be, you have to look honestly at the state of available solutions.

The enterprise-grade rule engines — the big names you will find in analyst reports — are expensive. Not expensive in the way a cloud database subscription is expensive. Expensive in the way that requires budget approval, procurement cycles, legal review, and license negotiations. For large enterprises, this is sometimes acceptable. For mid-sized companies, startups, and teams in emerging markets, it effectively places these tools out of reach entirely.

Then there is the problem of stack lock-in. Many rule engines are tied to a specific language or runtime. A Java-based rule engine is not particularly useful to a team running a Node.js microservices architecture. An engine designed for a .NET monolith does not drop cleanly into a Python-based data platform. The result is that teams either bend their architecture to fit the tool, or they abandon the tool and go back to burying business logic in code.

Even when cost and stack compatibility are acceptable, the developer experience often is not. Many rule engines require significant custom development to wire into an existing system. Some require learning a complex Domain-Specific Language that is neither quite code nor quite plain English — a DSL that is powerful in theory but frustrating in practice and nearly impossible to hand to a non-technical stakeholder. Others require the team to build their own interface for creating and testing rules, adding weeks of work before any value is delivered.

Perhaps most critically: most rule engines do not tell you why a decision was made.

They tell you the outcome. They do not show you the path. You pass in a set of facts, and you receive a result — but the chain of reasoning that produced that result is invisible. For debugging, that is an inconvenience. For auditing in regulated industries, it is a serious problem. For building trust with end users or regulators, it can be a deal-breaker.

Finally, as AI systems have entered the enterprise landscape and begun making or influencing high-stakes decisions, the lack of a clean, composable decision layer has become an even more pressing architectural gap. You cannot bolt deterministic business rules onto a probabilistic AI agent without a principled place to put them. Without that, the AI makes decisions the business never authorized, in ways no one can explain.

This is the accumulated weight of an unsolved problem. It is the reason engineering teams across the world are still writing business logic the hard way.

A New Path Forward

BaaS — Business Logic As A Service — is an open-source decision engine built to address this problem directly, practically, and without compromise on simplicity.

The project, available at github.com/zeguru/baas, takes a clear-eyed view of what has held rule engines back and builds a solution that removes those barriers one by one. It is not a theoretical exercise. It is a working system — API-ready, Docker-deployable in a single command, and equipped with a built-in web interface — designed to become the decision layer for modern applications.

The framing is deliberate and precise. BaaS positions itself not merely as a rule engine but as a decision layer for modern applications — from traditional systems to AI-powered workflows. That framing matters. It signals that this tool is not a narrowly scoped utility. It is infrastructure.

What BaaS Actually Does

At its core, BaaS evaluates rulesets: named groups of rules that together implement a piece of business logic. Each rule has two parts — a when clause that defines the conditions under which the rule fires, and a then clause that defines what action the rule takes.

The when clause supports a rich set of operators: equality and inequality checks, range comparisons, set membership, case-insensitive matching, and more. These operators map cleanly to the kinds of conditions real business logic requires — checking whether a value falls within a tax band, whether a customer's account status qualifies for a discount, whether a given input breaches a threshold.

The then clause is where business logic becomes tangible. Rules can issue advice — plain-language messages that document a decision or flag a condition. Rules can perform validation, including hard stops that terminate the evaluation immediately with a clear message when a critical condition is violated. Rules can apply adjustments: calculations that derive new values from existing facts, using fixed amounts, percentage rates, mathematical expressions, or lookup tables — both simple value lookups and range-based lookups that map input ranges to output values.

These are not toy capabilities. They are sufficient to implement real-world business logic at production scale. The sample ruleset included with BaaS demonstrates this with a net pay calculator — a multi-step computation that applies statutory deductions (health insurance levy, housing levy, pension contributions across tiers), computes taxable income, applies progressive tax bands, applies personal relief, and arrives at a final net pay figure. The entire logic is transparent, auditable, and modifiable without touching application code.

The Feature That Changes Everything: Decision Traces

If there is one capability in BaaS that separates it from the field, it is the decision trace.

Every time BaaS evaluates a ruleset, the response includes a breakdown — a structured, human-readable record of every rule that fired, the action it took, and the result it produced at that step. This is not a log file. It is a first-class part of the API response, designed to be displayed in a user interface, returned to a caller for auditing, or injected into an AI agent's context as factual, deterministic grounding.

Consider what this means in practice.

• A customer calls your support line asking why their insurance premium changed. Instead of the support agent guessing, or escalating to a developer who has to spelunk through code, the breakdown from the last evaluation tells the full story — step by step, in plain language, with the result at each stage.
• A compliance officer needs to demonstrate to a regulator that loan approvals are following mandated criteria. The breakdown is the audit trail.
• An AI agent has made a recommendation. A user wants to know why. The breakdown is the explanation.

This is what explainability actually looks like in practice — not a philosophical commitment, but a concrete artifact delivered with every decision.

API-First and Stack-Agnostic by Design

One of the most important architectural decisions in BaaS is that it exposes its functionality through a clean REST API. This is not incidental. It is the design philosophy.

By living behind an API, BaaS becomes stack-agnostic in the truest sense. It does not matter whether your application is written in Python, Java, Go, Ruby, PHP, or anything else. If your system can make an HTTP call — and every modern system can — it can use BaaS as its decision layer. The rule engine does not need to be rewritten for each technology context. It is a service, deployed once, consumed anywhere.

The API follows RESTful conventions and is documented with OpenAPI, accessible at /baas/docs when the service is running. Developers who are building against BaaS can explore its endpoints interactively, understand the request and response shapes, and integrate with confidence.

The editor UI, accessible at /baas/editor, provides a graphical interface for creating and managing rulesets. Rules can be authored using a form-based interface or by supplying JSON directly — whichever suits the user's preference and technical comfort. An interactive sandbox allows teams to test rulesets against sample inputs and observe the full response, including the decision trace, before any integration work begins.

Deployment is intentionally frictionless. A single Docker command — docker run -p 3000:3000 zeguru/baas:latest — brings the entire system up and running. For teams using Docker Compose, a minimal configuration file is sufficient. For teams who want to run from source, the standard npm install and npm run start:dev flow applies. There is no proprietary deployment tooling, no licensing server to configure, no vendor to call.

The AI Guardrails Opportunity

The timing of BaaS's arrival is not accidental. The problem it solves has existed for decades, but it has taken on new urgency as AI systems have entered production.

The challenge with deploying AI agents in enterprise contexts is not, primarily, a challenge of model capability. Modern language models and reasoning systems are remarkable in their ability to interpret intent, generate content, and navigate complex problems. The challenge is control and predictability.

Business rules are not probabilistic. Tax rates are not suggestions. Compliance requirements are not guidelines that a model should approximate. Regulatory constraints are hard boundaries. And the business logic that defines how a product is priced, how a claim is validated, or how a customer is categorized is the accumulated result of years of domain expertise that cannot simply be embedded in a system prompt and hoped for.

BaaS provides an answer to this challenge by serving as the deterministic layer that governs what an AI agent can and cannot do — and explaining, in each case, why.

Feed the output of an AI agent's reasoning into a BaaS ruleset that validates it against business constraints. Return the result — including the breakdown — back to the agent as grounding context. The agent now knows not just what it can do, but why certain actions are permitted or prohibited. The business has a clear, auditable record of every constrained decision.

This is what it means to add determinism to an AI-powered workflow for non-probabilistic business logic. It does not diminish the AI's capability. It anchors it to reality.

Who This Is For

BaaS speaks to several distinct audiences, and it is worth being explicit about each.

• Enterprise engineering teams that are wrestling with complex, frequently-changing business rules scattered across codebases will find in BaaS a place to centralize that logic, make it visible, and make it manageable. Rules that currently require a developer to change can be updated by someone with domain expertise. Changes can be tested in the sandbox before being promoted. The decision trace makes debugging a matter of inspection rather than investigation.
• Product teams and startups building pricing engines, quote generators, eligibility calculators, or workflow automation systems will find that BaaS reduces the time between idea and implementation. The built-in UI means there is no need to build a rules management interface from scratch. The API means integration with the rest of the stack is straightforward.
• AI platform engineers building agentic systems in production will find in BaaS a principled way to enforce business constraints on AI outputs — a guardrail layer that is deterministic, explainable, and independently operable.
• Teams in regulated industries — financial services, healthcare, insurance, government — will find that the decision trace addresses an audit and compliance need that most rule engines simply do not offer.
• Developers in emerging markets who have been priced out of enterprise rule engines, or who have been unable to justify adopting tools that require significant infrastructure investment, will find that BaaS's open-source licensing (GNU AGPL v3) and zero-dependency deployment model removes those barriers entirely.

Simplicity as a Design Principle

It would be easy to look at the feature set of BaaS and imagine a tool that is complex to operate and maintain. It is not.

The project's guiding principle is stated directly in its documentation: resist all temptations to make this tool complex. The design manifests this commitment in every dimension. The rule DSL uses familiar, readable JSON. The UI is clean and focused on a small set of well-defined operations. The API surface is purposefully limited to what is necessary. The Docker setup requires no configuration to get started.

This restraint is a form of respect — for the developer who will maintain this system, for the stakeholder who will need to understand it, for the team that will depend on it at two in the morning when something is not working as expected.

Complexity accumulates in software. Every abstraction, every option, every configuration parameter is a surface area that must be understood, maintained, and eventually debugged. BaaS makes a deliberate choice to keep that surface small, which in turn makes the system dependable in the ways that matter most in production.

A Practical Look at the Rules Model

The elegance of BaaS's rules model becomes clearest when you see a complete ruleset in context.

The net pay calculator sample demonstrates a twelve-step calculation: health insurance levy, housing levy, pension contributions across two tiers, personal relief, taxable income computation, tax band allocations, gross and final PAYE, and net pay. Each step is a rule. Each rule has a clear precondition and a well-defined action.

When you call the compute endpoint with a gross pay figure, the response gives you not only the final net pay, but the entire derivation — every intermediate value, labeled with the plain-language message from the rule that produced it. If a future regulatory change modifies a deduction rate or introduces a new band, the change is made in the ruleset — not in the application code. The audit trail for that change is the version history of the ruleset, not a diff in a pull request buried in a monorepo.

The rules model also supports more nuanced patterns. The break option on validation rules allows a ruleset to terminate early when a hard constraint is violated — without running subsequent rules that would be meaningless or misleading in that context. Lookup tables allow rules to implement complex mappings — from a customer segment to a discount tier, from a credit score range to an interest rate — without resorting to nested conditionals in code.

What Comes Next

BaaS is actively developed, and its roadmap reflects a clear sense of direction. Rule versioning will bring formal change management to ruleset updates. Execution statistics will give teams visibility into how rules are performing at scale. Expanded database support will allow teams to persist rulesets in the storage layer that fits their infrastructure. API key and JWT authentication will bring production-grade security to the API layer. Rule templates will accelerate the creation of common patterns. An SDK will simplify integration for teams building in supported languages. A headless mode will allow the engine to run without the editor and documentation UI for production deployments where those interfaces are unnecessary.

Each of these items addresses a real limitation in the current version. Each moves BaaS closer to being the comprehensive decision layer that modern enterprises need.

The project welcomes contributions across documentation, testing, UI development, and bug resolution — with clear contribution guidelines and a structured process for community participation.

The Larger Significance

Software systems have become extraordinarily capable. They can process language, reason over data, recognize patterns, and take actions at speeds and scales no human team could match. But capability without control is not an asset. It is a liability.

The missing piece — in enterprise software for decades, and in AI systems for the past several years — is a principled, explainable, manageable layer where business decisions are made. Not inferred from code. Not approximated by a model. Made explicitly, traceably, and in accordance with rules that reflect the actual intent of the business.

BaaS is that layer.

It is not the first attempt to build it. But it is one of the clearest, cleanest, and most practically accessible attempts yet made — and it arrives at a moment when the need for it has never been more acute.

Getting Started

BaaS is available now, free and open source, under the GNU AGPL v3 license.

Then open your browser:

• API: http://localhost:3000/baas
• Rule Editor UI: http://localhost:3000/baas/editor
• OpenAPI Docs: http://localhost:3000/baas/docs

Explore the repository: github.com/zeguru/baas

Star the project if it resonates with you. Share it with the engineer on your team who is still writing conditional logic in a service class that no one fully understands. Contribute if you see a way to make it better.

The decision layer has arrived. It is time to use it.

*BaaS is built with NestJS, TypeScript, and Node.js. It is powered by the json-rules-engine and json-editor projects, and inspired by the persistent need for stack-flexible, explainable, developer-friendly decision systems.*