What Is the CRAFT Methodology?

Why CRAFT Matters

Most teams operate in one of two failure modes. Either they move slowly because every decision gets relitigated, or they move fast without shared understanding and accumulate rework debt that compounds month after month. The first mode wastes time. The second wastes money.

In the AI era, the problem gets worse. When you have access to powerful code generation and architectural tools, the speed at which you can generate wrong output is unprecedented. A team without clarity can spin up dozens of AI-assisted features in a sprint that all contradict each other. That's chaos accelerated.

The risk also stops being confined to the codebase. Once a system makes decisions on its own (routing work, drafting responses, taking actions across business systems), the questions change. What is it allowed to touch? Who can override it? What evidence proves it is still behaving inside the bounds you set? Those questions have no release date. They recur every time the model, the prompt, the data, or the business changes.

CRAFT exists because building and running systems in the AI era demands a new operating system. You need enough structure to stay coherent and make decisions stick. But you also need the structure to enable speed, not strangle it. CRAFT is designed to do both.

It answers four questions every organization building with AI must answer:

How do we maintain shared understanding as we build faster? CRAFT stores that understanding in versioned artifacts that live alongside the code.

How do we prevent the endless relitigation of decisions that kills velocity? CRAFT makes important decisions visible and reasoned. When a question comes up a second time, the reasoning is there.

How do we know the system is still behaving inside the bounds we set? CRAFT classifies risk, records where human authority sits, and gates changes on evaluations rather than confidence.

How do we know we actually solved the problem? CRAFT measures outcomes, not just outputs. Success requires evidence, not status reports.

How CRAFT Works: The Five Disciplines

Context: Build Shared Truth First

Context is the structured, versioned understanding of the product, the workflow, its users, the domain constraints, and the business goals that frame all decisions. Context is not documentation. Context is the source of truth that teams return to when choosing which opportunity to pursue, making decisions, building features, or evaluating tradeoffs.

Context starts earlier than most people expect. Before there is a product decision, there is a strategy decision: which opportunity is worth pursuing, what the current baseline is, and what the business is genuinely willing to change about how it works. Opportunity selection is a Context problem. Teams that skip it build well-governed systems nobody needed.

A Context Graph might describe: what problem the product or workflow solves, what the user's world looks like, what constraints are non-negotiable, what success means in measurable terms, what technical, operational, or business risks matter. It gets versioned. It evolves as learning happens. But crucially, it's explicit and shared.

The CRAFT principle is simple: if it's not in the Context, it's not shared truth. If Context is vague, everything downstream is a guess wrapped in confidence.

Rationale: Document Decisions Before Velocity Buries Them

Every material decision needs a record. What was decided, why, what alternatives were considered, what risks were accepted, how we'll know if it was right.

Decision Records prevent the most common source of lost velocity: relitigation. Six months in, a new engineer questions a design decision. Without a record, the team re-debates it. With a record, you read the reasoning and either agree or formally override it with documented justification.

Two decisions get recorded that teams usually leave implicit. The first is risk classification: how consequential this part of the system is, and what level of scrutiny it therefore earns. The second is human authority: which actions the system may take on its own, which require a person to approve, and who that person is. Writing those two down is what makes an AI-enabled system governable rather than merely functional.

This sounds like overhead. In practice, it's the opposite. Teams that skip this step spend far more time in Slack discussions and async back-and-forths trying to remember why something was built that way. Decision Records compress that time into a one-time cost.

Automate: Let AI Handle Scaffolding, Humans Handle Judgment

With clear context and explicit rationale, AI and tooling can execute the mechanical work. Engineers design the system. AI handles first drafts, scaffolding, repetitive implementation patterns. Human judgment stays reserved for architecture decisions, risk acceptance, and quality judgment.

Automate covers two things that are easy to confuse: the AI that helps us build, and the AI inside the system we are building, which keeps acting long after the release. Both are bounded the same way: automation is risk-proportional, and human authority is explicit. Generating a utility function earns light-touch review; letting an agent write to a system of record earns rigorous evaluation. Our Anthropic-certified practitioners design those boundaries, not just the prompts.

This discipline is not about replacing developers. It's about directing developer effort toward the work that creates real value. If an engineer is writing boilerplate by hand because no tooling exists, that's a system failure, not inevitable cost.

Fortify: Build Safety In, Not On

Fortify means nothing ships without defined quality gates. Safety, rollback capability, and reliability are designed in from the start, not bolted on at the end.

This covers testing strategy, observability, rollback patterns, and staging environments. It means understanding the blast radius of a feature before it ships to users. It means having a tested rollback path before anything ships.

For AI-enabled behavior, Fortify adds a second gate: evaluations. An evaluation suite is a set of cases with known-good answers that runs on every change to a model, prompt, tool, or permission. It is how you learn that a change made the system worse before your users do.

Fortify also defines what "working" means while the system is live. Service objectives set the reliability, latency, and cost the business is entitled to expect, plus the escalation path when the system misses them. Those objectives get written before launch, not negotiated during an incident.

The operational principle is: "It feels ready" is not an acceptable release criterion. Evidence is required.

Telemetry: Measure Intended Outcomes

Success is measured with evidence, not status reports. Did the feature solve the problem? Did adoption match the hypothesis? Did it move the metric we said we'd move? Are there unexpected side effects?

Telemetry is the feedback mechanism that closes the loop. The metrics and evidence from one cycle inform the context for the next cycle. Without it, you're shipping blind.

