Turn Excel Decision Models Into APIs

flowchart TB

    D["<b>Excel Workbook<br/>(Source Code)"</b>]
    C["<b>CLE<br/>Decision Runtime</b>"]
    A["<b>Enterprise Applications</b>"]

    D ==> C

    A -->|"INPUT<br/><b>  Business Object  <br/>(JSON)</b>"| C
    C -->|"OUTPUT<br/><b> Enriched Business Object + Decision Results</b>"| A

    C:::Rose

    classDef Rose stroke-width:1px,stroke:#FF5978,fill:#FFDFE5

    style A fill:#E3F2FD
    style D fill:#FFF9C4,stroke:#D4AF37

    linkStyle 0 stroke:#D4AF37
    linkStyle 1 stroke:#000000
    linkStyle 2 stroke:#000000

The Problem

Business Logic Becomes Fragmented

Business logic rarely becomes fragmented overnight.

A pricing calculation is added to an ERP system. A validation rule is implemented inside an integration process. Product classification is maintained in a PIM system. Additional requirements appear in scripts, database procedures or spreadsheets. Each change makes sense individually, but over time the same business decision begins to exist in multiple places.

As business requirements evolve, teams must maintain multiple implementations of the same decision across different applications and technologies. Small changes become increasingly expensive because every modification requires coordination, testing and deployment across several systems.

A simple business change often becomes a software project. A pricing factor changes from 1.5 to 1.55. Someone must first identify where that logic is implemented, whether it exists in application code, scripts, database procedures or integration processes, assess the impact, modify the implementation, test the change and redeploy the affected systems. The business decision may be simple. The implementation rarely is.

The result is familiar:

• Simple changes turn into long and expensive IT projects.
• Duplicated business logic
• Inconsistent decision outcomes
• Slower change cycles
• Higher maintenance costs
• Growing technical debt

As decision complexity grows, maintaining the logic often becomes harder than maintaining the software itself.

The business decision takes minutes. The software change may take days or weeks.

The Solution

Separate Business Decisions From Application Code

CLE introduces a dedicated execution layer for business decisions. Rather than embedding pricing logic, validations, classifications and business rules directly into application code, these decisions are maintained as independent decision models and executed by a specialized runtime.

Applications remain responsible for data, workflows, integrations and user experiences, while business experts remain responsible for defining how decisions should be made. CLE connects these two worlds by executing decision models independently from the applications that consume them, allowing business changes to be implemented without repeatedly modifying and redeploying application code.

Applications submit business objects as JSON. CLE evaluates the appropriate decision model and returns calculated attributes, classifications, validations and decision outcomes through REST APIs.

flowchart TB

    A["Application"]
    C["CLE<br/>Contene Logic Engine<br/>Decision Runtime"]


    A ==>|"JSON Business Object"| C
    C ==>|"JSON Business Object + Calculated Attributes"| A

    C:::Rose

    classDef Rose stroke-width:1px,stroke:#FF5978,fill:#FFDFE5
    style A fill:#E3F2FD

    linkStyle 0 stroke:#000000
    linkStyle 1 stroke:#000000

This creates a clear separation of responsibilities while ensuring that the same decisions can be reused consistently across every connected system.

Beyond Traditional Rule Engines

Traditional rule engines are often built around decision tables and condition-action rules. While this approach works well for relatively simple scenarios, real business decisions rarely remain that simple for long.

Pricing decisions depend on customer groups, product structures, currencies, quantity breaks and exception handling. Publishing decisions may depend on data quality checks, completeness scores, successor relationships and regulatory requirements, while enrichment decisions often combine calculations, lookups, validations and reference data.

Over time these decisions evolve into interconnected networks of business logic rather than isolated rules. CLE was designed for exactly these scenarios, executing complete decision models instead of evaluating individual rules in isolation.

These are not isolated rules. They are decision models.

flowchart TD

    S["Product Status"]
    K["Category"]
    P["Pricing & Saleability"]
    L["Logistics"]

    B["Images"]
    D["Datasheets"]
    T["Technical Attributes"]

    B --> IQ["Information Quality"]
    D --> IQ
    T --> IQ

    EA["Replacement Product"]
    SA["Substitute Product"]

    EA --> ER["Replacement Logic"]
    SA --> ER

    S --> V["Product Publishability"]
    K --> V
    P --> V
    L --> V
    IQ --> V
    ER --> V

CLE executes complete decision models that combine:

• Calculations
• Validations
• Lookups
• Reference Data
• Nested Logic
• Dependency Chains
• Derived Attributes

