The Problem

Business logic for nested objects is often implemented directly inside application code.

Developers read values from complex JSON structures, apply business rules and write the resulting values back into the object.

What begins as a simple business decision eventually becomes application logic.

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

{
  "address": {
    "street": "4714 Echoglenn N.W.",
    "zipcode": "44718",
    "city": "Canton",
    "state": "OH"
  }
}

The application extracts the individual values, builds a formatted address block and stores the result.

A simple business decision becomes another piece of code that must be maintained, tested and deployed.

Over time the same pattern appears throughout the application landscape.

• Formatting logic
• Validation logic
• Classification logic
• Enrichment logic
• Naming logic

Business decisions become scattered across services, APIs, integrations and custom applications.

---

The Solution

CLE evaluates decision models directly against nested business objects.

Values from nested JSON paths can be mapped into Excel decision models and used in calculations, validations, classifications, lookups and enrichment logic.

Applications submit business objects as JSON.

CLE evaluates the decision model and returns an enriched business object while preserving nested objects and collections within the original payload.

---

Example: Address Block Generation

Input Business Object

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

{
  "address": {
    "street": "4714 Echoglenn N.W.",
    "zipcode": "44180",
    "city": "Canton",
    "state": "OH"
  }
}

Input Mapping And Decision Model

address.street
address.zipcode
address.city
address.state

Output Business Object

HTTP 200 OK

{
  "address": {
    "street": "4714 Echoglenn N.W.",
    "zipcode": "44180",
    "city": "Canton",
    "state": "OH"
  },
  "addressBlock": "4714 Echoglenn N.W.\nCANTON, OH 44180"
}

The original object remains intact.

CLE adds a derived business attribute while preserving the existing structure.

---

Beyond Address Formatting

The same approach can be applied to many business decisions.

• Product Naming
• Customer Classification
• Product Enrichment
• Validation

---

Arrays And Collections

Business objects often contain collections rather than individual values.

For example:

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

{
  "orderLines": [
    {
      "product": "A123",
      "quantity": 10
    },
    {
      "product": "B456",
      "quantity": 5
    }
  ]
}

CLE can evaluate nested sub-objects and collections as part of the same decision model.

This allows business decisions to operate directly on real API payloads rather than simplified flat structures.

Typical examples include:

• Order positions
• Product attributes
• Contacts
• Addresses
• Contract parties
• Product variants
• Activities
• Classifications

---

One Decision Model. Real Business Objects.

Business applications already exchange structured JSON payloads.

CLE allows organizations to apply business decisions directly to these objects without introducing additional mapping layers, custom transformation logic or duplicated application code.

Applications remain responsible for:

• User interfaces
• Workflows
• Integrations
• Data storage

Business experts remain responsible for:

• Business rules
• Validations
• Classifications
• Enrichment logic
• Derived attributes

CLE provides the execution layer in between.

Use real business objects as API inputs. Evaluate business decisions in Excel. Return enriched business objects through APIs.