Evincia
The Checklist Sampler
Paste a project file. Seven checks from the published checklist run in your browser, and nothing leaves this page.
Most inspectors do not publish their checklist. Ours is public: twelve risk categories and 51 signals, written out on the methodology page, including what each one reads and where it stops. This page goes one step further. Seven of those checks are re-implemented here in plain browser JavaScript, so instead of reading what the diagnostic looks for, you can run a piece of it against your own project file and see the output format on your own artifact.
It runs entirely in your browser. Open DevTools, switch to the network panel, paste your file, and run the checks -- no request carries your content; the sampler itself makes none at all. This page also omits the analytics tags every other page on this site carries, so there is nothing to explain away. Nothing you paste or open is uploaded, none of it is written to browser storage, and the page forgets your artifact when you close the tab.
While you are looking in DevTools, you will find two keys in browser storage, and neither of them is yours: evincia-theme, written if you use the light/dark toggle, and evincia-page-transition, written when you click through to another page. They are the site's own furniture and they are on every page here. Running the checks writes nothing at all -- which is the part you can verify by clearing storage, pasting a file, and watching it stay empty.
Three boundaries, stated up front, because a demonstration that oversells itself is worse than no demonstration:
- Seven checks drawn from the 51 published signals -- a sample of the checklist, not the checklist.
- One file, not the whole solution. The engine reads projects, dependencies, code, and configuration together, and the findings that change a plan usually come from the seams between them.
- Your browser, not your environment. In an engagement the engine runs inside the client's environment, reads the whole solution, and a senior architect reads the result and renders the judgment.
So: a taste of the method, deliberately not the assessment. It emits signals. It does not produce a score, and it never will -- the reason is at the bottom of this page.
Run it
Run the checks on your own file
A .csproj, a packages.config, or a web.config or app.config. One file at a time, up to 2 MB. Application source code is refused -- that boundary is deliberate, and the reason is the same one that governs an engagement.
Accepted: a .csproj project file, a packages.config, or a web.config or app.config. One file at a time, up to 2 MB.
Or drag a single file onto this panel. Files are read in the browser -- there is nothing to upload to.
Result
Nothing checked yet
Paste an artifact above, or choose a file, then run the checks. Accepted: a .csproj project file, a packages.config, or a web.config or app.config.
What runs
The seven checks
Each one is a port of a published signal, and each reads exactly what the engine reads from that artifact -- no more. Where this page reads less than the engine does, the card says so while you are looking at it.
| Check | Reads | What it looks at |
|---|---|---|
| Target frameworks | .csproj |
<TargetFramework>, <TargetFrameworks>, or the classic <TargetFrameworkVersion>. A .NET Framework target alongside a modern one reads as already in migration, not as a blocker. See Platform Obsolescence. |
| COM and ActiveX references | .csproj |
<COMReference> entries: the type-library name, version, and whether a registration GUID is recorded. See Internal Integration Complexity. |
| Dependency surface and era | .csproj · packages.config |
Counts of PackageReference, packages.config entries, and classic assembly references -- including the vendored ones carried by HintPath. Inventory only. See External Dependency Risk. |
| Configured authentication | web.config |
The <authentication mode> attribute: Forms, Windows, or the retired Passport scheme. None and absent produce nothing, deliberately. See Platform Obsolescence. |
| Session-state mode | web.config |
The declared <sessionState mode>: InProc, StateServer, SQLServer, or Custom. Off and absent produce nothing -- the framework default is never inferred. See Behavioral Coupling. |
| Database connections | web.config |
How many connection strings exist, which providers they name, and how many carry embedded credentials. Counts and providers only. See Data Complexity. |
| WCF endpoints and bindings | web.config |
<system.serviceModel> endpoint counts, service versus client, and the set of bindings in use. See Internal Integration Complexity. |
Two rules govern every one of them. A check never reports more than the engine would from the same artifact, because a sampler that over-flags is worse than one that under-flags -- if a target framework is ambiguous, this page takes the less alarming read. And no value read out of your file reaches a result card except from a fixed list: framework monikers, provider names, binding names, authentication and session modes, type-library names, and counts. Connection strings, application settings, machine keys, and file paths are read in memory and reported as counts -- they are never copied into a card. Your artifact is on screen in the box above, because that is where you put it; that box is the only place it appears, and nothing carries it any further.
Honest coverage
What this page cannot see
The gap between this and a Modernization Shield engagement is not a matter of degree. These are the things one pasted file cannot tell anybody, and they are where most of the risk turns out to live.
- Anything that needs the whole solution. Project fan-out, circular project references, layer boundary violations, shared projects that everything depends on, the same package pinned at three different versions across projects. One file has no view of the others.
- Your code. Static shared state, synchronous I/O, inline SQL sitting outside the data layer, WCF contracts, Windows-only API calls, test coverage. All of that is in the
.csfiles, which this page refuses on purpose. - SQL Server. Stored procedures carrying business logic, SQL Agent jobs, linked servers, triggers, compatibility levels. The connection string tells you a database exists. It tells you nothing about what is inside it.
- Package health. Whether a package is deprecated, unresolvable, or carries a known vulnerability needs a NuGet metadata lookup -- a network call. The engine makes it. This page will not phone anywhere, so it reports what is declared and stops.
- Judgment. Migration feasibility, embedded business logic, and domain knowledge risk are read by a senior architect, not by a parser. Three of the twelve categories work that way by design.
A clean result here means seven checks found nothing in one file. It is a real result and worth having. It is not a verdict on the system, and this page will not pretend otherwise.
Signals, not a score.
The 0-to-100 Modernization Readiness Score is senior-architect judgment, and it takes the whole solution rather than one file. That is why nothing on this page bands, ranks, or rates anything: a checklist item that fired is a fact, and a score is a decision about what the facts mean together. The sample report shows what that looks like when it is done properly -- 16 findings, each traced to the file behind it, one of them contested by the architect and re-rated after a code read.
About this page
Last updated: .
The seven checks are ports of published signals, written against the same detection descriptions on the methodology page. If one of them reads your file differently than you expect -- or differently than the methodology says it should -- that is worth telling us about. Email info@evincia.co.
Companion pages: the methodology for the full checklist, evidence of method for a single finding traced from raw signal to resolution, security and data handling for how the real engine operates inside a client environment, and the triage checklist for the manual inventory this page samples a corner of.