Coming soon

Bracel Fix · a separate product

A rule failed. Here is a fix that already passed.

Fix explains a FAIL, writes one patch, and hands it to Verify, which judges it in a clean environment with values the fix never saw. Only then does it reach you, as a draft pull request.

  • Draft pull requests only
  • Judged by Verify
  • Hold-out values
  • Your model, your key
  • Charged only when it passes
Session replay bracel fix · PR #482 · refund.amount-cap@1 00:19 / 00:20

Session

  1. Verify · PR #482 · refund.amount-cap@1FAIL · a 50.01 refund after 50.00 of 100.00 was accepted
  2. Fix job startedattempt 1 of 3 · estimate shown before start
  3. Reading the failing behaviourrule, scenario, observed response

Why it failed

The guard compares each refund with the captured amount. It has to compare the refunded total plus this refund, so a second refund cannot push the total past the capture.

  1. Changed: src/payments/refunds.tsapplication code
  2. Tests, fixtures, rules and workflowsuntouched

src/payments/refunds.ts

  1. 41export async function refund(paymentId: string, amount: number) {
  2. 42 const payment = await payments.get(paymentId);
  3. 43 if (payment.refunded + amount > payment.captured) {
  4. 44 throw new RefundExceedsCapture(paymentId);
  5. 45 }
  6. 46 return payments.addRefund(paymentId, amount);
  7. 47}

Verify · clean environment · rules from the base commit · hold-out values

  1. POST /payments · 74.00201
  2. POST refund · 37.00 (control)201
  3. POST refund · 37.01422
  4. GET refunded total37.00

PASS · the listed behaviours were executed and held

Draft pull request #483 bracel-fix/482-refund-cap → main

Fix: compare the refunded total with the capture

Proposed by AI. AI can be wrong. Review it like any other change.

Merge · your decision Bracel never merges and never writes to main.
Illustrative session · Bracel Fix is planned · the scenario follows refund.amount-cap@1

Two products, one referee

Fix never grades its own work.

Verify and Fix are separate engines with separate jobs. Verify is the referee: it executes and reports, and it does not need Fix. Fix is the engineer: it proposes, and every proposal goes back to the referee.

Bracel Verifythe referee

Bracel Fixthe engineer

Its job

Executes your rules on the pull request and reports what it observed

Proposes one patch for one failing rule

What it writes

A check result on the pull request. Nothing else.

A draft pull request on its own branch

Uses an AI model

No. Verdicts come from executed requests.

Yes, from a provider you choose, under your key

Works without the other

Yes. Verify is the product on its own.

No. Every proposal is judged by Verify.

How it is priced

Per organization. Verify never stops at a quota.

Charged only for fixes that pass verification

The job

One failure in. One verified proposal out.

  1. 01Input

    One FAIL

    Fix starts from what Verify executed and observed: one rule, one scenario, one pull request. Not from a guess about your codebase.

    refund.amount-cap@1 · FAIL · 50.01 accepted

  2. 02Proposal

    One patch

    A bounded job: a few attempts at most, a token budget and a time limit, with an estimate before it starts and a running total while it works.

    src/payments/refunds.ts · +1 −1

  3. 03Judgement

    Verify, without favours

    The patched head runs in a clean environment, from the rules on your base commit, with hold-out values the fix never saw.

    74.00 · 37.00 · 37.01 → 422 · PASS

  4. 04Output

    A draft pull request

    On its own branch, with the patch, a plain explanation, what was verified and what was not. Merging stays with you.

    PR #483 · bracel-fix/482-refund-cap

A fix job is small on purpose: a single failing rule on a single pull request. Small jobs can be checked, priced and trusted.

What lands in your repository

Anatomy of a proposal.

Every Fix pull request has the same shape, so a reviewer knows where to look and what was, and was not, proven.

Draft

Fix: compare the refunded total with the capture #483

1bracel-fix/482-refund-cap → main

2The guard compared each refund with the captured amount. It now compares the refunded total plus this refund, so a second refund cannot push the total past the capture.

3
  • Application codesrc/payments/refunds.ts · +1 −1
  • Tests, fixtures, rules, workflowsuntouched
4

Verify PASS · refund.amount-cap@1 · hold-out values 74.00 / 37.00 / 37.01

5Other behaviours were not checked by Bracel.

Proposed by AI. AI can be wrong. Review it like any other change.

6Merge · your decision
Illustrative · Bracel Fix is planned
  1. 1

    Its own branch

    Never your default branch. One branch per job.

  2. 2

    A plain explanation

    Why the rule failed and what the patch changes, in a few sentences.

  3. 3

    Changed files by category

    Application code, tests, configuration: visible before you open the diff.

  4. 4

    What was verified

    The rule, the scenario and the hold-out values, with the result.

  5. 5

    What was not

    Other behaviours were not checked by Bracel, and the pull request says so.

  6. 6

    Your decision

    A draft. Bracel never merges and never enables auto-merge.

Guardrails

Proposes. Never decides.

The verdict on a fix comes from the same engine that judged the failure, never from the model’s own account of what it did.

  • Never writes to your default branch

    Every proposal is a draft pull request on its own branch.

  • Never merges, never enables auto-merge

    Merging stays a human decision, or your own GitHub automation.

  • Stops at protected paths

    If a patch would change a protected path, the job aborts, unless you allow it for that job.

  • Stops when it cannot prove itself

    A patch that exceeds the size limit, or gets UNKNOWN from Verify twice, ends the job.

  • Spending you control

    An organization limit set by you is a hard stop. Nothing is charged beyond it without new consent.

  • States what was not checked

    “Verify PASS for this rule on this scenario. Other behaviours were not checked by Bracel.”

Protected paths, by default

  • Your rules file
  • Policies
  • Workflows
  • Lockfiles
  • Tests and fixtures

Your model, your key

The code goes where you send it.

Fix uses a model provider you choose, under your own API key and your own contract with that provider. Bracel does not see the code that goes to it.

Inference
Your provider account and key
Data path
From your environment to the provider you chose
Bracel
Receives no source code
Verdict
From the Verify engine, never from the model’s text
Proposed pricing

Fair by construction

Pay for fixes that pass. Nothing else.

A charge applies only when every condition holds. A model saying it succeeded is never one of them.

Charged only when

  1. Verify passes the target rule on the patched head, including hold-out values the fix never saw.
  2. The patch changes no protected path.
  3. Your own required checks do not newly fail.
  4. The draft pull request was delivered.

Never charged when

  • The job ends in FAIL, UNKNOWN, a timeout or an exhausted budget.
  • The patch was stopped at a protected path.
  • A Bracel defect caused the failure.
  • You reject the pull request within the stated window.
See plans and the Fix add-on →

Verify tells you it broke. Fix shows you how to mend it.