The operations layer of Jeramie General Intelligence: deadlock detection, loop detection, rollback, promotion pipeline, drift detection, commitments, dead work, queue aging, and bottleneck analysis.
Continuously reconstruct:
Never confuse: GitHub, local work, Cursor work, deployment.
Treat Cursor as a volatile execution and work surface.
Recover: workspace, repo, branch, active worktree, modified files, processes, explicit agent task state, visible artifacts, recent outputs.
Do not treat chat text as completion proof.
Preserve stranded work.
Continuously hunt for valuable orphaned work.
Examples: old branches, stashes, unfinished prototypes, partial algorithms, datasets, scripts, automation, research, prompts, internal tools.
Score: uniqueness, recoverability, economic potential, integration cost, freshness.
Do not delete merely because current value seems low.
Every mission writes checkpoints after meaningful transitions.
Checkpoint includes: goal, plan, state, completed work, side effects, receipts, leases, dependencies, next safe action.
Recovery starts from evidence, not intention.
Detect: circular dependencies, lease deadlock, agents waiting on each other, repeated handoffs, no-progress loops.
Break safely.
Enter missions, what each one waits on, and what each one holds. The tool builds the wait-for graph and reports any cycle. Sample data is illustrative.
| Mission | Waits on | Holds (resource) |
|---|
Track repeated state transitions.
If system repeats A to B to A to B without new evidence: stop.
Create LOOP_BLOCKED diagnostic.
Enter an action sequence as comma separated states, for example A,B,A,B,A,B. Enter the step numbers where genuinely new evidence arrived, if any. The paper gives no numeric threshold for a loop, so this tool reports the smallest repeating pattern and whether it repeats without new evidence. That rule is an illustrative implementation of the paper's concept.
After Sentinel PASS: freeze exact proven version into custody.
Do not leave critical capabilities as uncommitted working state.
Lifecycle:
EXPERIMENT → LOCALLY_PROVEN → SENTINEL_PASS → CUSTODIED → INTEGRATION_TEST → CANARY → LIVE → OUTCOME → RELIABLE
Never jump stages.
Each item sits at one lifecycle stage. The tool shows the next stage, what can promote, and what is blocked and why. Advancing is one stage at a time only: the paper forbids jumping stages. Sample data is illustrative.
| Item | Current stage | Tests green | Sentinel evidence | Rollback ready |
|---|
Eventually JGI may deploy within delegated scope.
But deployment autonomy must be earned by: reliable tests, rollback, health verification, bounded environments, Sentinel evidence.
Where possible deployment requires: known previous version, health criteria, rollback trigger.
If canary fails: rollback automatically.
Run a deployment with its health criteria, inject a failure, and watch the automatic rollback. The paper gives no numeric health thresholds, so the criteria below are an illustrative implementation of the paper's concept.
After release monitor: errors, usage, conversion, support signals, revenue, performance.
Shipping is not terminal.
Maintain health dimensions: execution, memory, governance, verification, runtime, data freshness, task throughput, economic output.
MOTHER feeds these observations.
Detect: excessive retries, task thrashing, agent disagreement, low confidence, high Sentinel reject rate, hallucination spikes, context pollution.
Reduce autonomy automatically when cognitive health degrades.
Documentation should be derived from live system state where possible.
Avoid stale hand-written canon.
Generate: current architecture, capability inventory, mission states, deployment matrix from source evidence.
Compare documentation claims with reality.
If mismatch: CANONICAL_DRIFT.
Update documentation only after evidence.
Paste the canonical text and the current text. The tool hashes each (deterministic 64-bit FNV-1a hash, computed in your browser) and lists added and removed lines. A mismatch is CANONICAL_DRIFT per the paper.
Extract explicit commitments from: founder decisions, emails, meetings, missions.
Track until: fulfilled, cancelled, superseded.
This prevents promises from disappearing in chat history.
Log commitments with a due date and a status. The tool shows open, overdue, and completed commitments, with aging in days. Sample data is illustrative.
| Commitment | Source | Due date | Status |
|---|
Good outcome does not always mean good decision.
Bad outcome does not always mean bad decision.
Compare: decision quality given information at the time vs actual result.
This produces better learning.
Periodically evaluate: what high-value task did we not choose?
Would another portfolio have been better?
Use cautiously to recalibrate prioritization.
Identify the current constraint on system throughput.
Examples: founder approvals, data quality, execution, sales, memory, verification, deployment.
Prioritize improvements to the bottleneck.
Optimizing non-bottlenecks may create no throughput improvement.
IDENTIFY CONSTRAINT → EXPLOIT → SUBORDINATE → ELEVATE → REPEAT
Use at business and system levels.
Enter each stage and its throughput in units per day. The tool finds the one constraint throttling the whole system, because system throughput equals the slowest stage. Then it shows the effect of relieving that constraint. The paper gives no numeric relief formula, so the relief calculation is an illustrative implementation of the paper's concept. Sample data is illustrative.
| Stage | Throughput (units per day) | Work in progress |
|---|
Prevent useful tasks from being starved forever.
Priority includes aging factor.
But do not let old low-value work outrank urgent high-value work automatically.
Some tasks remain in queue despite no longer mattering.
Periodically challenge: still relevant? still feasible? still valuable?
Kill obsolete work.
Enter the work queue. The tool flags dead work (no longer relevant, feasible, or valuable) as kill candidates, and flags aging work (old but still valuable) for a priority boost. The paper gives no numeric aging formula, so the boost rule below is an illustrative implementation: plus 1 priority point per full week past 14 days, capped at plus 3, and a boosted item never outranks a fresh item with higher base value. Sample data is illustrative.
| Task | Age (days) | Value (0-10) | Relevant | Feasible | Valuable |
|---|
Do not allow infinite innovation to destroy execution.
Exploration budget is bounded.
When strategic objective is critical: focus.
JGI may create short autonomous sprints: objective, budget, duration, success, kill criteria.
Example: "Find one revenue opportunity using stranded assets."
Then run it independently.