See the assessment from first answer to build PRD.
A walk through the tool with a fictional bank. Answer a question, read the diagnosis, check the plan, then state a need and watch the tool write the build PRD for it. Every company, figure and result on this page is an example.
Who approves a change for production, and are they independent of the requester and the implementer?
Choose the answer that describes what most teams do today.
A change board or a manager approves. Independence from the requester and implementer is not checked.
Evidence: change board minutes
A change board or a manager approves, sometimes using AI-written summaries.
Evidence: change records
A person approves every release that an agent prepared, and runs it.
Evidence: approval records on agent-prepared releases
A named person who is neither the requester nor the implementer approves each change, enforced by the tooling. Emergency changes are approved after the fact within a set time.
Evidence: the change approval log and emergency change records
In the allowed domain, changes deploy on evidence with automatic rollback and post-change verification, and the domain owner can veto. Critical functions stay at L3 unless internal audit has signed off.
Evidence: the autonomy certificate and veto log
As L4. Changes to release rules are approved by a person through the strict path, never by the factory.
Evidence: the approval record for each rule change
Not sure
Northbank today: mostly L1 and L2.
Levels set by the weakest practice in each step, after the working session. Testing and checks is the step holding everything else back.
| Step | L0 | L1 | L2 | L3 | L4 | L5 |
|---|
Jira · Confluence · GitLab self-managed · GitLab CI · SonarQube · Argo CD · Dynatrace · Microsoft Teams · Keycloak · HashiCorp Vault · Approved models on-premise
Option C, sovereign: models on Northbank’s own servers. Critical functions: Review and Release capped at L3. Works council informed; team-level data only.
Testing first. Then the rest can move.
Northbank wants Implementation at L4 for dependency updates. The tool checks what has to be true first and orders the jumps, one level at a time.
Implementation L4 is not possible yet. It needs Testing and checks at L4 (today L2), the verification base largely in place (today partially) and Specification at L3 (today L1). These come first.
Automated gates on every change, evidence recorded
Agents draft specifications and acceptance criteria
Agents take approved tasks from the pipeline
Independent review agent; named human approves
Change approval enforced by tooling; automated rollback
Replay set from past changes, measured test adequacy
Shared templates and checked acceptance criteria
Allowed domain: dependency updates, with an autonomy certificate
State a need. Get a build PRD.
Anyone authorised writes the need in plain words. The tool reads Northbank’s profile, stays inside the charter, tests the proposed setup on past work and writes the build PRD with its configuration.
Automated checks for the customer onboarding service
Owner: head of platform. Approvers under the charter: head of platform, risk and compliance owner.
1. The need and the measure
Releases take about two weeks, mostly waiting for checks and approvals. Measure: median time from merge request to all checks passed. Baseline: 6.5 daysexample, from the last 90 days of GitLab data.
2. Why now
Testing and checks is at L2 and blocks four later jumps in the plan, including Implementation L4. This is the first item of wave 1.
3. Workflow covered
Every merge request on the customer onboarding service (one repository, one team). Other services are out of scope for this step.
4. What the factory will do
- Run a fail-to-pass check on every change: the new test fails without the fix and passes with it
- Run the existing SonarQube rules and a dependency scan in GitLab CI
- Run end-to-end tests on a preview environment for each merge request
- Write missing tests for changed code, as a separate change for review
- Record the evidence for each change in one log linked to the Jira ticket
- Block any change whose evidence is missing
Runs without a person: all checks and the evidence record. Model: the best-scoring approved on-premise model on the replay set; no fallback to any other model.
5. What stays human
- Accepting each change (P6 stays at L2 in this step)
- Approving each release (P7 capped at L3 for this critical function)
- Approving any change to the gates themselves
6. How it is proven
| Replay test | Setup run on 120 past merge requestsexample; the gates caught the 9 changes that had later caused incidentsexample |
| Success measure | Median time to checks passed falls below 2 days, with change failure rate no higher than today |
| Level reached | P5 at L3 for this service, confirmed in the next assessment |
7. Scope, effort and cost
About 6 weeksestimate: two Quicksort engineers with one Northbank platform engineer. Uses tools Northbank already runs; adds a preview environment template in GitLab CI.
8. Risks and out of scope
- Flaky existing tests may block changes: quarantined and listed in week 1
- Preview environments need test data: synthetic data only, no customer data
- Out of scope: auto-merge, other services, changes to release approval
# factory configuration · generated with this build PRD
project: customer-onboarding
step: P5 Testing and checks
level: { from: L2, to: L3 }
deployment: option-c # sovereign, on-premise
models:
allowed: approved-on-prem # chosen by replay-set score
fallback: none
connectors:
tracker: jira
source: gitlab-self-managed
ci: gitlab-ci
chat: teams
gates: # all must pass, fail closed
- fail_to_pass
- sonarqube
- dependency_scan
- e2e_preview
evidence:
log: append-only
link_to: jira-ticket
human_decisions:
accept_change: head-of-platform
approve_release: change-approver # independent of author
change_gates: risk-and-compliance
agent:
identity: per-run, short-lived
network: no outbound traffic
data:
preview_data: synthetic-only
Want to see it on your own delivery?
Thirty minutes is enough to tell whether the assessment is the right first step, and who should answer.