Evidence · Source census · Snapshot 27 July 2026
The work,
measured.
Repository scale is not the same as product quality—but it reveals the engineering surface behind the interfaces. These figures measure project-owned source, not installed dependencies or generated output.
Read the counting method ↓Language distribution
Seven families,
one method.
Every measured line, grouped into language families. The spread is deliberate: the same architectural pattern is re-implemented wherever the user actually works. Select a family to filter the atlas below.
Repository atlas
Compare the footprint.
Search, filter, sort and expand any row for its full language breakdown, technology palette and delivery surfaces. Press / to jump to search.
No system matches that filter.
Density map
Files against lines.
Every system plotted by file count and line count. Bubble size is code density—lines per file. Position tells you whether a system is many small modules or a few dense engines.
Hover a node to inspect it.
Interactive comparison
Put two systems side by side.
Footprint, file density and dominant implementation language shift dramatically with the delivery surface. Swap, shuffle, or pick any pair.
Concentration
Where the code
actually is.
Portfolios are never evenly weighted. Drag the control to see how much of the measured code the largest systems account for—and how much sits in the long tail of focused tools.
Technology recurrence
What repeats,
and what is chosen once.
Every technology named across the fifteen case studies, scaled by how often it recurs. Recurrence signals a working method; single appearances signal a decision made for one specific problem. Select any technology to filter the atlas.
Delivery surfaces
Seven places
the work lands.
The same architectural ideas ship as browser platforms, Windows desktops, host-application add-ins, Blender extensions, Office task panes, local servers and Android packages.
Workflow evidence
Complexity has a direction.
The portfolio repeatedly converts specialist inputs into connected decisions and deployable outputs. Each lane shows the systems that carry that stage, with their combined measured footprint.
Interoperability census
What goes in.
What comes out.
Formats, records and artefacts named across the case studies. Repeated entries indicate the formats the portfolio has to speak fluently.
Counting method
What the figures include.
A reproducible source-footprint census taken from the working projects on 27 July 2026.
- Included
- Project-owned source files in the principal application, server, test, tooling and add-in folders. Text formats relevant to each stack are counted line by line, including blank and comment lines.
- Excluded
- node_modules, NuGet packages, generated builds, distribution folders, binaries, archives, caches, temporary output and vendored or third-party libraries.
- Language grouping
- Related dialects are grouped into families for readability: JSX counts as JavaScript, TSX as TypeScript, and CSS, HTML and XAML are grouped as markup and styling.
- Reconciliation
- Per-language breakdowns list the principal formats in each repository, so a small remainder of minor file types is reported separately rather than being silently absorbed.
- Density
- Lines per file is a structural signal, not a quality score. A high figure suggests dense engines or generated-adjacent formats; a low figure suggests many small composable units.
- Interpretation
- Counts describe implementation surface, not productivity or quality. A large engine and a focused add-in solve different problems; both can be substantial engineering.
- Not measured
- Design iterations, discarded branches, schema modelling, domain research, user testing, support work and the specification effort that precedes any of this code.
- Snapshot
- These are current working-directory measurements and will evolve as the products change. Re-running the census produces a new set of figures, not a corrected one.