Scientific software · Active development · Rust systems
The Generalized Execution Platform is a Rust system for turning authored scientific definitions into executable applications. Compose exact dependencies, prepare the work once, bring in data through an explicitly authorized route, and retain results with their input context intact. Reopen and reuse those results without replaying their original producer. Flexible research and dependable delivery belong in the same product.
01 / The idea
A game engine lets an author compose a world while shared machinery handles its execution. GEP applies that separation to scientific software: reusable definitions and applications above, execution and data infrastructure below. The analogy describes the product direction—not a claim that every discipline or deployment target is already supported.
meshes · textures · shaders · physics settings
mathematics · laws · models · methods · schemas · experiments
scenes assembled at runtime by the engine
exact definition dependencies, compiled and retained in a prepared Project
rendering · physics · memory · platform targets
execution · data movement · allocation · custody · lineage
drivers · draw calls · allocators
schedulers · kernels · backends · queues · clusters
Scientific meaning belongs to separately versioned libraries and applications. The platform executes that meaning; it does not invent it.
02 / The steel boundary
The defining cut of GEP is a boundary we treat like steel. Authored meaning lives above it; execution, data plumbing, and physical hardware live below it. Neither side leaks into the other — so either side can evolve without rewriting the other.
Above the line — yours
Below the line — the engine’s
Keep scientific identity separate from the machine that executes it. Local CPU execution is implemented; broader realization remains future work.
Science on GEP stacks like floors in a building. Each layer is an inert, versioned asset that composes on the exact closure beneath it. Build a tower yourself — click the assets below.
Select an asset to begin stacking.
03 / Architecture
GEP is four peer pillars joined by typed crossings. Each owns a narrow slice absolutely — and is forbidden from reaching into its neighbors’ concerns.
P·1
Authored meaning made exact: versioned definitions, precise dependencies, deterministic lowering, and a separate semantic trace.
P·2
A meaning-blind executor. It runs lowered programs as retained Jobs and returns exact technical outputs — understanding nothing of what they mean.
P·3
Bounded data exchange, Arrow and Parquet persistence, typed record datasets, and independent readback and reuse. Query support is qualified by the specific route.
P·4
The sole meaning-blind physical governor. It joins lawful work to current machinery through fit, grants, waits, and release.
04 / The route
01
Compose typed definitions with exact dependencies, conditional branches, bounded iteration, or supported stateful behavior. Scientific meaning stays in authored content.
02
Capture source and dependencies, check the lock, and form the selected applications and mechanical programs once.
03
Supply typed inputs, explicitly authorize bounded HTTPS acquisition, or reopen retained data. Bind the original inputs and invocation context to the work that uses them.
04
The Runtime and Player execute the prepared work; Allocation owns resource fit, grants, and release.
05
Typed records become durable data with explicit snapshot identity and attribution to the executed application.
06
Inspect exact Project and result facts through read-only tools and native prototypes. Use the command-line record route to reopen, inspect, and reuse supported datasets without rerunning their producer.
These are bounded implemented routes, not a general-purpose deployment service. The next product horizon is preparing a finished application for independent deployment, while retaining the research and its provenance. Standalone export remains future work.
05 / What gets built on top
These are intended application areas, not delivered industry packages. Scientific libraries should be independently meaningful, versioned, and reusable. Each new discipline must earn its support through actual definitions, data, and executable work.
First proving ground: a demanding end-to-end research vertical. Generality is earned through real executable work — not speculative abstraction.
06 / What’s real today
Scientific programs can now compose larger dependency trees, carry input context into saved results, and use explicitly authorized external acquisition. Supported records can be published, inspected, reopened, and reused through the command line. Focused macOS and isolated Linux checks cover these newer paths; a controlled public HTTPS test also passed. These are bounded implementations, not a finished scientific desktop or a production-readiness claim.
Recent implemented capabilities
Explicitly not yet
Further product horizons—not the active task order
Governance can prove what ran, under what authority, from which exact inputs. It cannot make weak science true.
07 / Operating principles
01
No math, laws, models, or methods ship inside. The platform holds no scientific opinion.
02
Inert, versioned assets composed with exact dependencies belong entirely to their author.
03
Kernels, schedulers, backends, and capacity are platform concerns — never labels in science.
04
Waiting, current resource nonfit, failure, and completion must remain distinguishable—not hidden behind a success label.
05
The intended path includes preparing an application for independent deployment. Standalone packaging is still to be built.
06
The engine proves provenance and authority. It cannot declare a conclusion scientifically true.