How the Engine works.
The Capability Engine is the platform behind every Capability Factory engagement. It does the analytical and mechanical labor — elicitation, modeling, code generation, integration, integrity checking — that used to require a team of five-to-ten. The architect uses it. The architect makes the calls. Here's what it does, how it works, and where it sits.
01 · 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, which are duplicates, which need merging, which are out of scope.
- Capability derivation.
- The Engine derives capabilities 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.
- Traceability 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.
- Persistence.
- The Engine holds the client's capability model live between engagements. When a new problem surfaces six weeks or six months after the last sprint, the problem register, capability model, outcome tracking, and ROI measurements are already in place. The next engagement extends rather than restarts.
02 · How the Engine works.
Every function the Engine performs is in service of a judgment the architect has to make. The Engine handles the analytical labor; the architect handles the calls.
ON DIVISION OF LABOR
The senior architect makes the calls. The Engine handles the analytical labor that supports them.
The architect's role.
Interprets the signals. Decides what's a problem and what isn't. Derives capabilities. Judges tradeoffs. Owns outcomes. The architect is accountable to the client.
The Engine's role.
Does the analytical work that supports the architect: extraction, clustering, structuring, connection maintenance, artifact assembly, persistence. The Engine surfaces, organizes, and produces. It does not recommend, determine, or decide.
03 · Two modes.
Every engagement runs in one of two modes. The choice is about how the client wants to work — not about the quality of the output.
Direct mode · the default
- 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
Standard mode · the alternative
- The architect runs the Engine on the client's behalf
- The client receives the same artifacts as documents, dashboards, presentations
- Same commitment-grade outputs as Direct mode
- Useful for buyers who prefer not to engage with the platform directly
The Engine is how the work gets produced. It is not a prerequisite for the work to be valuable. Both modes deliver the same commitment-grade outputs; the choice is about how the client wants to work.
THE COMMITMENT-GRADE ANALYTICAL PACKAGE
04 · 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, with bidirectional traceability. |
| Outcome qualification | The list of outcomes the client commits to, each with a measurable target, a baseline, and a measurement approach. |
| Traceability model | The connection map — every problem 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 post-go-live measurement plan — lagging measurables, leading indicators, baselines, review triggers, measurement owners. |
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.
05 · 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
The Capability Engine
- Architect
- Signal extraction
- Clustering
- Capability derivation
- Traceability layer
- Artifact production
- Persistence
Capability outputs
- Cash position dashboard
- Close pack reconciliation
- Forecast pipeline
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. When the engagement ends, the capability runs on the client's infrastructure. The Engine moves on; the capability stays.
ON THE ENGINE
Capability Factory is new. The Engine is the practice — drawn from twenty years of doing this work inside larger consultancies — packaged so a single senior architect can deliver it under one name. The first engagements will run on the Engine described here, with the client's business in the middle band.