GloriousFlywheel

Compute once, withdraw everywhere. GloriousFlywheel runs its own scheduler: every admitted Bazel action and Nix derivation hits the cache or runs on pooled workers, never on the runner.

Every request is admitted against caller identity, the checked-in ActionPlan, capability and tenant quota before it touches the fabric. Missing authority, denial or absent capacity fails closed with a typed error; nothing falls back to local execution. Your organization installs its own GitHub App and keeps custody of its policy and credentials: owned by you.

O(1) software development lifecycle

Every authorized caller withdraws the deposited result rather than recomputing it. The REAPI cell checks the action cache first: a qualified hit never touches a worker; a miss runs remotely and deposits.

GitHub schedules the job; GF schedules the actions inside it, so one developer's remote run warms CI and every other authorized developer. Reuse keys on action or derivation identity, toolchain, system, tenant and policy; similar source or a shared cache URL never counts. A result lives for its retention epoch; eviction starts a new one.
One scheduler for the entire execution fabric

Development and CI submit to one scheduler; neither executes product work. The scheduler admits by capability and tenant quota, queues saturated work, and leases attested worker slots; it never runs an action itself.

Nix keeps its derivation graph; the same physical fabric schedules each derivation, and its closure publishes recursively to a separate Nix cache. Trusted work deposits before its lane reports success. Developers authenticate through the adopter's Product App and CI through Actions OIDC: shared policy and cache, separate credentials.
Build way bigger.

Submit a large, parallel build graph from a small machine. Parallelism comes from pooled worker slots, not your runner count: one thin caller fans ready actions out within tenant quotas.

Work names capabilities, not machines: architecture, runtime, privilege, accelerator and bounded resources select the worker, never the repository. A dozen thin runners carrying a hundred-plus concurrent actions is the design bar. Capacity is read from the running system; a declared cap bounds admission and is never a measurement.
Immutable gitops that doesn't suck.

Main equals production: one signed release, reviewed, merged and verified where it is served. Authorized CI publishes a signed release of the exact PR head; after browser review and merge, the owner controller verifies the served content.

The preview binds the exact head, release, lifetime and access policy; only an observed merge, close or expiry reaps it. Browser review grants no deployment authority; production binds protected main through controller reconciliation. There is no manual post-main apply.

Stage 1 of 5

Architecture

withdraw

lookup -> verified-hit -> complete

Withdrawal: verified reuse of a previously deposited result. A warm result MUST be reusable by another authorized caller with the same tenant, digest, platform, and policy identity.

Architecture referenceWhitepaper, page 11
submit

lookup -> explicit-miss -> admitted -> remote-running -> validated

A remote-required cache miss MUST either be admitted to a compatible worker pool or receive a typed admission/availability failure. Remote-required work has no edge from explicit-miss to local execution.

Architecture referenceWhitepaper, page 11
deposit

Successful trusted work MUST publish its reusable closure or action result before the lane reports success.

Architecture referenceWhitepaper, page 11

deposit

nix-closure
bazel-cas
bazel-action-cache
Developer lane gf-v4-dispatch / dispatch onlyfail-closed / dispatches to executor
DispatchEdge lane gf-v4-dispatch / dispatch onlyfail-closed / dispatches to executor
ReapiOperation lane rbe-linux-x86_64 / remote requiredfail-closed / dispatches to executor
ReapiOperation lane rbe-darwin-aarch64 / remote requiredfail-closed / dispatches to executor
NixBuildOperation lane nix-build-linux-x86_64 / remote requiredfail-closed / dispatches to executor

1. nix-closure
2. bazel-cas
3. bazel-action-cache
4. Developer lane gf-v4-dispatch / dispatch onlyfail-closed / dispatches to executor
5. DispatchEdge lane gf-v4-dispatch / dispatch onlyfail-closed / dispatches to executor
6. ReapiOperation lane rbe-linux-x86_64 / remote requiredfail-closed / dispatches to executor
7. ReapiOperation lane rbe-darwin-aarch64 / remote requiredfail-closed / dispatches to executor
8. NixBuildOperation lane nix-build-linux-x86_64 / remote requiredfail-closed / dispatches to executor

release handoff

bind published descriptor

A published application release binds its source identity, one target and its lock, its qualification and output manifest, an authenticated root, a runtime image and its receipts into the handoff operands.

Architecture referenceWhitepaper, page 10
bind application + policy

A published reusable OverlayBundle binds separate source identity, target/graph/lock/evidence/output manifest, a bounded authenticated tar root, an exact regular 0755 activation-adapter member, and policy.

Architecture referenceWhitepaper, page 10
trusted identity / policy

Release authority, verified source commit/tree, payload/descriptor cryptography, and independently checked referenced-content observations are verifier-owned inputs, separate from artifact payloads.

Architecture referenceWhitepaper, page 10
independent byte verification

Payload and descriptor bytes are verified independently against the trusted producer identity.

Architecture referenceWhitepaper, page 10
exact immutable operands

