From Excel to a Scoring API: Eliminating Logic Drift
The Model Worked. The Software Didn’t.
Many rating, scoring and classification systems begin life as Excel models.
Business experts define:
- scoring criteria
- weighting factors
- rating calculations
- classification rules
- final score calculations
The model itself works.
The challenge begins when the organization tries to reproduce that model in software.
Years of Rebuilding the Same Logic
In this project, the original Excel-based scoring model was manually reimplemented in PHP.
On paper, the process looked straightforward:
flowchart TD
A[Excel Scoring Model]
B[Manual Reimplementation in Application Code]
C[Classification Result]
A --> B
B --> CIn practice, however, the software gradually diverged from the original model. New defects were fixed. New inconsistencies appeared elsewhere. Additional releases followed. Yet the implementation never fully matched the original scoring model.
Eventually, two versions of the same logic existed:
- the original business model
- the software implementation
And both continued to drift apart.
The Turning Point: Excel Becomes the Source Code
CLE introduced a different approach.
Instead of rebuilding the model, the original Excel file became the model.
The scoring system was no longer translated into software.
It was executed directly.
flowchart TD
A[Excel Scoring Model]
B[CLE]
C[Scoring API]
D[Classification Result]
A --> B
B --> C
C --> DThe Excel model remained the single source of truth.
There was no second implementation.
- No manual rule replication
- No code translation
- No synchronization effort
- No logic drift
The model was no longer rebuilt. It was executed.
The Result
The expected classification results appeared immediately. Not because a new ruleset had been developed. But because the original ruleset was finally being executed directly.
The system no longer calculated something similar to the model. The system executed the model itself.
Business Model ≠ Software Implementation
This problem disappeared completely. Only one version of the truth remained.
The real proof of the approach came years after deployment. A business user modified parts of the scoring model despite not being involved in either the original model design or the original implementation. The changes were made directly in the model and immediately produced the expected results. No specialized development knowledge was required. No hidden logic had to be rediscovered.
The knowledge remained in the model, not in the heads of individual developers.
Scoring Logic as an API
The same scoring model can be exposed as a Scoring API.
Applications submit business objects and receive scores, ratings and classification results in return.
Input
POST /api/decision
Content-Type: application/json
[{
"totalNumberOfUnits": 55,
"residentialPitches": 15,
"residentialPitchesWithOwnSanitaryFacilities": 10,
"speciallyPitchesForCampingCarsOnCampsite": 5,
...
}]
Output
HTTP 200 OK
[{
"totalNumberOfUnits": 55,
"residentialPitches": 15,
"residentialPitchesWithOwnSanitaryFacilities": 10,
"speciallyPitchesForCampingCarsOnCampsite": 5,
...
"numberOfRegularTouristPitches": 35,
"totalNumberTouristicPitches":40,
...
"scoreQualitySanitaryFacilities": 9,
"stars_2026" : 4.5
}]
The scoring model remains unchanged.
Only the integration mechanism changes.
A single scoring model can therefore be reused across applications, reporting platforms, customer portals, mobile apps and external systems.
Why Explainability Matters
A score alone is rarely enough.
The important question is:
Why did the system assign this rating?
Modern scoring systems must explain:
- which criteria were evaluated
- which sub-scores were calculated
- which rules influenced the result
- how the final classification was derived
CLE was designed for explainable business decisions from the beginning.
→ Explainable Decisions: See How Business Decisions Are Made
Why This Matters for Scoring APIs
Organizations often already possess scoring expertise.
What they struggle with is maintaining consistency between the business model and the software implementation.
CLE solves this problem by making the business model executable.
- The business model remains the source of truth.
- Excel remains the modeling language.
- Applications consume decisions through APIs.
- Changes happen in the model, not in code.
- Scores remain consistent and explainable.
The challenge was never creating the scoring model.
The challenge was keeping software aligned with that model over time.
CLE solved that problem by executing the model directly.