Instead of evaluating isolated rules, CLE executes interconnected decision models.

Excel Is The Authoring Tool. Not The Runtime.

Business decisions are rarely defined by a single rule.

A publishing decision may depend on product status, pricing, logistics, information quality, technical attributes, replacement products and many other interconnected factors. Over time these dependencies form complete decision models rather than isolated business rules.

Business experts already model these relationships in spreadsheets. They use formulas, lookup tables, reference data, classifications and validations to describe how decisions should be made and how different factors influence one another.

Rather than introducing another proprietary modeling language, CLE uses Excel as the authoring environment for these decision models.

The workbook becomes the central definition of the decision model.

Excel is not the runtime.

CLE analyzes the workbook, identifies dependencies and compiles the decision model into an executable dependency graph. The workbook remains the authoring environment, while production systems execute the compiled model through APIs.

The Excel workbook is the source code. CLE compiles the workbook into a dependency graph. The dependency graph is the executable artifact.

CLE provides the execution layer between business expertise and software implementation. Business experts maintain the decision models, applications consume the results, and CLE keeps both sides independent.

Applications Consume Decisions

Applications submit business objects through REST APIs. CLE evaluates the decision model and enriches the business object with calculated attributes and decision outcomes.

flowchart TB

    A["CLE Contene Logic Engine"]
    B["REST APIs"]

    A <==> B
    B <==> E["ERP"] & F["PIM"] & G["CPQ"] & H["CRM"] & I["SaaS"] & n1["Custom Applications"]


    classDef Engine fill:#FFDFE5,stroke:#FF5978,color:#8E2236
    classDef Api fill:#C8E6C9,stroke:#4CAF50

    class A Engine
    class B,C Api

Applications and enterprise systems consume decision results through REST APIs.

Input

POST /api/decision
Content-Type: application/json

[{
  "country": "Italy",
  "weight": 205,
  "currency": "EUR",
  "requestedQuantity": 300,
  "purchasePrice": 1.35
}]

Output

HTTP 200 OK
(annotated for clarity)

[{
  "country": "ITALY",       // standardized
  "iso_code": "IT",         // added
  "weight": 205,
  "weightClass": "heavy",   // added
  "currency": "EUR",
  "requestedQuantity": 300,
  "purchasePrice": 1.35,
  "purchaseTier": 3,        // calculated
  "marginFactor": 1.81481,  // calculated
  "salesPrice": 2.45        // calculated
}]

The input object is enriched with additional business attributes while preserving its original structure.

Explainable By Design

Business decisions often need to be understood long after they have been executed. Developers need to troubleshoot them, analysts need to maintain them, support teams need to explain them and auditors need to verify them. For this reason, CLE focuses on deterministic and transparent execution rather than opaque rule processing.

Every decision can be traced back to:

• Input values
• Formulas
• Lookup Tables
• Intermediate Calculations
• Decision Paths
• Business Documentation

This allows organizations to understand not only what decision was made, but why it was made and how the result was produced.

Built for complex enterprise decisions

CLE is designed for business decisions that evolve faster than application releases.

Typical use cases include:

• Pricing and Discount Calculation
• Product Classification
• Product Enrichment
• Product Publishing Decisions
• Product Configuration
• Data Validation
• Shipping Logic
• Tax Determination
• Regulatory Compliance
• Customer-Specific Business Rules

Wherever business decisions change more rapidly than software, CLE provides a cleaner architecture.

Stateless. Lightweight. Deployable on Docker.

CLE is designed as a lightweight runtime component.

The runtime does not require a database for business data and evaluates decision models in memory. Decision models are exposed through REST APIs and can be consumed by any application that needs decision results.

CLE can be deployed alongside:

• ERP Systems
• PIM Systems
• CPQ Solutions
• CRM Platforms
• SaaS Applications
• Custom Software

It runs on Docker environments and scales independently from the applications that consume it.

A Dedicated Runtime For Business Decisions

Applications should not need to be redeployed every time a pricing rule changes.
Business decisions should not be duplicated across systems.
Decision models should not disappear into application code.

CLE provides a dedicated runtime for business decisions. Instead of embedding pricing logic, validations, classifications and business rules directly into application code, these decisions are maintained as independent decision models and executed by a dedicated runtime layer. Applications consume the results, while business experts continue to maintain the underlying logic. As a result, decision models and application code can evolve independently without becoming tightly coupled to one another.

Model once. Compile once. Expose through APIs. Reuse everywhere.