How Clarity Fits — Clarity Framework

Clarity is a reasoning layer. Clarity is a framework for making beliefs, assumptions, evidence, confidence, ownership, and reassessment explicit so people can adapt when reality changes.

You do not replace your existing framework with Clarity. You use Clarity to improve how your existing framework reasons, adapts, and learns.

What Other Frameworks Do

Agile

Agile helps teams deliver value iteratively.

Scrum

Scrum helps teams coordinate work.

Kanban

Kanban helps teams visualize and improve flow.

Lean

Lean helps teams reduce waste and improve systems.

Six Sigma

Six Sigma helps teams reduce variation and defects.

Architecture Review

Architecture review helps teams evaluate technical design.

Product Discovery

Product discovery helps teams explore customer needs.

These frameworks are valuable. Clarity does not compete with them.

What Clarity Adds

What do we believe?

Why do we believe it?

What evidence supports it?

What assumptions are we treating as facts?

How confident should we be?

What would change our minds?

Who owns the consequences?

When should we reassess?

Where Clarity Fits Among Other Frameworks

Different frameworks answer different kinds of questions. Clarity is not intended to replace Agile, Scrum, Kanban, Lean, Six Sigma, Cynefin, OODA, systems thinking, architecture review, or product discovery. It adds a reasoning layer underneath them by making beliefs, assumptions, evidence, confidence, ownership, and reassessment explicit.

Framework	Primary Focus	Main Question	Where Clarity Fits
Agile	Iterative delivery	How do we deliver value incrementally?	Tests the beliefs behind backlog choices, priorities, and product assumptions.
Scrum	Team coordination	How do we organize and inspect work?	Clarifies the claims behind sprint goals, priorities, and commitments.
Kanban	Flow and visibility	How does work move through the system?	Examines beliefs about bottlenecks, constraints, and flow problems.
Lean	Waste reduction and flow	Where is waste, and how do we improve the system?	Tests assumptions about what is actually waste and what changes will improve flow.
Six Sigma	Variation and defects	What causes variation, defects, or quality problems?	Challenges assumptions behind root-cause claims and confidence in evidence.
Cynefin	Problem context	What kind of situation are we in?	Examines the claims and evidence used to classify the situation.
OODA	Rapid adaptation	How do we observe, orient, decide, and act quickly?	Strengthens orientation by making beliefs, assumptions, and reassessment triggers explicit.
Systems Thinking	Interactions, feedback loops, and system behavior	What system is producing this behavior?	Makes beliefs about the system visible and testable.
Architecture Review	Technical design	Is this design appropriate for the constraints?	Evaluates the claims, assumptions, evidence, and failure conditions behind the design.
Product Discovery	Customer and market learning	What do customers need, and what should we build?	Separates customer evidence from assumptions and defines what would change our minds.
Clarity	Belief management and adaptation	What do we believe, why do we believe it, and when should we reassess?	Provides the underlying reasoning layer for claims, evidence, assumptions, confidence, ownership, and reassessment.

Agile Example

Scenario: A Scrum team adds Feature X to the backlog.

Agile helps the team plan, prioritize, build, review, and iterate.

Clarity asks

What evidence suggests customers want Feature X?
What assumptions support that belief?
What would tell us the feature is not valuable?
What trigger would cause us to reassess?

Agile manages execution. Clarity improves reasoning.

Architecture Example

Scenario: A team proposes moving to microservices.

Architecture review helps evaluate system design.

Clarity asks

What problem are microservices expected to solve?
What evidence supports that expectation?
What assumptions are being made?
What happens if the claim is wrong?
What would trigger reassessment?

Architecture review evaluates design. Clarity evaluates the beliefs driving the design.

Postmortem Example

Scenario: A team concludes that testing caused a major delivery delay.

Clarity asks

What evidence supports that claim?
What evidence contradicts it?
Are we treating assumptions as facts?
What should have triggered reassessment earlier?

Postmortems explain what happened. Clarity helps test whether the explanation is true.

The Practical Difference

Most frameworks help teams decide how to work, how to deliver, how to improve flow, or how to understand complexity. Clarity focuses on the beliefs underneath those activities.

A team can use Agile and still have weak assumptions.

A team can use Lean and still misidentify waste.

A team can use architecture review and still overstate confidence.

A team can run postmortems and still accept the wrong explanation.

Clarity helps surface those reasoning gaps.

The Clarity Layer

Strategy ↓ Clarity ↓ Agile / Scrum / Kanban / Lean / Architecture / Product Discovery ↓ Execution

Clarity sits between intent and execution. It helps make sure the beliefs driving the work are visible, testable, and adaptable.

Use What You Already Have

Clarity is designed to work with the frameworks an organization already uses. It does not ask teams to abandon their operating model. It helps them examine the claims driving that model, the evidence behind those claims, and the triggers that should cause reassessment.

Why This Matters

Many organizations do not fail because they lack process.

Assumptions become invisible.

Confidence exceeds evidence.

Ownership becomes unclear.

Reassessment never happens.

Teams continue acting on beliefs that no longer match reality.

Clarity exists to make those conditions visible.

The goal of Clarity is not to make perfect decisions.

The goal is to help people recognize when reality has changed enough to require reassessment and adaptation.