The FORGE Diagnostic: one workload, engineered to your standards, running where you can watch it
A working slice of one workload you select, built on FORGE with your security controls in the path and deployed in your own environment. Beside it, a readiness assessment of how your current delivery compares, and a proposed next step. You keep all three.
The Diagnostic shows you how your software should be built by building some of it. FORGE is our product, an engineering platform. It builds your enterprise's architecture, security and governance standards into the path to production, so every team ships to those standards. A BtSavvy engineer takes one workload you select and builds a working slice of it on FORGE. The work happens with your team, inside your repositories and your cloud account. Your architecture and security standards are in the path from the first commit. The pipeline is generated, the deployment is real, and you watch it run. It takes 2 to 4 weeks of engineering time, sized to the workload and the decision in front of you. Most engagements begin here.
You do not have to take the method on faith. A recommendation tells you what should change. The Diagnostic shows governed delivery happening on your own workload, and the comparison makes itself. Nothing in your existing production is altered. The first look at your cloud account is read-only, and nothing in it changes until a person on your side has agreed to the change. The decisions that matter carry an accountable owner from your team, ours, or both. Every one is on the record, with the person who made it. The evidence is produced as the work happens, so what you hand to a sponsor or an auditor afterwards is a lookup, not a reconstruction. You decide against working evidence from your own environment.
01
Where the Diagnostic happens, and whose it is
2 to 4 weeks
| Item | Yours | Ours |
|---|---|---|
| The workloadOne, and you select it. | Yours | |
| The repositoriesThe work happens inside them, with your team. | Yours | |
| The cloud accountFirst look read-only. Nothing changes until a person on your side agrees. | Yours | |
| Architecture and security standardsIn the path from the first commit. | Yours | |
| Existing productionNot altered. | Yours | |
| The engineerOne, from BtSavvy. | Ours | |
| FORGEOur product. The platform the slice is built on. | Ours | |
| Every decision that mattersAn accountable owner, on the record with the person who made it. | Yours | Ours |
| The evidenceProduced as the work happens. Afterwards, a lookup. | Yours |
Two entries on our side of the line. Everything else is already yours.
What's included
Three things, and you keep all of them.
- A working slice of your workload, running. Built to your standards and traceable to your requirements. Your security controls are in the build path and the pipeline is there from the first commit. Deployed where you can watch it. Your workload, not a slide.
- A readiness assessment. Where your current delivery stands against what you just watched: architecture, data, cloud, pipeline, operations and governance. Where a system already exists, what it would take to recover what it does and prove that a rebuild behaves the same. Yours, as files in your own repository.
- A proposed next step. Which engagement fits the decision in play, and what your team would own at the end of it. The standards, the patterns and the reference build stay in your repository for every build that follows.
02
What remains when the Diagnostic ends
All three
| Item | Yours | Ours |
|---|---|---|
| A working slice of your workload, runningDeployed where you can watch it. Your workload, not a slide. | Yours | |
| A readiness assessmentWhere your current delivery stands, scored across six areas. Files in your own repository.ArchitectureDataCloudPipelineOperationsGovernance | Yours | |
| A proposed next stepWhich engagement fits the decision in play, and what your team would own at the end of it. | Yours | |
| The standards, the patterns and the reference buildIn your repository, for every build that follows. | Yours |
Nothing in the right-hand column. That is the point of it.
When to engage
When the next decision needs working evidence rather than another proposal.
Your organisation is considering enterprise AI delivery and needs a first move it can judge. Standards, controls and requirements exist on paper, and leadership wants to see software built inside them. An earlier piece of work, internal or external, produced recommendations, and the next conversation needs something running. An audit is on the calendar, and you want to see what evidenced, traceable delivery looks like before you commit to it.
What comes next
The Diagnostic ends with a proposed next step, and you choose. The usual next steps are a Proof (one use case, proved in production) or a First Build (one application, end to end, into production). A Focused Engagement takes on the single service the assessment surfaced. Where the ambition spans the estate, the Diagnostic becomes the scoping input for Strategy to Run. Some conclude with no next step, and that is a valid outcome. The working slice, its evidence and the assessment are yours either way, in your repository, to use as you see fit.
03
Five ways it can end
You choose
| Outcome | Yours either way |
|---|---|
| ProofOne use case, proved in production. | Yours either way |
| First BuildOne application, end to end, into production. | Yours either way |
| Focused EngagementThe single service the assessment surfaced. | Yours either way |
| Strategy to RunWhere the ambition spans the estate. The Diagnostic is its scoping input. | Yours either way |
| No next stepA valid outcome. | Yours either way |
The working slice, its evidence and the assessment stay in your repository whichever row you choose.
Book a Diagnostic.
A BtSavvy engineer will scope it with your engineering lead, sized to the workload you select. You leave with a working slice of it and the evidence behind it, whether or not a larger engagement follows.