Gauge Orbit Framework¶
Concept¶
The fleet's project management framework borrows from Yang-Mills gauge theory in differential geometry. This isn't decoration — it's a structural analogy that solves a real coordination problem.
When you have dozens of active projects, multiple AI instances with different models and capabilities, and several physical environments, the fundamental challenge is synchronization. How do you know when the system's understanding of a project has drifted from reality?
The Analogy¶
| Physics Concept | Fleet Equivalent |
|---|---|
| Fiber bundle | The collection of all active projects |
| Fiber | An individual project with its state, plans, and artifacts |
| Base space | The shared operational environment (infrastructure, tools, vault) |
| Gauge transformation | An AI instance acting on a project — reading state, making changes, producing output |
| Connection form | The shared knowledge layer (Obsidian vault) that defines how instances relate to projects |
| Curvature | Detected disagreement between an instance's understanding and actual project state |
Why It Works¶
The Synchronization Problem¶
Consider: Instance A updates a project plan. Instance B, working from cached context, makes decisions based on the old plan. Instance C is spawned fresh and reads the updated plan but doesn't know about B's in-progress work.
This is the fleet equivalent of parallel transport in differential geometry — moving information along different paths through the project space and checking whether you arrive at the same state.
Curvature Detection¶
When two instances' views of a project disagree, that's curvature — a measurable signal that synchronization has broken down. The framework includes automated checks:
- State comparison — do the MASTER-PLAN and actual artifacts agree?
- Cross-instance validation — does the instance working on a project have the latest context?
- Drift monitoring — periodic spot-checks comparing documented state against reality
When curvature is detected, it triggers reconciliation before more work proceeds on stale assumptions.
Orbit¶
Each project traces an orbit through the framework — a trajectory defined by its plan, the instances that work on it, and the decisions made along the way. The orbit is documented in a MASTER-PLAN that serves as the single source of truth.
An orbit document captures: - Current phase and status - Decision log with rationale - Dependencies on other projects - Which instances are authorized to act on it - Completion criteria
Practical Implementation¶
The framework is implemented as:
- ORBIT.md — a top-level document mapping all active projects, their status, and relationships
- MASTER-PLAN.md — per-project planning document (the "fiber")
- Dispatch protocol — async task routing that maintains context (the "connection")
- Heartbeat monitors — periodic checks for state drift (curvature detection)
- Reconciliation procedures — defined steps for resolving disagreements
Why Not Just Use Jira?¶
Standard project management tools assume human operators with continuous memory and shared context. AI instances don't have that. They wake up fresh each session, reconstruct context from files, and make decisions based on what they can read.
The Gauge Orbit framework is designed for this reality: - State is always in files, not in anyone's memory - Disagreement is detectable, not hidden until something breaks - Context reconstruction is defined, not ad hoc - The framework scales with the number of projects and instances without requiring proportionally more human oversight
The physics analogy isn't necessary to use the framework, but it provides a rigorous vocabulary for discussing coordination problems that otherwise devolve into "make sure everyone's on the same page."