One person, both halves.
The person who diagnoses the workflow is the person who builds the system. Nothing is lost in a strategy-to-developer handoff.
Build only after the value and boundaries are clear.
The work moves from diagnosis to evidence, then through explicit knowledge, data, permission, and release gates before a system reaches operation.
Strategy and implementation stay with the same accountable person throughout.
The route is rigorous because the work is real.
Nine stages in three phases. Each phase closes before the next one is allowed to start.
Find the value
Diagnosis, mapping, a value hypothesis, and a tested prototype come before any production decision.
Diagnosis before technology
Start with the costly, inefficient, or strategically important workflow. The right recommendation may be a system, an integration, a specialized tool, or not to build when the value is not there.
Map the work as it happens
Trace the workflow, recurring decisions, handoffs, knowledge sources, and available baseline before choosing technology.
Define the value hypothesis
Identify where the workflow may create commercially meaningful leverage, then measure the available baseline or establish a measurement plan.
Test before production
Build a working prototype, test it with representative users where access permits, and use the evidence to define the production recommendation.
Fix the limits
Knowledge, data, and permission boundaries are written down before the system is allowed to act.
Set knowledge and data boundaries
Define what the AI may read, what stays inside client-controlled systems, what it may draft or propose, and what remains prohibited.
Gate actions and verify results
Use explicit permissions, human approval, provenance, evaluations, and release gates. The model is never the permission system.
Hand it over
The system ships as an owned, documented, model-portable asset and is rolled out to the team.
Deliver the system as an owned asset
Deliver the logic, rules, workflows, evaluations, integration code, configuration, documentation, and repository to the client.
Keep business logic model-portable
Design the business logic so a provider change does not force a rebuild from zero. Provider changes may still require adaptation and retesting.
Put the system into operation
Deploy the validated system, document it, support basic team rollout, and expand into more roles or workflows when justified.
Sense → reason → gate → propose → approve → verify.
The gate is the center of the system: the model can reason and propose, but authority remains explicit, human, and verifiable.
- sensepermitted sources
- reasonanalysis and draft
- gatepermission boundary
- proposeproposal only
- approvehuman authority
- verifychecked and recorded
The model is never the permission system.
A visible gate separates analysis from action. A proposal waits at the boundary until a person approves it; the result is then checked and returned to the record.
Three commitments that do not move.
They hold for every engagement, whatever the workflow and whichever model provider the system uses.
You own the asset.
You receive a version-controlled repository containing the system logic, rules, workflows, evaluations, integration code, configuration, and documentation. Sensitive data, private records, credentials, and operational knowledge sources remain inside systems you control.
Governed by design.
Every system defines what AI may read, draft, or propose; what a human must approve; what remains prohibited; where important answers came from; and how actions are verified.