Business Logic That Ships Without a Release

A credit policy change should not sit in a release queue behind unrelated code.

Every enterprise engineer has watched it happen. A business team requests a rule change, one threshold, one new condition, one reassignment of who handles what. The change itself takes an afternoon. Then it joins a release train: batched with feature work, waiting on a regression cycle sized for the whole application, scheduled into a deployment window negotiated weeks out. The business asked for a decision change and received a delivery date.

The delay has a structural cause, and it is worth naming precisely: the logic is compiled into the application, so the smallest change inherits the largest release process. Fixing the delay means giving logic its own lifecycle.

Logic as a Governed Artifact

On Ontoz, business logic lives in Rule Sets: scripts grouped by rule type, held apart from both the process structure and the application code. The rule type tells the engine when a rule runs and what it must return. Orchestration rules decide which activities and tasks start next. Assignment rules decide who receives a task. Pre-condition rules allow or block an action before it executes. Validation rules protect data before it persists. Mapper rules transform payloads on the way to and from external systems.

The engine and the script divide the work cleanly, in the shape of the template method pattern: the engine controls the lifecycle, the invocation, the context, and the contract, while the script supplies only the decision. Rules execute against a uniform context that includes full application data, current flow state, user and role services, and master data, so a rule author writes the decision and nothing else.

Hot Reload, With Guardrails

Rules are hot-reloadable: a changed rule goes live without redeploying the platform. Said alone, that sentence should worry any risk team, because speed without control is how systems accumulate incidents. The control comes from the change mechanics that surround every rule change.

Versioned. Every configuration change is version controlled. The history of what the logic said, and when it changed, is a permanent record rather than a memory.

Compiled and stored before activation. A change is compiled and stored first, then activated for a specific flow. Activation is scoped: updating one flow never affects another. The blast radius of a change is declared before the change goes anywhere.

Automatic rollback. If an activation fails, the platform rolls back automatically to the last stable version. The failure mode of a bad change is the previous working state, arrived at without a war-room call.

Deliberate, isolated, reversible. Each property matters alone; together they are what make same-week logic changes compatible with the control expectations of a regulated enterprise.

What the Separation Buys

For business teams, the request-to-live gap collapses from a release cycle to a governed change. The system keeps pace with the institution instead of lagging it by a quarter.

For engineering teams, the release train carries what it should: platform changes, at platform cadence. Logic changes stop competing for deployment windows, and the regression burden scopes to the flow that changed.

For everyone auditing the system later, the question "what did the logic say on the day this decision was made" has an exact answer, because versions are the record.

The speed of a rule change should be set by how carefully it was reviewed, never by what else happens to be in the queue. Separating the lifecycle of logic from the lifecycle of code is how the platform keeps that promise.