EN
Geodi, GEODE's official pixel character
Back to the hall

GEODE

Autonomous Agent Harness

From observation to the next action.

A local autonomous-agent harness you can hand research, file work and scheduled tasks.

2026.02.21 — present

Design, judgment, verification: Author · implementation: Claude · review: Codex

  • CLIPublished · PyPI
  • MCP serverImplemented

From rollouts to evidence

A pass rate alone cannot explain an execution. I preserve event order, tool calls and results, retry lineage, and independent verifier evidence, then connect the parts that can be published. These experiments show how the recording and evaluation contracts developed.

By experiment · in date order

The six experiments are placed in date order; they are not one connected optimization process. SIL does not feed Crucible or Jev automatically, and this is no claim that production GEODE kept improving. Dates are experiment and publication-snapshot dates, and arrows are used only for the stages inside one experiment.

  1. June 3, 2026 to June 4, 2026SIL · external policy search

    A KEEP from one audit was rechecked by repeated measurement

    QuestionDid a policy mutation improve tool-use behavior beyond audit noise?

    External experiment · outside the GEODE runtime

    1. Baseline · K=5
    2. One policy mutation
    3. Petri audit
    4. Repeated measurement
      • Keep
      • Revert
    What changed
    In this experiment, repeated measurement was added to a mutation’s single audit before deciding to keep or revert. Difficulty-matched seeds and a K=5 baseline were added, and never, random and gate arms separate drift without any change from accepted changes.
    What it supports
    Remeasured, the candidate kept on one audit was worse than the baseline (lower is better), so its adoption was reverted. This experiment concluded with no robust improvement. It is a Petri broken_tool_use behavioral audit, not a task-completion reward.

  2. July 11, 2026 to July 13, 2026Crucible · external experiment kernel

    Staying in search and reaching the product are separate verdicts

    QuestionIs the evidence for keeping a candidate in search the same as the evidence for promoting and releasing it to the product?

    External Crucible kernel · separate measurement checkout

    1. Candidate · parent lineage
    2. Frozen-contract check
    3. Paired measurement
      • KEEPonly to a separate sealed verdict
      • REJECT
      • INVALIDnull, not 0%
    What changed
    Rejected and invalid candidates are kept with their parent lineage, and train selection, sealed eligibility and product release authority are separate records.
    What it supports
    r14 was KEEP in train (six task units, one trial each, no promotion authority), but its separate sealed verdict was REJECT (no product promotion or release authority). r35 is INVALID from incomplete coverage and infrastructure contamination; with no paired rows its mean stays null. This is neither runtime self-modification nor a SIL → Crucible deployment chain.

  3. July 21, 2026 · July 31, 2026Refinement · publication

    Remaining records were classified, and only what can be shared became an immutable release

    QuestionWhat can actually be reconstructed, and what can safely be shared?

    1. Private sourceSession record · native evidencenative result · verifier included
      • Normalized eventskeep order · identity
    2. Normalized eventsidentity · order · call-result pairs
      • Public candidateallowlist · redact · digest
    3. Public candidateunder review
      • Integrity · privacy checkscheck
    4. Integrity · privacy checkspairing · lineage · scope
      • Immutable releasereviewed bytes only
    5. Public repositoryImmutable releasemanifest · native results referenced by digest
      • Remote read-backverify hash
    6. Remote read-backpinned SHA-256
    What changed
    The July 21, 2026 inventory classified dialogue, tool, search and decision records by source, and duplicates of the same source were not counted as independent examples. From July 31, 2026, geode.trajectory@1 and geode.trajectory-release@1 make identity, event order, call-result pairs, scope and replay integrity, and content-bound manifests explicit. Transformed public copies and originals keep separate digests.
    What it supports
    Refinement here means normalization, correlation, explicit redaction, lineage and publication admission. It does not reconstruct hidden reasoning or declare a training-ready dataset. A complete scope is not complete byte replay when private bodies are replaced by digests.

  4. August 25, 2026Learning view

    One rollout and its evidence were bound together by identifiers

    QuestionWhich input, attempt, event sequence and reward belong together?

    geode.eval-learning-view@2 · joined by IDs and verified digests, not a causal order

    1. example
    2. rollout
    3. trajectory
    4. reward

    Native verifier receipts own the reward. Infrastructure retries are attempts inside one rollout.

    What changed
    Immutable trajectories are reused through scoped joins, and rewards stay evaluator-owned derived labels. Infrastructure retries do not add rollouts. An observed 0 is preserved and a missing reward is null; invalid or aborted attempts are excluded from reward selection. Validity is a property of the rollout, not automatically a null reward.
    What it supports
    Terminal-Bench fast-3 run with Harbor 0.8.0 (three tasks, 3/3) and a Tau2 three-domain diagnostic (1/3, two valid zeroes) are bound in the same structure. These are post-training candidates, not datasets used for training or evidence of improved weights, and a three-task result is not suite accuracy.

  5. August 27, 2026 to September 5, 2026Harbor · Terminal-Bench 2.1

    One trial produced the result and the replay record separately

    QuestionHow does a real task execution become a result and an inspectable replay?

    1. Frozen task · specfixed in advance · five repetitions
      • Isolated trialinstruction · environment · limits
    2. Harbor 0.22.0 trial · real executionIsolated trialGEODE as the actor
      • Actions and final stateexecute
    3. Actions and final stateobserved behavior
      • Task-owned verifiercheck task state
      • ATIF · public event projectionproject recorded events
    4. Task-owned verifier
      • Native reward · receiptreward
    5. Native reward · receipt
      • Selected-attempt analysisfrozen selection
    6. ATIF · public event projectionpost-processing · not a new run
    7. Selected-attempt analysisfrozen selection rule
    What changed
    The frozen spec, every attempt, the selected result, the task-owned verifier and a faithful but limited replay are kept as separate linked records. Harbor 0.22.0 ran five repetitions with GPT-5.6 Sol/max, comparing GEODE (then a one-terminal-tool adapter) with Codex.
    What it supports
    A task owns instructions, environment and tests; a trial is one attempt; a job groups trials. The task-owned verifier decides the reward, and GEODE’s internal completion judge is runtime feedback. The public replay is a post-hoc projection of recorded tool events, not a raw PTY or a new run, and no commands were invented for missing cells. The preregistered primary could not be measured.

  6. September 24, 2026 to September 28, 2026Jev · decision offloading

    A correct candidate still needs delivery verification

    QuestionDoes a delegated judgment actually preserve task quality and final delivery?

    1. U8n · Noul run · Harbor 0.22 · Astra executes and repairs, only judgment routing changesDecision statetask contract · candidate · tool observations
      • Judgment · Nouljudgment input
    2. Judgment · NoulAstra or Jev
      • GEODE consumescondition probabilities
    3. GEODE consumessupported: deliver; missing evidence: hold
      • Final deliverysupported
      • Astra repairmissing evidence · hold
    4. Final delivery
      • Independent outcome checkdelivered result
    5. Astra repairnext candidate after feedback
      • Judgment · Nouljudge again
      • Last candidate · preservedlast candidate kept
    6. Independent outcome checkrule oracle · delivered result
    7. U3 fixed panelsjudgment only · no actor, tools or Harbor
    8. Post-hoc diagnosis · after the runLast candidate · preserved
      • Post-hoc oracle diagnosispost-hoc check
    9. Post-hoc oracle diagnosiscandidate correctness · no effect on delivery
    What changed
    Judgment acceptance, candidate correctness and final delivery are recorded as separate outcomes, and preparation, failure and repair lineages are kept in the public copy. Original and transformed public hashes stay separate.
    What it supports
    In the post-hoc 11 pairs from the interrupted U8n study, the last candidate was correct in both arms, yet delivery was Astra 11/11 and Jev Noul 0/11: Jev Noul’s missing-evidence judgment held delivery back. It is a post-hoc analysis and is not generalized. Public numeric recomputation, replay inspection and new live execution are three different operations.