How Code Effects Fits Into Your Existing Applications

One of the most common questions we hear from executives and technical leaders is simple:

What exactly does integrating Code Effects involve?

The short answer is: much less than most people expect.

• You don't replace your existing applications.
• You don't migrate your data.
• You don't deploy separate decision servers.
• You don't redesign your architecture.

Code Effects becomes part of the software you already have. It's that simple.

Think of It as Another Library

From a technical perspective, integrating Code Effects is no different from adding any other third-party .NET component to your project.

Every implementation is built on the same two components: the Rule Editor, a web component in which business users write rules in plain language, and the Rule Engine, a .NET library that compiles those rules and evaluates them inside your own production code. What differs is how much of the rule management around them you build yourself, and Code Effects gives you two ways to handle that.

Stand-alone. Your developers reference the Code Effects assemblies, define the business data that rules should work with (we call these Source Objects), extend your existing data storage to save and retrieve rules in a manner consistent with the rest of the application, optionally implement authentication and authorization for rule access, optionally introduce rule versioning and testing workflows, and embed the Rule Editor wherever rules need to be created or maintained.

With the Rule Repository. The optional Rule Repository, new in version 7, provides rule storage, versions, tests, permissions and approvals as a complete rule management application inside your own web application, placed in one element of your page, on your sign-in, in a database you own. Instead of building that layer, your developers connect the repository to your sign-in and a SQL Server or PostgreSQL database, synchronize your source objects into it, and load the live rules in production code. The optional Audit library and MCP server can be added the same way. See Code Effects Basics for how the two compare.

Everything else remains exactly where it already is:

• Your databases stay the same (the Rule Repository and Audit only add their own tables in a database you own, created and updated by scripts you run when you decide)
• Your APIs stay the same
• Your authentication systems stay the same
• Your deployment processes stay the same

Your applications continue doing what they already do - except that business decisions become configurable.

How Rules Are Created

Rules are authored through a web-based editor that can be embedded directly into your existing web applications, whether they are built with ASP.NET Core, MVC, Razor Pages, Blazor or WebForms, or with React, Angular, Vue or plain pages.

Users interact with menus and business-friendly statements instead of programming languages. For example, a user might define a rule such as:

If the customer has been with us for more than three years
and annual spending exceeds $25,000,
apply the premium discount.

The editor offers only the choices your source object allows at each step, and the server checks the rule again before it is stored, so every saved rule is structurally valid against your data, whether a person, a script or an AI agent wrote it.

The resulting rule is stored as a simple XML document that can be saved wherever your organization normally stores application data. For most organizations, that means an existing SQL database. No specialized storage systems are required. With the Rule Repository, the same Rule XML is kept as immutable versions in the repository's own database, and users can also describe a rule in any language to the AI Rule Editor, which composes it and validates it immediately, right next to the standard editor.

How Rules Are Tested

Before a rule affects real business, it can be tried. In a stand-alone implementation, testing is up to your application. With the Rule Repository, it is built in: business users test a new rule or a proposed version against your real classes before saving it, explore what-if ideas as drafts that never create versions, and define expectation tests that report whether a rule produces the outcome it must. Each run shows the decision path that led to the result. Tests can be saved, built from value templates, created from recorded production decisions, and run in batches of up to 350 whenever a rule changes.

How Rules Are Evaluated

When your application needs to make a decision, it simply retrieves the appropriate rule and evaluates it against the source object it already has. For example:

• A loan application arrives
• An insurance claim is submitted
• A customer requests a discount
• A workflow reaches an approval step

Instead of executing hard-coded conditions scattered throughout the codebase, the application asks Code Effects to evaluate the rule against a source object - the business object that represents the loan application, insurance claim, customer request, workflow instance, or any other entity involved in the decision.

The engine returns the result immediately. Your application then decides what happens next - either by continuing its normal execution flow or by allowing the same rule to invoke designated public methods, called Rule Actions, which can take over the subsequent execution of the business logic.

With the Rule Repository, your application loads the live versions of its rules, together with the rules they depend on, as a complete ruleset ready for evaluation. With Audit, it loads them through the Audit recorder instead, and each evaluation is recorded: when it ran and for whom, the rule and source versions, the values read and the branch taken. Records go to a local journal first and are moved to the database by a background worker, so recording never makes a decision wait. See Evaluating Rules from the Repository.

One Rule's Journey

A simple way to understand how Code Effects works is to follow the lifecycle of a single rule.

Stand-alone:

1. A business user creates or updates a rule using the embedded Rule Editor.
2. The rule is saved as XML in your existing database or storage system.
3. Your application retrieves that rule whenever a decision is needed.
4. The Code Effects engine evaluates the rule against the business object you provide.
5. Your application acts on the result.

That's it.

No separate services. No synchronization processes. No proprietary infrastructure. Just rules moving through the same applications and systems you already own.

With the Rule Repository:

