Skip to content
BMO

Edit Quality

BMO’s edit quality pipeline connects seven stages — from intelligent tool selection through adaptive learning — so each edit in a session benefits from what the system learned from previous edits. The pipeline catches errors introduced by edits before the model moves on, and automatically adjusts strategy when edits are producing too many failures.

What problem it solves

Section titled “What problem it solves”

Multi-line edits can introduce compilation errors, break references in other files, or fail to apply when the model’s old_string doesn’t match exactly. Without validation, the model discovers these problems turns later — or never. BMO catches them immediately and feeds the information back.

How it works

Section titled “How it works”
flowchart LR A["Tool Router"] --> B["Pre-edit Ripple"] B --> C["Edit Mutation"] C --> D["Confidence Gate"] D --> E["Post-edit Ripple"] E --> F["Edit Resolver"] F --> G["Adaptive Learning"] G -.->|reshapes| A
  1. Tool router — a decision tree biases the model toward the smallest edit tool that matches the intent (edit for single replacements, multiedit for coordinated changes, LSP symbol tools for renames). Model edit metadata can declare an edit_floor (exact_replace, unified_diff, patch, or whole_file) that constrains low-confidence format choices while adaptive edit_tool_preference remains the higher session-learning layer.
  2. Pre-edit ripple — before the file is modified, LSP impact analysis identifies which other files reference symbols in the edited file.
  3. Edit mutation — one of 8 edit tools applies the change.
  4. Confidence gate — for multi-line edits, LSP error counts are compared before and after. If new errors were introduced, a <confidence_gate> warning tells the model to fix them.
  5. Post-edit ripple — after mutation, a second ripple analysis identifies affected files and suggests follow-up edits.
  6. Edit resolver — when exact old_string match fails, a small model produces the correct replacement.
  7. Adaptive learning — the edit_tool_preference gene tracks resolver fire rate and reshapes the edit strategy mid-session.

Configuration

Section titled “Configuration”

Most layers activate automatically when LSP is available. The edit resolver auto-enables when a supported backend is configured.

[options.edit_resolver]
enabled = true         # auto-enables when backend supports it
model = "small"        # cost-bounded: uses the small model slot


[options.smart_apply]
enabled = true         # stale-file 3-way merge


[options.suggested_edits]
mode = "advisory"      # "advisory" or "required"


[options.adaptive_orchestration]
enabled = true         # enables edit_tool_preference gene

Options

Section titled “Options”
OptionDefaultDescription
edit_resolver.enabledautoModel-assisted fallback for exact-match failures
edit_resolver.model"small"Model slot: small (fast) or large (more reasoning)
smart_apply.enabledfalseStale-file conflict recovery via 3-way merge
suggested_edits.mode"advisory"Whether ripple-suggested edits are best-effort or required
adaptive_orchestration.enabledfalseAdaptive genome including edit_tool_preference gene

The tool router and confidence gate have no config — they are always active when the edit tools run.

When to enable

Section titled “When to enable”
  • Edit resolver — enable for any session using models that occasionally produce inexact old_string matches. Cost is bounded by the small model slot.
  • Smart Apply — enable for long sessions or multi-agent workflows where files may change between reads and edits.
  • Adaptive orchestration — enable for sessions where you want the system to learn from edit patterns and adjust strategy automatically.
Section titled “Related”