In production, telemetry keeps producing evidence: adoption, exception patterns, human override behavior, cost, latency, security posture, and the business measure the system exists to move. That evidence is reviewed on a schedule rather than on a hunch. Every quarterly value review identifies what operating evidence changed, what action follows, and how the next improvement will be verified. In CRAFT, continuous improvement is a governed activity, not a good intention.

The Four CRAFT Artifacts

CRAFT artifacts are not busywork documentation. Each one is a control mechanism that solves a specific problem in the system.

Intent Contract. An Intent Contract is a short, signed-off statement of the outcome, scope, success metrics, constraints, human authority boundaries and acceptance criteria. It is not a legal agreement; commercial terms live in the engagement agreement. It is agreed before work begins, and it answers: What are we building? What counts as done? How will we measure it? What's out of scope? Who decides what the system is allowed to do? It's the North Star that guides all downstream decisions.

Decision Record documents important technical and operational decisions: the choice made, why it was made, what alternatives were considered, what risks were accepted, how we'll know if it was right. It prevents relitigation and creates organizational memory.

Context Graph is the versioned source of truth. It captures the product and workflow landscape, domain knowledge, technical constraints, business context, and assumptions that shape the system. It evolves as learning happens but remains explicit and structured, and the operating team keeps maintaining it after launch.

Telemetry Ledger tracks outcome metrics and operational signals. It answers the question: Did we achieve what we intended? It feeds learning back into the next cycle, and it is the evidence base the quarterly value review works from.

These artifacts live alongside the code. They're not a separate documentation silo. They're part of how the team works, and they're what you keep. When an engagement changes shape, the artifacts are the reason the next cycle starts with context instead of archaeology.

What CRAFT Measures

The primary delivery metric is Time to Verified Value. The time from an approved Intent Contract to an agreed outcome being verified in production. Not story points. Not features shipped. Not tokens generated.

That choice is deliberate. The metric can only be reported if the whole loop worked: intent was clear enough to approve, decisions were recorded, the system was fortified enough to ship safely, and telemetry could actually prove the outcome moved. It cannot be gamed by shipping more.

Two companion measures cover the rest of the lifecycle. Assessment work is measured by Time to Buildable Decision, from assessment kickoff to an approved Intent Contract. Once the system is running in production, the operate measure is Time to Next Verified Improvement: how quickly evidence from the live system turns into a verified improvement to the business outcome. Supporting measures sit underneath all three: quality and reliability, adoption, human override behavior, cost and latency, and security and governance.

How CRAFT Shows Up Across the Lifecycle

Consider a full cycle with CRAFT in place.

It starts before the product decision. An assessment establishes the baseline, maps the workflow as it actually runs, classifies risk, and produces an opportunity map. The output is a decision about what is worth building, not a deck.

The Intent Contract comes out of that assessment and usually takes days, not weeks. The Product Delivery Lead writes it with the client's accountable owner. A Product Delivery Lead is accountable for the outcome, managing intent, milestones, and the rhythm of delivery across the engagement. The Intent Contract states the outcome, scope, success metrics, constraints (latency, cost, compliance, backwards compatibility), human authority boundaries and acceptance criteria.

Design covers the human system and the technical one together. If the point of the work is that people do something differently, the workflow redesign is part of the design, not a change-management afterthought.

The engineering lead uses the Context Graph to understand the current system landscape, existing patterns, and technical debt that might affect this work. A senior engineer documents the key decision in a Decision Record: why this approach over alternatives, and what risks it accepts. With that intent and rationale in place, AI-assisted tooling generates scaffolding and first drafts, and engineers review, modify, and build on top. The structure is clear enough that review and override are fast.

Testing, rollback patterns, evaluation suites, and service objectives are defined upfront as part of Fortify. The team knows how it will validate the system before it touches users, and how to roll back if something breaks. Once shipped, the Telemetry Ledger captures whether the work achieved its intended outcome, and Time to Verified Value is reported against the agreed measure.

Then operation begins. Launch is not where our responsibility ends; it is where running the system begins. The system runs against its service objectives, the AI runs against its evaluations, and production evidence flows back into the Context Graph. The quarterly value review turns that evidence into the next decision, measured by Time to Next Verified Improvement. That evidence becomes the Context for the next cycle. The loop doesn't end at launch. It changes the question it's asking.

Key Takeaways

CRAFT is a systematic approach to governing software and AI in the AI era. It's not a rigid waterfall process. It's a continuous control loop where clarity, reasoning, bounded automation, safety, and evidence guide every cycle, from the first opportunity conversation through the improvement that ships two years after launch.

The core principles are reversible: Context can be updated as learning happens. Decisions can be formally revisited. Architecture can be refactored as constraints change. Authority boundaries can be widened or narrowed as evidence accumulates. But all changes remain visible and reasoned.

CRAFT scales. On a single team, it reduces waste within that team's work. Applied across multiple teams and into operations, it gives an organization something more valuable: the ability to share context, learn from decisions across projects, and compound learning over time instead of restarting it at every handoff.

It requires discipline. Documenting intent takes time. Writing Decision Records is uncomfortable at first. But the time saved in prevented relitigation and rework compounds quickly.

The result is faster delivery with lower rework, decisions that stay decided, AI behavior that stays inside bounds a person set on purpose, and measurable outcomes instead of guesses.