How the Engine works.
The Capability Engine is our AI software factory, the technology behind every Capability Factory engagement. It does the labor that used to require a team of five to ten. It scopes and models the work, then builds, tests, releases and maintains the software. It builds from the spec: the architect's written description of the software, drawn from your scenarios, your team's descriptions of how the work should run. The architect uses it. The architect makes the calls. Here's what it does, how it works, and where it sits.
What the Engine does.
- Signal extraction.
- The Engine reads the inputs the client brings to scoping — meeting transcripts, documents, screenshots, system exports, written context, conversation recordings. It extracts the embedded signals: the actual problems, the artifacts referenced, the workflows described, the constraints implied. AI-assisted extraction at a scale that would otherwise require a team of analysts.
- Clustering and structuring.
- Related signals are clustered into candidate problems and structured for review. The architect makes the calls about which clusters become problems in the register, the list of named problems, which are duplicates, which need merging, which are out of scope.
- Capability derivation.
- The Engine derives capabilities, the things the business will be able to do, bottom-up from problems and top-down from named outcomes. The two directions meet at the capability layer. Capabilities that show up in both directions are high-confidence candidates. The architect resolves conflicts and selects what makes the register.
- Connection maintenance.
- Every signal traces to a problem, every problem to a capability, every capability to a named outcome with a measurable target. The Engine keeps the chain consistent as the architect adjusts the model — adding a problem mid-scope, refining an outcome target, splitting a capability.
- Artifact production.
- The Engine assembles, formats, keeps, and revises the named deliverables of the method. The architect drives; the Engine produces. The full artifact list is in section 4.
- Building from the spec.
- The Engine generates the software from the spec the architect writes from your scenarios: the data model, the workflow, the interface, and the connections to the systems you already run.
- Testing against your scenarios.
- Every build is tested automatically against the scenarios your team wrote in Scoping, before the architect accepts it.
- Release.
- Accepted builds are released to your environment by the Engine. No deployment project.
- Maintenance by rebuild.
- On Continuous Fit, our monthly service after launch, the spec changes when the business does. The Engine rebuilds, retests and re-releases. It monitors what it released. No code is maintained by hand.
- Persistence.
- The Engine holds the client's capability model, the linked record of problems, capabilities and outcomes, live between engagements. When a new problem surfaces six weeks or six months after the build ends, the problem register, capability model, outcome tracking, and ROI measurements are already in place. The next engagement extends rather than restarts.
How the Engine works.
Every function the Engine performs is in service of a judgment the architect has to make. The Engine handles the labor; the architect handles the calls.
The architect's role.
Interprets the signals. Decides what's a problem and what isn't. Crafts the capabilities. Turns your scenarios into the spec. Judges tradeoffs. Accepts what ships. Owns outcomes. The architect is accountable to the client.
The Engine's role.
Does the labor that supports the architect: extraction, clustering, structuring, connection maintenance, artifact assembly and persistence, then building, testing, release and maintenance from the spec. The Engine surfaces, organizes, builds and runs. It does not recommend, determine, or decide.
On division of labor The senior architect makes the calls. The Engine handles the labor that supports them.
Two modes.
Scoping runs in one of two modes. The choice is about how the client wants to work — not about the quality of the output.
- Leadership defines outcomes interactively, inside the Engine, alongside the architect
- Operational stakeholders contribute signals and problems from inside their own systems
- The architect refines the model as new information surfaces
- Role-based access controls what leadership, operators, and architects see
- The architect runs the Engine on the client's behalf
- The client receives the same artifacts as documents, dashboards, presentations
- Same outputs as Direct mode
- Useful for buyers who prefer not to engage with the Engine directly
The modes differ only in how you work with the Engine during Scoping. Both deliver the same outputs, and the Engine builds from the same spec either way.
What the Engine produces.
| Artifact | What it is |
|---|---|
| Problem register | The structured list of problems surfaced during discovery, with metadata (source, severity, frequency, who's affected). |
| Capability register | The list of capabilities derived from problems and outcomes, linked in both directions. |
| Scenarios | The behavioral requirements, written in your team's words and traced to outcomes. The spec the Engine builds from, and the tests every build has to pass. |
| Outcome qualification | The list of outcomes the client commits to, each with a measurable target, a baseline, and a measurement approach. |
| Connection map | Every problem linked to a capability, every capability to an outcome. The structural backbone of the method. |
| ROI model | The financial impact of each capability, tied to the outcome it produces. |
| Phase plan | The sequencing of capability builds across phases, with timing and dependencies. |
| Phase diagram | The visual representation of the phase plan. |
| Points rollup | The sprint-points estimation that drives commercial terms. |
| Benefit Realization Plan | The plan for measuring the outcome after go-live: its baseline, the early signs we watch, who measures, and the trigger, the number at which we stop and review. |
Every artifact is a named deliverable. A client completing scoping leaves with the full set — a document they could take into any consulting engagement and have the firm commit against.
Where the Engine sits.
The Engine occupies the middle band — between the systems the client already runs and the capabilities the engagement produces.
Client systems
- System of record
- CRM
- GL
- Bank feeds
- Inventory
Client owns
The Capability Engine
- Architect
- Signal extraction
- Clustering
- Capability derivation
- Connection map
- Artifact production
- Build, test and release
- Rebuild from the spec
- Persistence
Capability Factory runs
Capability outputs
- Cash position dashboard
- Close pack reconciliation
- Forecast pipeline
Client owns
The Engine sits between the systems the client already runs and the capabilities the engagement produces. It does not replace either. The middle band is where the architect works; the bands on either side stay the client's. The capability runs on the client's infrastructure. On Continuous Fit, the spec changes and the Engine rebuilds. The capability, its specs and its code stay yours either way.
Capability Factory is new. The Engine is the practice, drawn from years of doing this work inside larger consultancies. It is packaged so a named senior architect can deliver it, with the Engine doing the labor. The first engagements will run on the Engine described here, with the client's business in the middle band.