Open Space Inversion

Proof the inverter works

Round-trip validation first

Before trusting the inverter on synthetic coordinates, it must reconstruct real ones. Two real documented functions, embedded and inverted back:

One comes back verbatim (cosine 1.0); the other reconstructs the meaning with token artifacts (the '/pl>' fragments), at 0.916. That is the fidelity ceiling to keep in mind when reading the hole decodes below. Baseline for the emptiness numbers: a typical real function sits at cosine 0.746 from its own nearest neighbor.

The open space

Three holes, traced and surrounded

The 2D projection of all 515 function embeddings. Each traced circle is empty (no function inside) and enclosed: points appear in all eight compass directions within 2.5 radii, and each hole's radius is at least 3x the median point spacing, so these are cavities inside the cloud, not indentations on its edge. The colored dots are each hole's walls: the twelve nearest real functions, whose full-dimensional mean is the coordinate we invert.

The inversions

What the empty space says

Hole 0 · Guided secure-environment provisioning

radius 0.7 in projection units · surrounded on all 8 sides · walls from CRWV, RUM

Outside the white space: The wall points split into three distinct capability groups. On one side, credential minting: Rumble's 'Generate app credentials', 'Create S3 credentials', 'Add an SSH key pair'. On another, network boundary control: Rumble's security groups and CoreWeave's IPAddressManagementPolicy, PortRange and HostPrefix objects. On a third, storage operations: 'Clone a volume', 'Create a volume snapshot'. Three families of security-adjacent primitives, each real, each shipped by someone.

Inside the white space: the point we invert is the full-dimensional mean of those twelve wall functions: the single coordinate equally influenced by every wall, with no real function inside its radius. Handing that coordinate to the inverter returns, verbatim:

20-step: Step-by-step instructions: Create Step-by-step instructions: How to configure a HostPhone security group for volume.
50-step: Step-by-step instructions: Create Step-by-step instructions: How to create Step-by-step for SSH volume group port credentials.

Why this point is between the walls: The inverted point ties at MODERATE similarity to all three families at once (0.69-0.75 to credentials, security groups, AND volumes) while reaching identity-level similarity with none - the round-trip test showed 0.92+ is what 'the same function' looks like. Equal moderate pull from every wall, full membership in none: that is what 'between' means in this space.

Re-embedded, the raw decodes sit at max cosine 0.786 / 0.749 to any of the 515 real functions: comparable to a typical function's distance from its nearest neighbor.

Interpreted as a product: The hole between the security PRIMITIVES is the composed PROCEDURE. Every company ships the individual nouns; nobody ships the guided flow that provisions credentials, security groups, ports and volumes as one operation. The machine, asked what lives between these walls, literally answered: 'Step-by-step instructions.'

Hole 1 · Template-driven network lifecycle

radius 0.55 in projection units · surrounded on all 8 sides · walls from 9449.T, RUM

Outside the white space: The wall points again split cleanly. One group is introspection: Rumble's 'Show stack details', 'Show template details', 'Show instance details', plus GMO's Template Management. The second is network attachment: Rumble's 'Associate/Disassociate a floating IP with an instance'. The third is GMO's IP Address Management and account functions. Templates exist; IP operations exist; they are separate products from separate companies.

Inside the white space: the point we invert is the full-dimensional mean of those twelve wall functions: the single coordinate equally influenced by every wall, with no real function inside its radius. Handing that coordinate to the inverter returns, verbatim:

20-step: Retrieve details of a given instance  Template: Retrieve details of a specified instance  Stack and IP.
50-step: Retrieve specific details of a stack: Retrieve specific details of a stack: Removal of IP template for instance.

Why this point is between the walls: The inverted point's STRONGEST tie to any real function anywhere is just 0.64 ('Show stack details'), with the floating-IP and template walls at 0.50-0.62. Nothing comes close to identity range. The decode text splices the two families' vocabulary ('IP template for instance') into an object neither family has - the purest between-point of the three, and the only one that re-embeds farther from every real function than a typical function sits from its own nearest neighbor.

