Skip to main content

Genesis Program Working Agreement

Mission And Products

Build four dependency-ordered, independently governed outcomes:

  1. GenesisCode: the agent-native language, runtime, toolchain, packages, and product platform.
  2. Genesis Foundry plus Genesis Algorithms: a post-Core proof-carrying search system and its separately governed, supplied .gc algorithm package collection; production never depends on Foundry implementation or mutable research state.
  3. GenesisBench: a self-hostable instrument for evaluating acquisition and trustworthy use of exact released GenesisCode and Genesis Algorithms profiles.
  4. Genesis Model: an optional specialist that starts only after the named readiness gate in ROADMAP.md; GenesisCode, Genesis Algorithms, and GenesisBench must remain useful without it.

The canonical strategy and dependency order live in ROADMAP.md. Current execution state is generated from it and policies/roadmap_execution_v0.1.json; inspect selected work with python3 scripts/lib/roadmap_execution_manifest.py --slice and all graph-ready work with the non-authoritative --ready view. docs/TECH_HANDOFF.md and docs/PAPER_v0.2.md are historical architecture inputs, not current project status.

Authority Order

  1. Normative schemas and specifications under docs/spec/.
  2. ROADMAP.md, upgrade_plan.md, and machine policies for scope, blockers, and sequencing.
  3. Source, tests, and independently checked evidence.
  4. Generated manifests, cards, indexes, and site pages as derived views only.

Never hand-edit a generated authority. Use its explicit update_* command, inspect the complete diff, then run the corresponding read-only check_* command. A generated view never authorizes its own completion.

Non-Negotiable Invariants

  • The G-lambda kernel is pure and deterministic: no filesystem, time, randomness, network, process, environment, UI, or model access.
  • UNHANDLED, EFFECT, and ERROR remain unforgeable Prelude seals.
  • No user input can panic or abort the host. Boundaries return explicit Rust errors or sealed language errors.
  • Effects and host bridges are deny-by-default, bounded, hard-cancellable where promised, deterministically logged, and strictly replayed.
  • Canonical identities, serialized formats, resource accounting, and observable semantics agree across every execution tier.
  • Optimizers, models, benchmark solvers, and Foundry candidates can propose but cannot verify, promote, grant authority, or rewrite their evaluators.
  • Production crates and release gates never depend on Foundry implementation code, mutable research state, or a Genesis Model package. Promoted genesis/algorithms artifacts cross only through independent destination review and ordinary versioned package releases.
  • Application-facing behavior belongs in libraries, capabilities, and components unless a measured semantic requirement justifies new kernel surface.

Execution Discipline

  • Until exact reviewed R9.4.f, keep one repository-changing GenesisCode Core task in progress and no repository-changing Benchmark, Challenge, Foundry, Model, or optional-pack lane. One read-only assurance observation may coexist only when it directly satisfies the selected Core task, runs on separately provisioned resources, and consumes none of the active task’s local compute, locks, or agent attention. After the signed Core handoff, complete F2.a-r Foundry Foundation and Genesis Algorithms v0.1 before activating Bench or Challenge. After F2.r, independently governed downstream lanes may each hold one coherent WIP item, but shared interfaces and generated authorities still merge serially.
  • Finish and publish the current coherent transaction before opening another. The current order is generated by --slice; do not substitute the broad set of merely start-ready tasks.
  • Reproduce a defect or define a falsifiable negative control before redesigning the boundary.
  • Prefer library behavior over CLI special cases and add goldens, differential tests, mutation controls, or proof obligations for semantic rules.
  • Use focused positive/negative checks and task-specific guards, then exactly one V2 integration route for the exact revision. Inspect bash scripts/test_changed_fast.sh --dry-run; run its impacted route for ordinary changes, or treat one canonical generated-authority transaction as the V2 route when its read-only check set subsumes the generated closure. Never run both for the same facts. Run larger profiles only when their manifest and ROADMAP validation stage require them.
  • Do not repeat an identical successful command on the same revision, inputs, host class, cache state, and seed. One additional run is allowed only for a recorded flake/nondeterminism hypothesis; statistical samples belong inside one bounded autonomous harness.
  • Qualification follows subject readiness: do not benchmark known-incorrect behavior, soak a stub, qualify an unsupported host, or run a release matrix before a release candidate exists. Long campaigns declare a decision, budget, reuse rule, stopping rule, and terminal artifact, and report only material state transitions.
  • Checks are read-only. Updates may generate state but are never evidence by themselves.
  • One canonical generated-authority update transaction plus its staged fixed-point/read-only checks is sufficient; do not rerun the updater or an aggregate merely to reproduce observations that transaction already supplied.
  • Preserve dirty user work. Do not revert unrelated changes, rewrite retained evidence, weaken a gate, or bypass protected CI to obtain green status.
  • Close a task only with the dated evidence annotation required by ROADMAP.md; local mutable reports are observations, not release proof.

Current Concentration

R0.4.j is closed on exact-main operational release-DAG and watchdog evidence; its class-separated timing calibration is preserved for R9.1.c release qualification and must not block implementation. Close P1.5 through R2.2.f next, then complete R4.1 SH-A, R5.1/R5.3 contract freeze, R4.2.a-e semantic-authority migration, the minimum R2/R3 execution prerequisites, and R4.2.f-g plus R4.3-R4.5 self-host/bootstrap closure. The generated slice selects the first start-ready Core task so a blocked downstream anchor cannot stall its prerequisite; its ordered anchors cover every unfinished R9.4.f ancestor and filter out pack-only trailing work. Carry the finite GenesisCode Core through exact reviewed R9.4.f with no target-model campaign, Challenge, Foundry, Model, or optional-pack implementation consuming the lane. That signed handoff activates F2.a-r Foundry Foundation first; F2.r publishes Genesis Algorithms v0.1 and then activates isolated GenesisBench, GenesisChallenge, continued Foundry, optional-pack, and F1/F3/F4 lanes. F2.y still waits for R8.5.s, and Genesis Model implementation still waits for R8.5.t.

Scoped instructions under a subtree override this file only for that subtree; they cannot weaken these program invariants.