KUIPER / LIVE ISSUED KEYS loading ADDRESS SPACE loading COMMITS loading REPOSITORIES loading LAST MEASURED loading

GLOBALGRID2050 / VENTUS LTD / KUIPER

What is the Kuiper?

Kuiper began as a way to see an expanding estate of code on one dashboard. The solution was to stop treating the estate as a pile of files and give its measured history a deterministic mathematical address space.

LIVE KUIPER VIEW the page captures the actual Kuiper canvas when the browser allows it

This art is sourced from the Kuiper itself, not a decorative illustration. If a same-origin canvas capture is available it becomes a frozen live snapshot; otherwise the embedded live view remains visible.

Why it exists

A visibility problem became an addressing problem.

globalgrid2050.com is a Ventus Ltd project that has accumulated billions of historical line occurrences across code, data and engineering work through continuous machine-learning and computational iteration. That process has combined AI development tools such as Codex and Claude, Python and CuPy GPU computation, automated CI/CD and GitHub Actions runs, repeated software testing, calibrated hardware and software environments, and Windows and Linux machines configured around the workloads.

The resulting code estate is therefore not simply a collection of AI-generated code. It is the accumulated record of repeated human-directed computation, automation, testing and machine-assisted development over time. Kuiper emerged from a practical problem created by that scale: how do we see and organise such a large body of work on one dashboard when it is distributed across many repositories, files, commits, datasets and computational runs?

The Key

The Key is the chronological address of a measured line occurrence.

Kuiper measures historical line occurrences and gives each issued occurrence its own numerical Key. Earlier measured material receives earlier Keys and later material is appended further out. The Key is unique even when the underlying text is repeated, because Kuiper is preserving the history of iteration rather than pretending that repeated states never happened.

Measure
tools/count_lines.py — its entries mode walks every file entry in every commit, deliberately including repeated historical occurrences.
Issue Keys
tools/wafer_keys.py — converts the measured historical population into issued Keys in time order and leaves unissued address space for measured silence between commits.
Keep Growing
tools/wafer_topup.py — appends later public commits beyond the existing rim so earlier issued addresses do not move.
Wafer placement law
Radius = √Key
Function: how Kuiper spreads the measured population across a circular map.

Once an occurrence has a Key, the square root of that Key determines how far from the centre it belongs. The reason is geometric: the area of a circle grows with the square of its radius. Taking the square root makes the radius grow more slowly than the population, so the available circular area grows broadly in step with the number of addresses instead of the outer addresses being pushed absurdly far apart.

That is only the radial part of the placement. Kuiper then uses its angular law to decide which direction around the circle the Key belongs, allowing a deterministic coordinate to be generated from the address rather than storing a separate coordinate for every point.

The law stays small while the population grows. That is one of the central ideas of Kuiper.
From picture to engine

The larger opportunity appeared after the visualisation worked.

What began as a way to make the accumulated coding estate visible exposed a larger possibility: the same deterministic addressing system can organise very large volumes of distributed code, high-frequency grid data, engineering drawings and other generated information without storing a separate position for every item.

An address can become part of a procedural programmable engine in which information is generated, resolved, transformed or rendered when required. Billions of issued Kuiper addresses can therefore become computational locations rather than merely passive dots on a visualisation. Algorithms can operate across those addresses, compare and combine their contents, search for repeated structures, pattern-match across historical states and distil useful information from the accumulated development record.

The wider opportunity is to turn that history into an active computational environment in which previous iterations can inform future ones. In that sense Kuiper is not merely a visualisation of the code estate: it is becoming an iteration engine for coding, grid intelligence, engineering information and potentially much more, with the foundations for a machine that can progressively learn from its own accumulated coding, engineering and grid history.

Iteration

Kuiper records change instead of hiding it.

A conventional deduplicated count asks how much unique material exists now. Kuiper can ask a different question: what sequence of computational work actually happened? Repeated lines, changing files and successive commits are meaningful because they describe development over time. The historical occurrence is therefore part of the data.

Like the numerical methods used to calculate a square root, the system is iterative: a state is produced, measured, refined and followed by another state. Kuiper makes that accumulated iteration addressable.

Technical references

Follow the implementation.