
How Evincia Works
From your code to a decision you can defend.
Evincia turns a legacy .NET system into a board-ready read on what is likely to break before you modernize. This is the whole path, end to end.
Most assessments ask you to trust a conclusion. This page shows how the conclusion is reached: what goes in, what the engine does, where the deterministic work ends and human judgment begins, and what comes out. Eight stages, in order.
From artifacts to executive decisions
Eight stages, in order. The deterministic work is stages two through four. Stage five is optional AI-assisted synthesis after those deterministic outputs exist, governed by the client's rules. A named senior architect owns stage six and signs what ships. The detail for each stage is below.
- Artifacts What goes in is the system as built.
- Diagnostic Engine A deterministic reader, not a language model.
- Evidence Findings supported by source artifacts.
- Risk Rules The same evidence, weighed the same way every time.
- Optional AI-Assisted Synthesis After deterministic outputs, and only if the client allows it.
- Senior Architect Review A named human owns the result.
- LMRR The written deliverable for the people who decide.
- Executive Decisions The reason the whole thing exists.
Stage by stage
1. Artifacts -- what goes in is the system as built.
The starting point is what you already have: the .NET solution and its source, the .csproj and web.config files, the SQL Server schema, the things that live in source control. No questionnaire, no self-assessment, no architecture diagram drawn from memory. Evincia reads the system as it was built, not as it was described.
2. Diagnostic Engine -- a deterministic reader, not a language model.
The engine is a Roslyn-based static analyzer -- a CLI application a senior architect operates in the client's environment, with no AI and no required network calls outside the client's network. It walks the C# code and the project artifacts and extracts signals: the platform targets, the coupling, the dependency risk, the places change is unsafe. It is rules-based and reproducible. The same code in yields the same signals out, every run. The engine reads the C# code side; the database and SQL Server tier is covered by the architect's hands-on review in stage six.
3. Evidence -- findings supported by source artifacts.
Signals point back to source files, project artifacts, configuration, dependencies, or other supporting evidence. This is the raw material of the assessment: located facts. A finding without supporting evidence does not belong in the report.
4. Risk Rules -- the same evidence, weighed the same way every time.
The evidence runs through a fixed set of deterministic rules that weigh how likely a problem is against how much it would hurt, and rank the result. Two reviewers running the same code get the same priorities, because the priorities are computed, not argued. What the rules measure is published; how they weigh and combine the evidence is the part Evincia keeps to itself.
5. Optional AI-Assisted Synthesis -- after deterministic outputs, and only on the client's terms.
AI-assisted synthesis happens only after the deterministic outputs exist, and it can be turned off entirely. If it is approved, it runs on the client's terms -- inside the client environment, against the client's designated model, or with client-approved external tooling. It does not find the risks, it does not score them, and it does not decide the diagnosis. Read the full Security & Data Handling boundary.
6. Senior Architect Review -- a named human owns the result.
The architect does what the engine cannot. They review the database and SQL Server tier by hand, weigh the categories that take judgment, set the 0-100 Modernization Readiness Score, and sign the report. The engine provides the consistency. The architect provides the judgment. Nothing leaves without a name on it.
7. LMRR -- one report, written for the people who decide.
The Legacy Modernization Risk Report is the deliverable: the readiness score, the four-dimension risk radar, the prioritized risks, each carrying its evidence, and a plain-language read a non-specialist executive can follow. It is built to be forwarded, and built to be checked. The SocialGoal sample Modernization Risk Report shows this workflow end to end: evidence collection, diagnostic findings, risk scoring, optional AI-assisted synthesis, senior architect review, and executive-ready recommendations.
8. Executive Decisions -- the reason the whole thing exists.
Approve the modernization budget, or hold it. Sequence the work so the fragile parts go first. Choose a vendor with eyes open. Set a timeline you can defend, or decide the system is not ready to move yet. The read exists so the decision is made on evidence, before the money and the calendar are committed. This is the decision Modernization Shield is built to inform; across a portfolio, private equity diligence applies the same read application by application.
Why this flow is different
Two things separate this from a typical assessment, and both come straight from the stages above.
- A deterministic spine. Stages two through four produce the same findings on the same code, every time. That is what makes the read checkable, comparable across applications, and hard to argue with.
- A human gate. Stage six puts a named senior architect between the engine and your decision. The score is set by judgment, and someone signs it.
You get the consistency of a machine and the accountability of a person. Most assessments give you one or the other. Both properties are examined in detail in why the score is defensible.
Who reads the output
- CIOs and CTOs: an independent read before committing a budget, a vendor, or a timeline.
- Architects and engineering leaders: located evidence they can verify against their own code.
- Private equity deal teams: a comparable, repeatable read across a portfolio of applications, pre- or post-close.
See the flow end to end
Two ways in: check fit for Modernization Shield, or inspect the SocialGoal sample Modernization Risk Report to see where the flow ends. For what the diagnostic measures, see the methodology; for why the score holds up under scrutiny, see why the score is defensible; for the client-environment and optional-AI boundary, see Security & Data Handling.