The typed decision accepts only authority-matched application and reusable overlay releases whose complete references are bound by a separately signed selection.

Architecture referenceWhitepaper, page 10
Accept(handoff) only

Missing selection, signature, the selected arm's independent authority verification, or independently supplied subject refuses; two independently signed release artifacts alone do not authorize their pairing. Only an accepted handoff reaches the consumer; deployment plan, apply and provider state stay outside the product.

Architecture referenceWhitepaper, page 10

Accept(handoff) only

CandidateEvidence/v1 cannot satisfy a published handoff
ApplicationRelease/v1 target + authenticated outputs + build evidence
OverlayBundle/v1 target + authenticated root + policy
Published handoff operands
ReleaseAuthority trusted producers + policy
ReleaseVerification payload + descriptor + references
OwnerOverlayDecision Accept | typed Refuse
Owner-overlay consumer plan / apply / state

1. CandidateEvidence/v1 cannot satisfy a published handoff
2. ApplicationRelease/v1 target + authenticated outputs + build evidence
3. OverlayBundle/v1 target + authenticated root + policy
4. Published handoff operands
5. ReleaseAuthority trusted producers + policy
6. ReleaseVerification payload + descriptor + references
7. OwnerOverlayDecision Accept | typed Refuse
8. Owner-overlay consumer plan / apply / state

Adopting GloriousFlywheel

Launch preview

Explore an installation and repository attachment design preview with simulated plans and recovery scenarios.

1. Create and install the adopting organization's own all-repositories GF GitHub App.
2. Publish signed OwnerInstallation/v1, TenantOverlay/v1, and RevocationSet/v1 operands from that organization's -infra repository. OwnerInstallation/v1TenantOverlay/v1RevocationSet/v1-infra
3. Check an exact ActionPlan into each application repository and call the immutable ci-templates v4 workflow.
4. Let the controller join demand to provider supply and publish the immutable catalog used by gf-action-client. gf-action-client
5. Prove one remote Execute or authenticated same-tenant cache hit with measurement-plane attribution.

Multi-Org Enrollment Model

Forge scope GitHub repo/org/enterprise, GitLab project/group/instance, Forgejo repo/org/account
Operator tenant team, org, enterprise, managed customer
Runner capability class admission shell, not the execution pool docker, nix, nix-heavy, gpu, kvm
Cache/state plane Attic tenant/cache view, Bazel cache namespace, state backend authority

Architecture Axioms

Attach once. Local development, CI through the adopter thin dispatch edge, and REAPI workers resolve the same logical tenant, cache, and toolchain contract. Neither caller executes product work locally or deposits results; it dispatches to the shared fabric
Trusted work deposits automatically. Successful trusted work MUST publish its reusable closure or action result before the lane reports success. A manual seed is bootstrap or repair, never steady-state acceptance.
Every attached path withdraws from shared authority. A warm result MUST be reusable by another authorized caller with the same tenant, digest, platform, and policy identity.
No silent fallback or disguised outage. Remote-required work MUST fail closed when remote execution is unavailable. Backend unavailability, corruption, denial, and a genuine cache miss are distinct observable states.
The action is the unit of compute; throughput lives in the pooled scheduler, not runner count. Product throughput is a property of the shared exec-cache pool and GF's own scheduler (cache hit-rate, deposited and withdrawn results, admitted actions, worker slots), never of runner count.

Invariants

pool topology shared data plane
tenant isolation true
content identity verified true
outage distinct from miss true
coreIsAdmissible gfCore true
REAPI Linux platform identity gloriousflywheel-rbe-linux-x86_64
REAPI Darwin platform identity gloriousflywheel-rbe-darwin-aarch64

Born out of what agent orchestration does to legacy development lifecycles: the same builds, tests and derivations re-executed again and again, O(∞) iteration we've somehow grown to accept. A system of systems is O(1). GloriousFlywheel makes it so: a qualified cache hit returns without touching a worker, and a miss waits in the scheduler queue for an attested slot.

Status, 2026-09-29: latest signed release v0.5.2; scheduler and workers are source on main; first adopter installing; nothing measured yet.

Jess Sullivan, founder, xoxd.ai; MLOps lead on Merlin Sound ID

Whitepaper, 2026-09-19.

Whitepaper

Your developer's machine, your CI runner and your release pipeline each execute the same work in an environment of their own, so every change set is executed once per caller. GloriousFlywheel attaches all three to one pool. A result computed once is withdrawn by every later authorized caller instead of being computed again; the action, not the runner, is the unit of compute; and remote-required work fails closed rather than falling back to a laptop. This paper states the thesis in the operator's own words, explains how the fabric keeps it (fourteen laws and eleven versioned interfaces, quoted in the appendix), states what you get and what you must do to attach, and places the design beside five products that each optimise one part of the same system.

Read the whitepaper (PDF)

GloriousFlywheel

O(1) software development lifecycle

One scheduler for the entire execution fabric

Build way bigger.

Immutable gitops that doesn't suck.