Bracel
Request access

Bracel Verify

Executed checks for the rules that must hold.

Four steps, the same on every pull request: define the rule, approve it through your normal review, run it against the change in your own runner, and inspect what happened.

Request access Try a rule
base commit
rules file pull request head
your change Bracel run
Rules from the base. Code from the head. A change can never rewrite its own judge.

How it works

From a business rule to a pull request check.

  1. 01

    Define

    Start from a rule template and point it at your application: how to start it, which routes the rule exercises, where to read the result. The rule logic ships in the release; your repository says only which rules to run and how to reach your app.

  2. 02

    Approve

    The rules file lives on your default branch and changes only through a reviewed pull request. Bracel reads rules from the base commit, never from the head, so a pull request cannot change the rules that judge it.

  3. 03

    Run

    Inside your own GitHub Actions runner: dependencies install from the public npm registry only, the application builds and starts in isolation without network access, and each applicable rule runs its scenario.

  4. 04

    Inspect

    The check names the approved rule and why it ran, what was expected and observed, why the verdict follows and what to do next. A PASS lists every behaviour that was actually executed.

Verdicts

Four answers. Each one earned.

Every result ends in exactly one verdict, with one reason code. Only PASS means a rule was executed and held.

  1. PASS

    At least one behaviour was executed and every applicable approved rule held. The summary lists each executed behaviour.

    Job succeeds

  2. FAIL

    An executed behaviour violated an approved rule. The summary shows what was expected and what was observed.

    Job fails

  3. UNKNOWN

    A result could not be established: unsupported setup, a failed install or build, an app that did not start, an inconclusive observation, or a change to Bracel’s own rules. Never a pass.

    Job fails

  4. NOT_APPLICABLE

    No approved rule applies to the files this pull request changes. Zero checks executed, and no verification claim is made.

    Job succeeds

Every reason code →

Try it

Run it yourself.

Pick a rule and a version of the change. The steps are the ones the rule template performs; the summary is what lands on the pull request.

Rule
Change

PR #482 as opened: the guard no longer counts what was already refunded.

  1. POST /payments · 100.00 201
  2. GET refunded total 0.00
  3. POST refund · 50.00 (control) 201
  4. GET refunded total 50.00
  5. POST refund · 50.01 201
  6. GET refunded total 100.01

Bracel · refund.amount-cap@1

Advisory: Bracel changes no merge settings.

FAIL
Approved rulerefund.amount-cap@1: refunds never exceed the captured amount
Why it ranThis pull request changes src/payments/refunds.ts
ExpectedThe 50.01 refund is rejected with a 4xx; the refunded total stays 50.00
ObservedThe 50.01 refund was accepted (HTTP 201)
WhyThe rule was executed and did not hold
Next stepRestore the remaining-amount check, or change the rule on the base branch through review
Provenancerelease 3f9c2e1 · code digest 7d41…a0e9 · ran in customer-ci

Illustrative example · the steps follow the rule templates; values are not customer data

Write your own rule in the rule lab. Point it at your routes, choose how the app answers, read the verdict.

When a rule runs

Scoped to the code it protects.

Add paths to a rule to run it only when matching files change. Omit paths to run it on every pull request.

Bracel changes no merge settings. If your administrators make the check required, a failing result blocks merging. NOT_APPLICABLE succeeds, so a pull request that touches none of a rule’s paths merges without that rule running.

Limits, stated

What a verdict does not say.

A verification product is only as useful as the honesty of its edges.

  • A PASS is exact, not general

    It covers only the behaviours the summary lists as executed. It says nothing about the rest of your application.

  • customer-ci protects against accidents

    Results ran in your runner and Bracel did not observe them. They protect against accidental regressions, including ones introduced by AI coding tools, not against a contributor who modifies the workflow.

  • Protect the referee

    Protect your workflows and rules file with code owners. A pull request that changes them gets UNKNOWN with policy-review-required.

  • A defined profile

    Bracel supports a defined set of stacks today. Check your repository against it in two minutes.

See exactly what each rule executes, step by step.

Rule templates Check compatibility