6. The GLoops Flywheel
Executive Summary
What this chapter establishes
GLoops learns from the strongest Reference Realization, extracts the reusable shape, and returns it to every org.
This is one of the company’s two or three central ideas. The platform does not invent capability in the abstract — it learns from the strongest realization currently known, extracts the reusable shape, and returns it to every organization.
A Reference Realization is the current highest-fidelity working instance of a capability class. GLoops’ relationship to it is fixed: observe → learn → operationalize → improve. GLoops platformizes the realization’s intelligence into reusable, domain-neutral capabilities; it never becomes or replaces the realization, and it never imports one org’s domain or policy values as platform truth — it platformizes the shape and leaves domain/policy to the per-org adapter.
The flywheel’s promise: improving GLoops improves every onboarded org; improving an org (whose evidence raises the bar) improves GLoops. A capability extracted from a realization that helps only one org is a missed extraction, not a win.
The role of Reference Realization is not fixed — it is held by whichever realization is strongest, and reassigned on a measured bar (stronger real-receipt evidence on the class and at least parity breadth, over a window), never by assertion. When several realizations exist for a class, the platform learns their intersection (the reusable shape) and adapts to their divergence (the per-org adapter).
Decision rule — a bottleneck found inside a Reference Realization. When the Steward finds an operational bottleneck inside a Reference Realization (e.g. Induct), it does not default to filing work to improve that org. It asks: “Should the org solve this itself, or should GLoops operationalize this capability for every onboarded org?” — and defaults toward GLoops: build the reusable capability in GLoops → the Reference Realization consumes it → every other org inherits it. Route work directly into the org only for genuine org-specific policy/config.
Five lenses — The Flywheel & Reference Realizations
| Lens | |
|---|---|
| ▣ Current Reality | Induct — a regulated pilot customer — is the current Reference Realization for autonomous software delivery. It already runs a mature, governed agentic SDLC (runnable-task contracts, an autonomous merge contract, a track record of governed, receipted delivery, governed gates, risk tiers) that is more operationally advanced than GLoops on delivery. Notably, Induct is ~100% human-merged — its merge taxonomy and shadow evaluator exist but were never wired to act, and it has no cross-org readiness roll-up. That gap is a domain-neutral capability shape — GLoops’ highest-leverage extraction. |
| ◇ Target State | GLoops continuously extracts Induct’s delivery intelligence into reusable capabilities behind the Capability API; Induct consumes them; future orgs inherit them without reinvention. |
| → Migration Path | Receipt & Evidence ingestion (observe first) → observational Capability Health → Issue Discovery/Understanding → Clarification → Planning/RT generation → … → Merge Readiness — ascending authority, learn-before-act. |
| ⚖ Executive Implication | You don’t bet the platform on one customer. Every capability is built to serve all onboarded orgs; single-org work is the exception, justified explicitly. |
| ☼ Operator Experience | When you onboard a second organization, it consumes existing capabilities rather than triggering a rebuild — the platform feels like it already knows the job. |
Chapter closeout
Decision ledger
Key Decisions
- A Reference Realization teaches the platform; GLoops does not become or replace it.
Open Questions
- Which Induct patterns generalize cleanly across a second organization?
Related Chapters
- Ch. 7 - Knowledge
- Ch. 14 - Phase 5
- Concept Map - Reference Realization