Solution · How the analysis works
How Codeego’s analysis works
Codeego combines deterministic computation with bounded AI judgement to produce Certified Software Valuations that are rigorous, auditable and reproducible.
This page explains how that works, with a focus on the Expert tier, where the engineering behind the numbers matters most for due diligence.
Why this matters
A valuation is only as good as your ability to defend it
Investors, acquirers, auditors, and courts do not accept “the AI said so.” They need to know that the same codebase, assessed twice, yields the same answer, and that every figure traces back to something observable in the code.
Most AI tools are a black box: ask the same question twice and you get two different answers. Codeego is built the opposite way. The intelligence of a large language model is used where human-level judgement is genuinely required, but it is constrained, calibrated and audited by deterministic logic so the result holds up under scrutiny.
Two engines, one result
Every assessment is produced by two cooperating layers
A deterministic layer
Pure, rule-based computation that runs in code. Given the same inputs, it always produces the same output. It handles everything that can be measured or computed directly: code metrics, the scoring rubric, and the final hours/cost formula.
A bounded AI layer
A large language model reads the codebase and forms judgements on qualities that cannot be measured by counting alone: system-design sophistication, domain complexity, the size of the security surface. Crucially, the model never has the final word: its outputs are clamped to ranges set by hard metrics and calibrated against observable evidence.
The division of labour is deliberate: the AI contributes informed judgement; the deterministic layer turns that judgement into defensible numbers.
The pipeline
From source code to certified numbers
Reproducibility and auditability, by design. Every stage is either measured deterministically or bounded by what the measurements justify.
Tap a stage to highlight it in the schema below, or tap its arrow to read the explanation.
Static metrics
Before any narrative is written, Codeego extracts static metrics directly from the source: lines of code per language, cyclomatic complexity, the dependency graph, test-to-source ratios, and the infrastructure footprint. These are facts about the code, not opinions, identical every time.
The deterministic layer
Facts about the code, not opinions
Before any narrative is written, Codeego extracts a set of static metrics directly from the source: lines of code per language, cyclomatic complexity, the dependency graph, test-to-source ratios, and the infrastructure footprint: containers, orchestration, infrastructure-as-code, CI/CD. These are identical every time.
Each metric is produced by a purpose-built tool or parser, not by the model:
Complexity
radon
Cyclomatic complexity measured by analysing the actual structure of the code rather than guessing at it.
Security surface
Semgrep
Industry-standard static analysis across multiple languages; warning- and error-level findings feed directly into the Security score.
Dependencies
ecosystem manifests
The graph is read straight from package.json, pyproject.toml, go.mod, Cargo.toml and others.
Size & test coverage
LOC + conventions
Lines counted per language by file type; test code identified by recognised conventions (*.test.*, test_*) to compute a test-to-source ratio.
Infrastructure
the files themselves
Dockerfiles and Compose files, Terraform, Kubernetes manifests, and CI/CD configuration: GitHub Actions, GitLab CI, and similar.
Because these tools read the code deterministically, the same repository always yields the same metrics: the foundation everything else is built on.
An evidence-based rubric
Each technical dimension is assessed against explicit, published criteria organised into bands. A score is assigned to the band whose criteria the code actually satisfies, justified by concrete findings rather than impression. The seven technical dimensions produce the Production Readiness Score:
The eighth dimension, Economic, is derived from them: the deterministic formula reads the same analysis and translates it into a value range (covered in the Expert tier below), rather than contributing a score of its own. Two deterministic rules remove residual noise:
When a result sits between two bands, the lower band is always chosen.
Scores are rounded to standard increments (dimension scores to the nearest 5, effort to the nearest 10 hours) because precision beyond that is not meaningful.
Same code in, same numbers out. By construction.
The bounded AI layer
Judgement, on a leash
Some questions genuinely require reading and understanding code, not just counting it: How sophisticated is the system design? How intricate is the business domain? How large is the security surface? Here Codeego asks a large language model to form a judgement, but it is judgement on a leash.
01
Strict determinism in the model
Every analysis runs the model at temperature zero with a fixed random seed and greedy decoding, so the model makes the same choices on the same input. Context is compressed on a fixed schedule, and the model provider is never swapped midway through an analysis. The AI step itself is reproducible, not just the maths around it.
02
Signals are bounded
The model expresses each complexity judgement on a fixed scale, then those values are stabilised: clamped into a range whose floor and ceiling are derived from the hard static metrics. A model that underrates a large, polyglot, infrastructure-heavy system is pulled up; one that overrates a small script is pulled down. Judgement is permitted only within limits the measurable facts justify.
03
Scores are calibrated
Quality scores are tied back to evidence. A codebase with no tests cannot score highly on test coverage; one with no linter cannot score highly on code quality, regardless of what the model proposes. These ceilings apply to every tier. On the Expert tier, evidence-backed floors also apply, so strong, well-tested, well-documented code is properly credited rather than under-marked.
Two passes
The narrative, kept honest
1
Scoring pass
Produces the structured data: the KPI scores, the bounded signals, and the investment figures.
2
Reporting pass
Produces the written report, from the already-finalised numbers of the first pass as its source of truth.
This guarantees the prose in the report cannot drift away from the figures in the data: the narrative explains the numbers; it never invents its own.
Expert tier
How the valuation is built
On the Expert tier, the investment figure is not an AI estimate. The hours and cost are produced by a deterministic formula in code that composes three inputs:
01 · Static metrics
The measured size and shape of the codebase establish a baseline effort, adjusted by code-intrinsic factors such as complexity, dependency breadth, and infrastructure footprint.
02 · Bounded AI signals
The stabilised, evidence-clamped judgements on system design, domain, integration and the security surface adjust that baseline within their permitted ranges.
03 · Scenario factors
Your context is applied last: the working mode (in-house, near-shore, off-shore), the degree of AI tooling adoption, and a location-based market rate band convert effort into a realistic cost range.
Because the scenario factors are applied deterministically in code, you can re-price the same analysis under different assumptions (a different team location or AI-adoption level) without re-running the model, and the result recomputes exactly.
Maintenance cost
Handled the same way: the model inventories the running infrastructure (compute, databases, queues, storage, specialised workloads), and a deterministic schedule turns those counts into a monthly operating-cost range.
A full audit trail
Every Expert valuation carries an internal breakdown recording each factor that contributed to the final number: the baseline, every adjustment, and the scenario multipliers. Every figure is traceable to either a measured metric or a bounded, calibrated signal. Nothing is unaccounted for.
The outcome
A valuation you can stand behind
Reproducible
The same code and the same scenario produce the same result, every time.
Auditable
Every number traces back to a measured metric or a bounded, calibrated signal, recorded in a signed audit trail with a full internal breakdown on the Expert tier.
Defensible
AI judgement is used where it adds value, but it can never contradict the observable evidence in your code.
That is the difference between a number a model happened to produce and a valuation that withstands due diligence.