Skip to content
rematch

The evidence boundary

The session is the evidence, and a model may only propose. What gets written, loaded or executed is decided by record types and counters, not by a prompt.

Architecture. omp (stock or a fork) emits events to the extension, which writes traces and has the binary sync the shared skills directory before discovery. The Rust binary owns rematch-core, reflect and count, create and improve, batch and scope, and calls omp -p non-interactively for the editor, the classifier and batch rollouts. State lives under ~/.rematch; kept entries are copied into ~/.omp/agent/skills.Architecture. omp (stock or a fork) emits events to the extension, which writes traces and has the binary sync the shared skills directory before discovery. The Rust binary owns rematch-core, reflect and count, create and improve, batch and scope, and calls omp -p non-interactively for the editor, the classifier and batch rollouts. State lives under ~/.rematch; kept entries are copied into ~/.omp/agent/skills.

Two sides

Section titled “Two sides”
In the session Outside the session (detached binary runs)
Runs the omp extension (or a harness adapter) the Rust binary
Does records every input, tool result and turn; flags; loads; runs approved hooks classifies, proposes, lints, stages, counts, decides
Model calls none editor and classifier, through omp -p
Parses nothing: it forwards raw events everything: the schema lives in Rust only

No proposal exists without a trace (D1). The binary never holds provider credentials; every model event’s provider and model are verified.

What a proposal can and cannot do

Section titled “What a proposal can and cannot do”
  • It carries no score field. Scoring belongs to the counters, never to the model that wrote the text.
  • Nothing activates without a lint report. Anything executable also needs a receipt (D24).
  • Skill text activates on its own, in your personal scope, as provisional.
  • Scripts, hooks, subagents and system-prompt text wait for you. Scripts are staged non-executable; hooks are compiled only after approval (D4); a provisional subagent is linked nowhere and a fragment is added to no prompt until you approve it.
  • Anything beyond your machine waits for a merged PR (team .omp/, your fork).

Lint is the generalization gate

Section titled “Lint is the generalization gate”

Every staged entry passes static lint (D15):

  • no session ids, task paths or user names in the text;
  • no string-match on the user’s words;
  • a trigger predicate and a trigger line on every entry;
  • no URLs, network calls or destructive git;
  • always-on text within 8 KB per branch: skill descriptions and bodies, subagent descriptions and prompt fragments;
  • facts carry as_of.

HarnessCompass’s generalization gate alone recovered most of its gain. Full rule set: lint rules.

Scope and who merges

Section titled “Scope and who merges”
Scope Activation Examples
Personal, text automatic, as provisional skill text, laws, facts, lessons
Personal, subagents and prompt one tap in the session-start digest, with the text; bound to the file’s hash, so an edit asks again provisional subagents; AGENTS.fragment.md, appended to your system prompt where the entry loads (your AGENTS.md is never written)
Personal, executable or blocking one tap in the session-start digest, with the diff scripts (0644 → 0755), compiled tool_call verifiers
Team (<repo>/.omp/, <repo>/AGENTS.md) ship --scope team: a branch with the entry and an evidence commit; --push --pr opens the PR, never merges entries whose predicate recurred across two or more repos, or that you list; the only way text reaches a repo’s AGENTS.md
Fork ship --scope fork: the entry’s fork_path, the built fingerprint and before/after counters in the PR body per-model prompt text, tool descriptions, compaction defaults
Work → home library export, per-entry approval with the diff; off by default at work invariant entries only; lint with transfer: true blocks domain and workspace facts

No fork of omp is required; the fork is one of the things rematch can propose changes to.

Branches and shared

Section titled “Branches and shared”
  • A branch is a repo or project. Entries are staged per branch.
  • shared holds entries kept in two or more branches. Promotion needs a second branch’s canary and no new canary of its own.
  • When the shared copy replaces a kept entry whose task has a verifier, that task is replayed once first. A failing replay retires the copy; the kept entry stays.
  • Transfers between branches with overlapping facets are applied as provisional and earn their place through that branch’s counters.

See also

Section titled “See also”