Re-embedded, the raw decodes sit at max cosine 0.623 / 0.644 to any of the 515 real functions: further from every real function than a typical real function is from its own nearest neighbor - novel text.

Interpreted as a product: Network state AS a template: declare an instance's network attachment once as a reusable object, retrieve it, remove it as a unit. Templates exist for clusters and servers; floating IPs are managed one call at a time; the space between them keeps trying to say 'IP template'.

Hole 2 · Portable capacity claims

radius 0.52 in projection units · surrounded on all 8 sides · walls from CRWV, E2E.NS, NSCALE

Outside the white space: The wall points: CoreWeave's entire CapacityClaim CRUD suite (Create/Get/List/Delete) on one side, Nscale's coarse 'Compute' and 'Networking' surfaces on another, and E2E's 'Sign up' onboarding on a third. One vendor's proprietary reservation object, ringed by other vendors' generic surfaces.

Inside the white space: the point we invert is the full-dimensional mean of those twelve wall functions: the single coordinate equally influenced by every wall, with no real function inside its radius. Handing that coordinate to the inverter returns, verbatim:

20-step: Manage CapacityClaim services: Access, manage, and distribute resources generated by a service for its cloud-based GPU compute unit. 
50-step: Services: CapacityClaim: Manage, store, and access GPU workloads on the Distributed Cloud Services of the corresponding compute environment.

Why this point is between the walls: Weakest betweenness of the three, reported as such: the decode ties 0.83 to CoreWeave's own CreateCapacityClaim - one dominant wall rather than balanced pull. The 'between' here is thin; the decode is CoreWeave's concept re-voiced in provider-neutral words ('the Distributed Cloud Services of the corresponding compute environment').

Re-embedded, the raw decodes sit at max cosine 0.802 / 0.831 to any of the 515 real functions: comparable to a typical function's distance from its nearest neighbor.

Interpreted as a product: A capacity claim not bound to one vendor: reserve GPU capacity as an abstract, portable object across providers. Honest caveat: this is less a void than CoreWeave's idea waiting to be unbundled.

The holes as businesses

Three business plans from the empty space

Plan 0 · The environment API

The problem. Standing up one secure GPU training environment today takes roughly eight uncoordinated API calls: create a security group, add rules for exactly the right ports, mint an SSH key, mint S3 credentials scoped to the right bucket, restore the volume, attach everything to the instance, and keep every reference consistent by hand. The sequencing knowledge lives in tutorials and in engineers' heads, not in any API. When step six fails, the customer personally cleans up the orphans from steps one through five. Every ML team at every neocloud rebuilds this same glue.

The product. Environment-as-an-object: one call that takes intent ("private training environment, S3 access, SSH from these IPs only") and provisions credentials, security group, rules, ports, and storage together - mutually consistent, atomic, rolled back as a whole on failure, returned as a single bundle the customer can inspect, audit, and tear down as a unit. It works across neoclouds, so a team running on two providers declares the environment once.

Why the market leaves it open. Neoclouds compete on GPUs and inherit single-object CRUD from their infrastructure lineage; composition is "the customer's problem." Generic tools (Terraform) exist but know nothing about GPU-cloud specifics, offer no atomicity, and treat teardown as your risk. And precisely because the neocloud market is fragmented across 14+ providers, no single vendor has the incentive to build the cross-vendor layer - the fragmentation that creates the problem also prevents any incumbent from solving it.

First customer. ML platform teams at AI startups running on one to three neoclouds, who currently maintain this glue as internal scripts.

Plan 1 · Network identity templates

