From uncertainty to technical clarity.
Seven stages. Each leaves a written artifact, each ends in a decision point, and each is structured so the engagement can be re-scoped without losing prior work — built for organizations adapting to fast-moving technology.
Understand
1 – 2 sessionsStudy the domain before framing the technical question.
We start by understanding the organization, the workflow, the constraints, the data environment, and the operational reality. The technology only matters if it fits the domain — and most generic AI projects fail here first.
- Domain study notes
- Environment and constraint map
- Stakeholder and user mapping
Define
3 – 5 daysConvert understanding into a written engagement.
We translate discovery into a written scope: what technical questions the engagement will answer, what it will not attempt, what artifacts will be delivered, and how decisions will be made if direction needs to change mid-flight.
- Engagement scope document
- Milestone and decision-point plan
- Data and access requirements
Investigate
1 – 2 weeks typicalResearch the technical landscape.
Before building, we research what is possible: current methods, tools, models, architectures, and implementation paths. We design the experiments — what hypotheses are we testing, and what is the smallest test that would change the recommended path?
- Technical landscape analysis
- Research plan with hypotheses
- Evaluation methodology
- Initial risk register
Prototype
1 – 6 weeksBuild the smallest thing that produces real evidence.
We construct a focused system — not a finished product — designed to test the questions defined in the research plan. Code is written to be readable and handed off, not to be a permanent codebase.
- Working prototype
- Source code and documentation
- Demo environment
Evaluate
3 – 10 daysMeasure what happened, including what failed.
We run the prototype against representative data, document performance, surface failure modes, and assess deployment readiness. The evaluation is structured to be reproducible by the client's own team.
- Quantitative evaluation report
- Failure-mode catalog
- Performance and readiness benchmarks
Document
Concurrent with buildWrite it down so the work survives.
Documentation is treated as a deliverable in its own right — not an afterthought. We produce technical references, architecture notes, and decision records that allow another engineer to pick up the work without ambiguity.
- Technical reference document
- Architecture decision records
- Operational notes (where applicable)
Recommend
1 – 2 sessionsDeliver a clear path forward.
We close with a structured handoff: a recommendation memo, a walkthrough with the client's technical team, and clear guidance on what we would and would not do next if we were the team taking it forward.
- Recommendation memo
- Live technical walkthrough
- Next-step execution roadmap
Four principles the process is built on.
Domain understanding before tooling
Most generic AI projects fail because they start with tools and look for problems. We start with the operational reality and only commit to a technical approach once the domain is understood.
Written artifacts at every stage
If a stage produces no document, it didn't happen. Each milestone leaves something the client can read, share, and use to decide.
Evaluation before optimization
We measure before tuning. Engagements that skip evaluation tend to optimize the wrong thing very efficiently.
Handoff-ready by default
Code, documentation, and architecture are written from day one as if a different team will own them — because they will.
How the research method works in practice.
Direct answers about stage artifacts, decision points, re-scoping, and how continuity is preserved across personnel.
Seven disciplined stages — Understand, Define, Investigate, Prototype, Evaluate, Document, Recommend — that move an engagement from an ambiguous brief to a defensible technical recommendation. Each stage produces written artifacts so the work survives personnel changes and pivot points.
Understand: domain study notes, environment map, stakeholder mapping. Define: scope document, milestone plan, data requirements. Investigate: technical landscape analysis, research plan, evaluation methodology. Prototype: working code, demo environment, documentation. Evaluate: benchmark report, failure-mode catalog. Document: reference document, ADRs. Recommend: memo, walkthrough, execution roadmap.
Every stage ends at an explicit decision point. The client receives the artifacts produced so far and a written recommendation on whether to proceed, redesign, or stop. Engagements are structured so pausing is a clean operation rather than a sunk-cost trap.
Yes — that is what the decision points are for. Because each stage leaves a written artifact and a recommendation, re-scoping happens without losing prior work. New scope is documented in a written amendment before further work begins.
Stage durations vary: Understand (1–2 sessions), Define (3–5 days), Investigate (1–2 weeks), Prototype (1–6 weeks), Evaluate (3–10 days), Document (concurrent with build), Recommend (1–2 sessions). End-to-end engagements typically run 2–16 weeks depending on program format.
Continuity is designed into the method. Written artifacts at every milestone mean the project never depends on a single mind in a single chair. Code, documentation, and architecture are written from day one as if a different team will inherit them — because they might.
Have a technical challenge worth investigating?
Bring us the problem. We will help determine what is possible, what is practical, and what should be built next.
Response within two business days · NDAs available when required