Before Modernization Shield
- We think the migration is straightforward.
- The database should be fine.
- The vendor estimate looks reasonable.
- AI should help us move faster.
Evincia
Why the score is defensible
The Modernization Readiness Score ends up in front of boards, investment committees, auditors, and insurers. This page is for the person who has to present it there: the chain of custody between the codebase and the number, and what to hand the skeptic in the room.
From artifacts to a number
Every Legacy Modernization Risk Report (LMRR) score is produced the same way, in the same order. The score is the senior architect's synthesis of the engine's signals: the architect assigns the 0-to-100 number from the dimension reads -- the engine does not compute it. Nothing enters that judgment that did not come through the pipeline described below.
Evincia's read follows an eight-stage path from system artifacts to the score, set out in full in How Evincia Works. The categories those stages evaluate are documented in the methodology. This page answers the next question: why the number that comes out the other end holds up under scrutiny.
Diagnostic visibility
Before the diagnostic, everything looks like opinion.
After Modernization Shield
- These dependencies drive the sequencing risk.
- These stored procedures carry business logic.
- These integrations affect outage planning.
- These findings should change scope, budget, or timing.
The deliverable is not a modernization pitch. It is a decision instrument.
Deterministic by construction
The diagnosis itself uses no AI. The engine reads the source -- it does not sample it, and it does not guess -- and weighs what it finds against a fixed rules layer. Run it twice on the same system and you get the same findings. That is not a property most assessments can claim, and it is the first thing to say when someone asks whether the evidence is reproducible. The number is a different kind of claim -- assigned, not computed -- and it is defended a different way: not by re-running it, but by auditing it. That case is the rest of this page.
Gates, not promises
Three machine checks stand between the engine and anything a client sees. A run that falls below the coverage gate fails -- it does not quietly produce a thinner report. When AI drafts the narrative, a claim that cites evidence the deterministic output does not contain fails the run before a human ever reads it -- an invented finding is not reviewed out; it is structurally unable to ship (an engagement with AI turned off has no machine-drafted narrative to gate). And the engine itself cannot be released if it stops catching a labeled corpus of known hidden risks -- the benchmark blocks the release the way a failing test blocks a deploy. If any part of the analysis runs with reduced confidence (for example, due to cross-project load failures like those logged in the public SocialGoal sample), that reduced confidence is declared in the deliverable.
Every artifact is stamped with the engine version that produced it, and the test suite guarding all of this is larger than the engine it tests. None of this is visible in the report's prose. All of it is why the prose can be trusted.
The scoring is published, not a black box
Anyone challenging the score can read exactly what it measures: twelve categories, four Modernization Readiness dimensions, a 0-to-100 scale with published Red, Yellow, and Green zones. The whole structure is on the methodology page, including an interactive explorer that shows how the rollup is structured. Seven of its checks also run in your browser, against your own project file. And interrogation is the right test for a judgment: the evidence beneath the score is deterministic and cited to source, the judgment layered on it is labeled as judgment, and the architect's reasoning ships with the finding. The R-003 trace shows that chain of custody holding under dispute: the engine rated the finding Critical, the architect overruled it, the disagreement shipped visible, and it closed with a dated ruling. A score you can interrogate beats a score you have to trust.
Findings cite supporting artifacts
No finding in an LMRR floats free. Findings carry source artifacts -- projects, files, configuration entries, stored procedures, dependencies, or other supporting evidence -- and the evidence appendix ships with the report. The finding-anatomy walkthrough traces one real finding, R-003 from the SocialGoal sample report, from raw signal to dated resolution; the SocialGoal sample Modernization Risk Report shows the register schema those findings land in. When the room asks "says who?", the answer is evidence, not a feeling.
Judgment is labeled as judgment
Nine of the twelve categories are engine-detected. Three -- Migration Feasibility, Embedded Business Logic Risk, and Domain Knowledge Risk -- are explicitly a senior architect's call, and the report says so. So is the composite: the architect assigns the four dimension reads and the 0-to-100 score from them. If the client's rules permit AI-assisted synthesis, it happens only after the deterministic outputs exist and can be turned off entirely (Security & Data Handling). It is never the source of the initial evidence set, and it is never the source of a conclusion. Nothing in the score is laundered through false automation: where a human judged, the report names the judgment.
The limits are in the report
What the diagnostic cannot see from code, it says it cannot see. Uncertain findings are marked uncertain rather than scored confidently. Questions that need direct database access or a stakeholder conversation are named as open, not papered over. A number that admits what it does not know is harder to attack than one that claims everything.
Tested in the open
The same engine and the same twelve categories run publicly against well-known open-source .NET codebases, with the repository and pinned commit published so the cited evidence can be checked against the source. The teardown program also documents where the engine's own first-run false positives were found and corrected. Ask any other assessor for their list of corrected mistakes.
What the score does not claim
- It is not a guarantee of project outcomes. It measures readiness at a point in time; it does not promise the modernization will succeed.
- It is not an audit opinion or a compliance certification.
- It is not a substitute for the evidence behind it. The number means what it means because of the appendix attached to it -- quoted without the evidence, it is just a number.
- It is current as of the engagement. Systems drift; scores age.
That candor is deliberate. A score that overclaims invites the challenge it cannot survive.
Want to see the evidence behind the number?
Bring the appendix, not just the score. The report is structured so the hardest question in the room -- "how do you know?" -- has a direct answer: here is the finding, here is the artifact it came from, here is the business impact, and here is the recommended sequence.
The sample is the fastest way to see that structure end to end, with the score sitting on top of the evidence rather than in place of it.