Book a pilot

Platform

How it worksReview panelCode AssurancePlanning and contextEngines and integrations

Brunelly

GovernanceSecurityCase studyResourcesPilotsLog inBook a pilot

Governance

Your engineering standards,enforced at merge.

Engineering rules stop living in documents and good intentions. Brunelly evaluates them, deterministically, against the exact commit that would merge, records every decision, and makes exceptions accountable.

Book a pilot Security and trust

Merge policy

Two rules unmet. The merge is blocked.

Every merge is decided against the precise revision that would land. If the branch moves, the decision is taken again. On GitHub and Azure DevOps the same rules hold for pull requests opened anywhere, not only those Brunelly created.

Merge policy · Payments Platformat f519425
  • Code Assurance present and current at headMet
  • No undispositioned finding at medium or aboveMet
  • Two human reviewers, one a code owner1 of 2 approvalsNot met
  • Separation of duties: author cannot approveMet
  • Release freeze on release/**Freeze active until 4 NovNot met
Blocked: 2 rules unmetOrg rule · pinned

Policy model

Central control, local flexibility.

Policies stack from the organisation down to a branch pattern. The organisation decides what is fixed; projects adapt the rest.

  1. 01

    Organisation

    Central rules for every project. Pin the ones that must never move.

    Pinned rules cannot be weakened
  2. 02

    Project

    Rules for one product or team, adapting what the organisation leaves unpinned.

    Adapts unpinned rules
  3. 03

    Branch pattern

    Stricter rules where it counts, such as release/** during a freeze.

    Targets matching branches

How it holds

Rules that apply whoever writes the code.

  • 01

    Policies at every level

    Define rules for the whole organisation, for a project, or for branches that match a pattern. Pin a central rule and no project can weaken or disable it; leave it unpinned and teams can adapt it locally.

  • 02

    Evaluated at the exact commit

    Every merge is decided against the precise revision that would land: required assurance present and current, findings within threshold, the reviewers you require, separation of duties and release freezes. If the branch moves, the decision is taken again.

  • 03

    Findings are dispositioned, not hidden

    Every finding ends one of three ways: fixed and gone from the head commit, raised as tracked work, or suppressed under a stated reason and expiry. Hiding a finding from view is not a disposition.

  • 04

    Governed exceptions

    Overrides need the right permission and a written reason, and are recorded. For emergencies, break-glass is a separate, single-use grant bound to one evaluation and one commit, so it can never be reused on anything else.

  • 05

    Policy as code

    Keep policies in your repository as YAML, with the repository, commit and content hash recorded on every version. Simulate a change against recorded decisions before you enforce it, and let a new version promote itself only when it is provably stricter.

  • 06

    Enforced in your repositories

    On GitHub and Azure DevOps, Brunelly configures a required check on the default branch and verifies the platform applied it, so the rules hold for pull requests opened anywhere, not only those Brunelly created. A drift sweep reports any rule someone removes.

  • 07

    Tamper-evident audit

    Policy decisions, approvals, overrides and rule changes are written to a hash-chained trail per tenant, verified every fifteen minutes and in full weekly, and sealed with signed anchors in write-once storage.

  • 08

    Evidence you can verify yourself

    Export a signed evidence pack for an auditor or a regulator, with a standalone verifier that checks it offline, without access to Brunelly.

  • 09

    Keys per tenant, erasure by design

    Data is protected by a key hierarchy rooted in HSM-backed keys, with keys per tenant and per subject. Erasing a person destroys their key, so their audit records become unreadable while the chain around them still verifies.

Exceptions

When the rule has to bend, it bends on the record.

Real delivery needs exceptions. Brunelly gives them a shape, an owner and a trail.

Override

A reasoned exception to one rule

  • Needs the override permission
  • A written reason, captured with the decision
  • Recorded in the audit trail
Break-glass

An emergency that cannot wait

  • A separate grant, for people only
  • Single use, bound to one evaluation and one commit
  • A written reason, always
  • Written to the audit trail as a mandatory record
Three Blocking policy checks: Minimum human reviewers, Required reviewer group: Security showing 0 of 1 approvals from a group of 1 person, and Separation of duties. Below, an amber Policy override panel explains that a governed override applies once to this exact evaluation and head, that the pull request can only merge through the platform's own merge gate, and that the author cannot waive the block with a routine override. A Break glass button is shown.
The remaining blocking rules on the same pull request and the policy override panel, which refuses a routine override from the author and offers only a break-glass path.

Evidence

A trail that proves itself.

Every governance decision is chained to the one before it, verified continuously and sealed in write-once storage. Export it for an auditor, with a verifier that runs offline, without trusting Brunelly.

  • Hash-chained per tenant, verified every fifteen minutes
  • Sealed with signed anchors in write-once storage
  • Evidence packs an auditor can verify offline
Policy set activatedGroup Change Control Standard v3
9f2c…e41a
Merge evaluated: blockedPR #3 at a41c09e · 2 rules unmet
1b7d…08c2
Break-glass grantedSingle use · bound to evaluation and commit
c3e9…5f17
Merge evaluated: allowedPR #2 at 7f20b1d · override consumed
6a40…d9b3
Sealed: signed anchor in write-once storage · chain verified

Policies at merge

0:28

Your rules, evaluated at the exact commit

Human approvals and separation of duties enforced, an override with a named person and a written reason, and the record.

The product

Governance, in the product

Every plan, review, decision and exception is on the record, and on screen.

Pull request #3, Sanctions screening hook before acceptance, from feature/sanctions-screening into main, status Open. The Merge Pull Request button is disabled with the message Merging is blocked by policy; satisfy the blocking rules or have an authorised person place an override. A Policy checks list shows Approval invalidation mode Satisfied, Blocking finding severity: Security Blocking, Change blackout year-end-close-2026 Satisfied with its UTC window, Code Assurance required and current Satisfied, and Finding disposition required: Security Blocking.
Pull request #3 with its merge button disabled because organisation policy is not yet satisfied, and each policy check listed as Satisfied or Blocking.
Policies table with filters for status and scope, showing 3 of 3 policy sets. Payments Platform - Security Controls, project scope, 7 rules, Draft version 2, with an activation panel noting version 1 is currently governing and that a second administrator must schedule the draft because the organisation requires a second person to put policy into force. November release freeze, scope branch release/**, 1 rule, Active, currently governing. Payments Platform - Security Controls version 1, project scope, 5 rules, Active, currently governing.
The project's policy sets with scope, rule count, status and version, including a branch-scoped release freeze and a draft that needs a second administrator to activate.
Dialog titled Review this policy candidate for Release branches - payments change control, with source key release-branch-controls, commit 17f4058 and compile time. A notice says the candidate governs nothing until promoted. A Comparison section explains why the versions cannot be ordered, then Added (4) lists rules with Governing now and This candidate columns: Blocking finding severity at minimum Medium, Code Assurance required and current, Minimum human reviewers of 2, and Separation of duties with prohibit self-approval and require independent approval of AI-launched work switched on. The Promote button is disabled because a second administrator must promote it.
A policy candidate compiled from a repository commit, compared rule by rule with what governs now before anyone can promote it.
Expanded audit event Break-glass override granted, performed by a person, with a timestamp in UTC, a 1 restricted badge and a Causality button. A correlation id is shown, then a field table where the Reason field's old and new values both read Value restricted. Event details list author user id, head commit, idempotency key, Made by a person: Yes, Override class: Break-glass override, Override outcome: Granted, policy evaluation id, policy override id, pull request id, reason length 454 and request channel Web app.
The Security audit entry for a granted break-glass override, with the reason withheld from this viewer and the evaluation, override, commit and pull request it applied to.
Page titled How this change came about. The change set is Break-glass override used. A Causality trace tree starts at Break-glass override granted, marked Origin, where this began; under it the opened event Break-glass override used, and under that Pull request merged for pull request #2, each with actor and UTC timestamp. A footer explains where the trace stops: toward the origin at the origin, and no further events caused within the viewer's entitled streams.
The causality view for a break-glass override, tracing it from the grant to its use and the pull request merge it allowed.
Audit log page with tabs Security, Billing, Configuration, Data changes and AI execution, Configuration selected, and filters for subject type, subject id, performed by, initiated by, action and time range. A Record integrity panel reads Verified through sequence 34 with the check time. An Evidence sealing panel reads All records sealed, every record has a sealed copy in write-once storage, all 34 records sealed, nothing waiting to be sealed, records sealed every 10 minutes. An Activity volume panel reports not enough history yet to evaluate.
The project audit log with its five streams and filters, and integrity panels confirming the hash chain is verified and every record is sealed in write-once storage.

Keep exploring

The rest of the platform.

Get started

Make software engineering repeatable.

Every engagement starts with a scoped pilot on one problem that matters, measured against how your team works today.

Book a pilot See how it works