What Is the CRAFT Methodology?

The methodology is organized around five disciplines: Context, Rationale, Automate, Fortify, and Telemetry. Each discipline serves a specific purpose in the delivery system. Together, they form a feedback loop where learning from one cycle feeds directly into the next.

Why CRAFT Matters

Most product 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.

CRAFT exists because building 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 three questions every product engineering team 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 re-litigation 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 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, 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 making decisions, building features, or evaluating trade-offs.

A Context Graph might describe: what problem the product solves, what the user's world looks like, what constraints are non-negotiable, what success means in measurable terms, what technical 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: re-litigation. 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.

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.

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 knowing how to get out of a bad deploy in under 5 minutes.

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.

The Four CRAFT Artifacts

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

Intent Contract defines the outcome, scope, success metrics, constraints, and acceptance criteria before work begins. It answers: What are we building? What counts as done? How will we measure it? What's out of scope? It's the North Star that guides all downstream decisions.

Decision Record documents important technical 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 re-litigation and creates organizational memory.

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

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.

These artifacts live alongside the code. They're not a separate documentation silo. They're part of how the team works.

How CRAFT Shows Up in Delivery

Consider a typical feature delivery with CRAFT in place. A product manager and engineering lead work together to write an Intent Contract. It specifies the user problem, the proposed solution, the success metric (time to value, user adoption, metric movement), constraints (latency, cost, backwards compatibility), and the definition of done.

The engineering lead uses the Context Graph to understand the current system landscape, existing patterns, and technical debt that might affect this feature. The team identifies which subsystems need modification.

The team sketches the architecture. A senior engineer documents the key decision: why this approach over alternatives, what risks it accepts. This goes into a Decision Record.

With clear intent and documented rationale, an AI-assisted development tool generates scaffolding and first drafts. Engineers review, modify, and build on top. The structure is clear enough that review and override are fast.

Testing and rollback patterns are defined upfront as part of Fortify. The team knows how they'll validate the feature before it touches users, and they have a clear plan to roll back if something breaks.

Once shipped, the Telemetry Ledger captures whether the feature achieved its intended outcome. That evidence becomes part of the Context for the next cycle.

Key Takeaways

CRAFT is a systematic approach to building products in the AI era. It's not a rigid waterfall process. It's a continuous control loop where clarity, reasoning, automation, safety, and evidence guide every cycle.

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

CRAFT scales. Individual teams use it to reduce waste within their own work. Organizations that adopt CRAFT across multiple teams gain something more valuable: the ability to share context, learn from decisions across projects, and compound learning over time.

It requires discipline. Documenting intent takes time. Writing decision records is uncomfortable at first. But the time saved in prevented re-litigation and rework compounds quickly.

The result is faster delivery with lower rework, clearer reasoning visible to the whole team, and measurable outcomes instead of guesses.

Frequently Asked Questions

Q: Isn't CRAFT just adding more documentation overhead?

CRAFT is not about documenting everything. It's about documenting the decisions that matter: intent, important architectural choices, and outcomes. In practice, teams that adopt CRAFT spend less time in async discussions and re-debates because the reasoning is visible. The time saved in prevented re-litigation exceeds the time spent capturing context and decisions.

Q: Can CRAFT work for small teams?

Yes. CRAFT scales down. A small team working on a single feature still benefits from a clear Intent Contract and from documenting why the architecture was chosen that way. The artifacts get smaller, but the discipline remains the same. The smallest implementation is still more valuable than no shared understanding at all.

Q: Does CRAFT require special tools?

CRAFT does not mandate specific tools. An Intent Contract can live in a Notion database or a GitHub markdown file. Decision Records can be stored in a wiki or in a subdirectory of the repo. The key is that these artifacts are version-controlled and treated as part of the system, not separate documentation. That said, tools that make it easier to author, version, and search these artifacts reduce friction.

Q: How is CRAFT different from Agile or Scrum?

Agile and Scrum are frameworks for organizing work and cadence. CRAFT is a delivery discipline that specifies what clarity must exist before work begins, how decisions are made and recorded, how automation is directed, and how outcomes are measured. CRAFT can be used within an Agile framework. Many teams running Scrum sprints have adopted CRAFT to improve the quality of what gets built within each sprint.

Q: What happens if we skip the Context Graph or Decision Records?

You lose the feedback loop. Without documented context, every team member carries their own mental model. Without decision records, you re-litigate the same choices repeatedly. Without fortification discipline, features go out without clear safety gates. Without telemetry, you don't know if you actually solved the problem. Each artifact serves a purpose. Skipping any of them makes the system work harder downstream.

Q: How long does it take to adopt CRAFT?

Most teams see benefit in the first cycle. Intent Contracts clarify scope and reduce rework. Decision Records create organizational memory immediately. The compound benefit grows over time as learning from telemetry feeds back into future context and decisions. Full adoption across an organization typically takes 2-3 quarters, but individual teams can adopt it in days.