1. A business user, or an AI agent on their behalf, writes a new rule version in the repository inside your web application.
2. The version is tested against your real classes and submitted for approval.
3. An authorized person approves it and makes it live with a typed confirmation, using Go Live.
4. Your production code loads the live version and the engine evaluates it, in-process, exactly as before.
5. With Audit, the decision is recorded, and it can later be reviewed, replayed step by step, explained, and turned into a test.

Even here, nothing runs outside your systems: the repository is part of your own web application, its database is yours, and evaluation still happens in your own process.

There Is No Separate Runtime

Many decision platforms require dedicated servers, cloud services, synchronization processes, or proprietary execution environments.

Code Effects does not.

The evaluation engine runs inside your application process. It is stateless and thread-safe, compiles each rule into IL once, and evaluates it at the speed of compiled C# on any number of threads. If your application runs successfully today, it already has everything needed to execute rules tomorrow. Scaling decisions is no different from scaling the application itself.

The same is true of the version 7 components. The Rule Repository and Audit run inside your own ASP.NET Core or ASP.NET application, and the MCP server inside your own ASP.NET Core application. No component calls a Code Effects service, and Code Effects never hosts your rules. The only data that leaves your environment is what the optional AI features send to the AI provider you configure.

Where It Runs

• The Rule Editor and the Rule Engine target .NET Standard 2.0: .NET Framework 4.6.2 and later, .NET Core 2.0 and later, and .NET 8 and later, on Windows, Linux and macOS, in containers and in the cloud. The browser components are delivered as dependency-free npm packages.
• The Rule Repository and Audit run in ASP.NET Core or in ASP.NET on .NET Framework 4.7.2 and later, with SQL Server 2012 or later or PostgreSQL 14 or later. Oracle and MySQL support is planned for upcoming minor versions.
• The MCP server runs in ASP.NET Core on .NET 8 or later and works with the Rule Repository, Audit, or both.

The entire Code Effects platform is also coming to Java, planned for 2027.

Existing Teams Usually Need Very Little Training

Developers typically become productive within hours because the integration model follows familiar .NET patterns.

Business users generally require only a brief introduction to the editor. Because rules are assembled from guided menus rather than written as code, business users focus on expressing policies instead of learning syntax. The Rule Repository takes its text from a single translatable XML file, comes in light and dark themes, and adjusts its layout to tablets and phones, so it can be presented in your users' own language and terminology.

Many organizations simply introduce the editor, or the entire Rule Repository, as another screen within their existing administrative portal.

You Decide Who Owns Decisions

Every organization is different. Some prefer that only developers create rules. Others allow analysts and operations teams to maintain them. Many use a review process where business users propose changes and technical teams approve them before deployment.

Code Effects supports all of these approaches because rules remain under your control. You decide who can create them, modify them, approve them, and publish them.

With the Rule Repository, this review process is built in: its decision workflow lets users request approval, approve or decline, Go Live and Take Offline, with a typed confirmation for every production change and at most one live version per rule. The repository has no users of its own: your application tells it who the current user is and what that user may do, from a set of 37 permissions enforced both in the interface and on the server. Every change is recorded with who made it and when.

AI follows the same rules. AI agents and services can draft, write and test rules, but every AI save waits for a person's approval, and they can never delete, approve, put a rule live or take it offline, even if your application grants those permissions by mistake.

Typical Implementation Timeline

For most projects, the first working prototype takes days rather than months.

1. Identify a business process with frequently changing logic.
2. Define the data that decisions depend on.
3. Embed the Rule Editor into an existing administration interface, or place the Rule Repository on one of its pages.
4. Store rules in the application's existing database, or let the Rule Repository keep them in a database you own.
5. Replace selected hard-coded conditions with rule evaluations.
6. Expand usage gradually as confidence grows.

How long it takes to reach production depends on how much rule management you need to build:

• Stand-alone, with your own storage, versioning and testing: typically 2 to 4 months for a team of two or three developers, or 2 to 5 hours for an AI coding agent, plus testing and review.
• With the Rule Repository: typically 3 to 4 days for one junior developer, or 1 to 2 hours for an AI coding agent, plus 1 to 2 days of testing.

See Code Effects Implementation for the components, their packages and the estimated time to production.

Organizations often start with a single use case and extend adoption naturally over time. The Rule Engine and the Rule Editor are free for personal, community, development and research use; for commercial use and the optional components, see Code Effects Packages.

What Changes and What Doesn't

What changes:

• Business logic becomes configurable.
• Decision policies become easier to maintain.
• Rules can evolve without modifying application code.
• Non-developers can participate in policy definition.
• With the Rule Repository, every change is versioned, tested, approved and recorded.
• With Audit, every production decision can be explained and reproduced.

What stays the same:

• Your applications.
• Your infrastructure.
• Your databases.
• Your security model.
• Your deployment processes.
• Your ownership of data and logic.

In other words, Code Effects does not ask you to rebuild what already works. It simply gives your software the ability to adapt when your business changes.

You don't adopt Code Effects by replacing your software. You adopt it by teaching the software you already have how to adapt to change.