Honesty for Agents.

Freeze the plan. Challenge it independently. Build in phases. Review the result before anyone marks it DONE.

ROADMAP holds the plan. HANDOVER carries the baton between sessions. Overseer Kit helps teams keep both honest from first review through final verification.

01 PLAN freeze · challenge 
independent review · revise until clear
02 BUILD phases · checks 
VERIFY against freeze · HANDOVER truth

Install v1.0.0-rc.1 Clone on GitHub

Scenarios · Docs · Release

Overseer honesty loop: freeze and independently review a plan, build it in phases, verify the result, and re-check findings until it passes

Review before build

  • Freeze the plan — write the intended outcome, phases, outputs, and acceptance evidence in ROADMAP before implementation starts.
  • Challenge it independently — give the freeze to a separate agent chat or human reviewer with no incentive to approve it.
  • Loop on findings — revise and re-review until the plan is clear enough to build without guesswork.

Roadmap · Handover · Phases

  • ROADMAP — the phase board: what is planned, frozen, building, under review, or done.
  • HANDOVER — the session baton: what landed, what remains true, and what the next session should do.
  • Phases — turn an accepted plan into bounded slices with explicit outputs and checks.
  • Continuity — the current CLI binds NEXT to the repository and revision so the right work reaches the right session.

The failure mode

Why governance honesty matters

AI-assisted work breaks down at the boundaries between planning, building, review, and the next session.

Overseer Kit makes shortcuts visible before work advances — by keeping the plan, reviews, phase state, evidence, and next handoff explicit.

The loop

How it works

Lock the plan, challenge it independently, build accepted phases, then verify the implementation before DONE.

  1. Lock and challenge the plan

    Write what will be built, how it will be phased, and what evidence will count. Freeze it, then have a separate agent chat or human reviewer try to find gaps.

  2. Build in bounded phases

    Implement only the accepted scope. Each phase carries declared outputs and project-owned checks so later sessions do not have to reconstruct intent.

  3. Review the completed build

    Compare the implementation and its evidence with the frozen plan. Resolve findings and re-check before marking the phase complete.

  4. Hand over the truth

    Update ROADMAP and HANDOVER to match what actually landed. The rc.1 CLI then keeps the next task bound to the correct repository and revision.

Structure at a glance

The original diagrams show the operating model: living documents, explicit reviews, phased work, project evidence, and a clean handoff to the next session.

Each work lane pairs a ROADMAP phase board with a HANDOVER session baton. Keep lanes few and meaningful.
Single-lane ROADMAP and HANDOVER pair with an optional multi-lane layout for separate streams of work
  • Single-lane default: ROADMAP ↔ HANDOVER
  • Optional multi-lane: each work stream gets its own living-document pair
Version control supports the governance work in the background. Git-only is complete; Muse authority and a controlled GitHub mirror are optional repository choices.
Version-control options from git-only to Muse with GitHub mirror to Muse-only
  • git-only — permanent mode; no Muse required
  • muse+git-mirror — Muse authority + controlled GitHub mirror
  • muse-only — Muse authority; no GitHub mirror
Start with living documents and plan review. Add project-owned checks and stronger separation of review when the work needs them.
Three safety layers: baseline governance and freeze review, optional domain checkpoints, and optional dual-control records
  • Baseline — ROADMAP, HANDOVER, frozen plan, and independent review
  • Project checks — tests, files, hashes, diffs, or domain scripts
  • Separation — an independent completed-build review before DONE
The kit supplies the governance pattern and living documents. Each project supplies its own runtime, tests, domain checks, and product decisions.
Overseer Kit feeding governance and living documents into projects that retain their own domain checks and product runtime
  • Kit → configuration + ROADMAP + HANDOVER + review pattern
  • Projects → implementation, tests, domain checks, and user experience

Get started

This site is informational and does not run Overseer. Install the reviewed prerelease, initialize an authorized repository, then use the governance loop with the agent tools and reviewers you already trust.

Path 1 — Install and initialize start here

  1. Follow the reviewed v1.0.0-rc.1 INSTALL-AND-ROLLBACK.md guide.
  2. Set PROJECT_ROOT to an existing Git checkout you are authorized to initialize.
  3. Run ./cli/ok with init --vcs git and the required repository name and context. Existing ROADMAP and HANDOVER files are preserved.
  4. Use the repository-bound launcher to inspect status and carry the reviewed next task between sessions.

Git-only is a complete ongoing mode. The governance workflow does not require Muse, a hosted service, or a new agent product.

Path 2 — Freeze and review the plan

  1. Write the goal, scope, phases, outputs, and acceptance evidence in ROADMAP.
  2. Freeze the plan with the governance loop, then give it to a separate agent chat or human reviewer.
  3. Resolve cited findings and re-review until the plan is safe to treat as build input.
  4. Record the accepted state so later phases do not silently reinterpret it.

Path 3 — Build, verify, and hand over

  1. Build only the accepted phases and run project checks; then have a separate reviewer compare the implementation and evidence with the frozen plan.
  2. After findings clear, update ROADMAP and HANDOVER together and publish the next reviewed task.

Overseer supplies the rails and durable state. It does not run agents, appoint the independent reviewer, decide that work is good, or merge code.

Operator detail: Installation and rollback · Release index: v1.0.0-rc.1 · Git guide: Git-only quickstart

Optional history with MuseHub

The honesty loop works in Git-only mode. When a repository benefits from Muse-backed history, Muse can become its explicit authority with or without a controlled GitHub mirror. That storage choice supports the workflow; it does not define it.

See version-control options · Adoption guide: docs/MIGRATE-EXISTING-REPO.md

Where to go next

This site explains the governance workflow and the bounded rc.1 CLI that carries its handoffs. Planning, building, and review stay in your existing tools.

GitHub

overseer-kit — source, living docs, review patterns, issues, and release history.

Docs

Docs on this site · Adapter pattern · Quickstart

Release

After reviewing v1.0.0-rc.1: Open the release — see Get started.

Scenarios

Scenario gallery — the original job flows, clearly labeled as examples.

Freeze + review plan → Build in phases → Verify before DONE

Scenarios

See how the same plan-review, phased-build, and completion-review loop applies to software, media, research, finance, and classrooms.

Open the scenario gallery →