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 ↓
Census note Loading the snapshot…
Measured code546,549source lines
Source surface2,026files
Systems15shipped & prototyped
Average system36,437lines per project
Median systemlines per project
Code densitylines per file
Language familiesin measured source
Delivery range07platform surfaces
Technologiesdistinct in the stack
Documented capabilitiesacross all case studies
Architecture layersdescribed end to end
Largest systemshare of all code

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.

15 systems shown

SystemRelative code footprintLinesFilesLines / fileDominant language

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.

Few files · denseSingle-surface tools and portable viewers where one file carries the product.
Many files · denseEngines and platforms: modular, but each module carries real logic.
Few files · lightFocused add-ins that do one job inside a host application.
Many files · lightComponent-heavy interfaces where structure is spread across small units.

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.
See what the code actually does