The problem. GPU instances churn constantly: spot preemption, resizing, cluster rebuilds. Each time an instance dies, its network identity - floating IPs, firewall bindings, routes - must be reconstructed call by call ("associate a floating IP", "disassociate a floating IP", one at a time). Templates exist for servers and stacks, but no provider offers a template for network attachment. Teams keep that identity alive with brittle scripts, and a mis-reconstructed environment is a security incident.

The product. The IP template - the object the inversion invented. Declare an instance's complete network attachment once as a versioned, reusable template; apply it to any instance in one call; retrieve and remove it as a unit. The instance becomes disposable while its network identity persists - the piece that makes ephemeral GPU capacity behave like stable infrastructure.

Why the market leaves it open. The network functions ship as-is from the OpenStack lineage most neocloud stacks inherit; template systems were built by different teams for a different noun (servers). Products that require marrying two internal families fall between org charts. The geometry showed this literally: the two function families sit in separate clusters with a measured, fully enclosed cavity between them, and the decode of that cavity splices their vocabularies into an object neither team ever built.

First customer. Anyone running spot or preemptible GPU fleets - the same buyers the preemption-insurance void points at.

Plan 2 · The capacity clearinghouse

The problem. Reserving GPU capacity is vendor-locked. The only claims API in the industry is CoreWeave's proprietary CapacityClaims; everywhere else, reservation means emails, PDFs, and take-or-pay contracts. A buyer hedging across providers cannot hold, compare, transfer, or resell reservations as instruments - the industry prices like a hotel with no booking layer.

The product. The capacity claim freed from its vendor: a standardized reservation object (GPU type, count, window, SLA) issued against multiple providers through one API - acquire, exercise, transfer, resell. This is the same missing economic layer the catalog method found independently (spot market, capacity resale, futures all measured empty market-wide); the inversion re-derived it by generalizing CoreWeave's object to "the corresponding compute environment."

Why the market leaves it open. The one incumbent with the primitive benefits from its lock-in; the small providers who would gain from a neutral layer lack the volume to establish one alone; and a clearinghouse needs multi-vendor cooperation no single vendor has an incentive to lead. Classic missing-marketplace economics: everyone benefits, nobody moves first - which is why it is a business for a neutral third party, not a feature for a cloud.

First customer. AI labs and funds that already hedge capacity across two or more neoclouds and carry the reservation risk on their own books.

These plans are interpretations built on the decoded holes and the indexed function data; the geometry locates the gap and proves nobody documents it, the business case around each gap is analyst work, labeled as such.

Variant

Description-only embeddings

The holes above were found in embeddings of name: purpose. Function names carry vendor branding ('CapacityClaimService_...'), and hole 2 showed the cost: the inversion parroted the brand. This variant re-runs the whole pipeline on embeddings of the purpose sentence alone. The decodes come back cleaner (round-trip recovered 'Create a droplet.' exactly; no vendor tokens anywhere), and the space changes character: without names, descriptions read as generic behavior, the cloud is smoother, and two of its three holes decode to near-existing paraphrases (max cosine 0.82-0.84 to real functions). One is genuinely new: between walls of VPC creation, availability zones, host prefixes and support, the empty space decodes to 'Reclaims an Availability Capacity assigned to a local Vserver' (0.77): capacity reclamation, an operation no one documents, and a cousin of the preemption-insurance void the catalog method found independently. The trade is real: names add branding noise but sharpen the voids; descriptions clean the language but smooth the space.

Read together

The pattern

All three decodes point the same direction the proposal-based methods found independently: the industry's holes are the coordination layer above its own primitives. Hole 0 decodes to the procedure between security primitives. Hole 1 decodes to templates for network state. Hole 2 decodes to capacity claims freed from their vendor. The nouns exist; the space between them keeps trying to say verbs.

Raw inversions are vec2text output, verbatim, including artifacts; interpretations are ours and labeled as such. The inverter runs on the GTR encoder (the embedding family with public pretrained inverters), a different model from the two used elsewhere on this site; hole locations therefore differ from the qwen3/bge maps. Educational; not investment advice.