How it works

Every piece of work scoped, approved, delivered and proven.

EmberNest sits between the tools that write code and the systems that run it. Coding assistants and agents produce the change. EmberNest decides what is in scope, who approves it, how it is checked, and what evidence is kept.

01 · Scan

Assess

EmberDNA scans the codebase against your engineering rules and grades it. Each finding is tied to its business impact: reporting, access or day-to-day operations.

02 · Plan

Scope

Findings become Sorties: small, scoped pieces of work, each with one acceptance test that fails before the change and passes afterwards. Each is priced against the rate card agreed for that customer and names the AI model tier it will use.

03 · Two approvals

Approve

Two approvals, in order: commercial sign-off on the price, then the budget owner's authorisation of the work.

04 · Sweep, gate, ship

Deliver

Each Sortie is worked in its own isolated copy of the repository, so parallel work cannot collide. Before anything merges, the acceptance test runs again on top of the latest code. Deployments follow your release process.

05 · Verify

Prove

What shipped is checked in a real browser where it applies, and the repository is scanned again. If a later change breaks it, the Sortie reopens automatically.

A Sortie cannot be closed by hand. Its acceptance test has to pass on main.

Requirements without an acceptance test never start.

The engine

Three controls under everything.

Scan

EmberDNA reads code against AST-accurate architecture rules, not pattern-matching guesses. You define the rules; the scan grades the code and reports what breaks them.

Heal

Drift is rewritten to match your rules, wrapper-first and dry-run by default. You decide which rules heal automatically and which raise a change for someone to review.

Gate

A change that fails the checks you have defined does not ship. Raise a threshold and the gate holds the new line.

Runs on the branches and pushes you connect.

Two approvals, never one

Your team signs off the price. The budget owner authorises the work.

Before a quote is published.

The commercial lead reviews the scope and the calculated price, then approves it, amends it, or sends it back for re-scoping.

Before any work starts.

The budget owner reviews the published scope, price and acceptance test, then authorises the work or asks for an amendment.

Both approvals are recorded against the quote version. Any change to scope or price goes back through both.

Automatic inside the approved scope. Nothing outside it.

  • Inside an approved Sortie, agents write and heal code automatically against your rules, with up to three attempts.
  • Work that falls outside the approved scope is parked, not done.
  • Nothing merges unless the Sortie's acceptance test passes on the latest code.
  • Deployments follow your release process and any deployment approvals you require.
  • Outside a mission, fixes apply automatically only on the rules you have marked safe. Everything else waits for review.

Five safeguards, one per stage.

Isolated worktrees

Each agent works in a separate copy of the repository, so one piece of work cannot interfere with another.

Shared rules and acceptance

Every change is checked against the DNA rules and its own completion test.

Review against current code

Changes are re-tested against the latest shared code before they merge.

Controlled deployment

Releases follow the agreed process and required approvals.

Evidence linked to the work

Test results, browser checks and re-scans are attached to the Sortie they prove.

One portal, three questions answered.

What needs fixing.

A priced item, ready for approval.

What is being done.

A scoped Sortie with visible status.

What actually shipped.

A verified result, the test evidence and a fresh scan.

Evidence covers the agreed scope of each Sortie, not the whole application.

Match the model to the work.

Each quote names the model tier it will use, so AI cost is visible item by item and kept separate from the delivery price. Set budget alerts and routing policies per programme, or run on your own model subscription.

Clearer measurement and control, with no blanket claim that every workload will cost less.