From intent to a running system

As AI makes software easier to build, the question of what you actually want, and within which responsibilities and limits, matters more than ever. CaseFlows starts with that question, captures the answer in an open specification, and runs that specification directly.

The bottleneck has moved

The gap between business and IT is old. Requirements, agile teams, product owners and low-code made it smaller, but the translation step remained: someone says what is needed, someone else turns it into software.

A code assistant now writes working code in little time. That moves the scarcity to intent: which outcome, for whom, with which responsibilities and within which limits. Gartner, too, calls specifications the main control point in AI-assisted development: whoever doesn't own the intent leaves control to the development process or to the AI.

That knowledge sits with the people who do the work. A planner knows how planning works. A permit officer knows what weighs in an application.

%%{init: {"theme":"base","themeVariables":{"primaryColor":"#FFFBF3","primaryBorderColor":"#211D18","primaryTextColor":"#211D18","lineColor":"#211D18","secondaryColor":"#FCE3D2","secondaryBorderColor":"#EC6A22","tertiaryColor":"#ffffff","tertiaryBorderColor":"#D9CFBE","clusterBkg":"#F5EFE4","clusterBorder":"#D9CFBE","fontFamily":"Instrument Sans, system-ui, sans-serif","fontSize":"15px"},"flowchart":{"padding":18,"nodeSpacing":40,"rankSpacing":45}}}%%
flowchart TB
  subgraph before["Before"]
    direction LR
    W1["What we want"] --> T1["Translation<br/>analyst, developer"] --> C1["Code"]
  end
  subgraph now["Now"]
    direction LR
    W2["What we want"] --> T2["Specification"] --> C2["AI builds"]
  end
  before ~~~ now
  classDef scarce fill:#FCE3D2,stroke:#EC6A22,stroke-width:2px
  class C1,W2 scarce

Scroll sideways to see the whole diagram.

Three layers, each with its own owner

Intent. Why does this process exist, and which outcome counts? In plain language, deliberately incomplete.
Specification. The case, the caseflow, the case roles, what each role can see and do in each phase, and which services are used. Precise and readable: JSON for structure, markdown for behaviour.
Execution. What happens in a real case, done by people, systems and agents.

%%{init: {"theme":"base","themeVariables":{"primaryColor":"#FFFBF3","primaryBorderColor":"#211D18","primaryTextColor":"#211D18","lineColor":"#211D18","secondaryColor":"#FCE3D2","secondaryBorderColor":"#EC6A22","tertiaryColor":"#ffffff","tertiaryBorderColor":"#D9CFBE","clusterBkg":"#F5EFE4","clusterBorder":"#D9CFBE","fontFamily":"Instrument Sans, system-ui, sans-serif","fontSize":"15px"},"flowchart":{"padding":18,"nodeSpacing":40,"rankSpacing":45}}}%%
flowchart TB
  I["Intent<br/>why, and which outcome counts"] --> S["Specification<br/>case, caseflow, case roles, rights"] --> X["Execution<br/>people, systems and agents in real cases"]
  X -. signals .-> I
  X -. signals .-> S

Scroll sideways to see the whole diagram.

Describe, build, experience, adjust

Whoever knows the work describes it in a conversation with the CaseFlows coach. The coach asks where something isn't clear yet and turns it into the specification. During the conversation a model appears that you can look at: which phases, which roles, where responsibility shifts.

Then you start a test case and take the role of customer, planner or assessor yourself. What doesn't feel right, you say, and the next round starts.

%%{init: {"theme":"base","themeVariables":{"primaryColor":"#FFFBF3","primaryBorderColor":"#211D18","primaryTextColor":"#211D18","lineColor":"#211D18","secondaryColor":"#FCE3D2","secondaryBorderColor":"#EC6A22","tertiaryColor":"#ffffff","tertiaryBorderColor":"#D9CFBE","clusterBkg":"#F5EFE4","clusterBorder":"#D9CFBE","fontFamily":"Instrument Sans, system-ui, sans-serif","fontSize":"15px"},"flowchart":{"padding":18,"nodeSpacing":40,"rankSpacing":45}}}%%
flowchart LR
  D["Describe<br/>with the coach"] --> B["Build<br/>specification and screens"] --> E["Experience<br/>a test case, in a role"] --> A["Adjust"] --> D

Scroll sideways to see the whole diagram.

The specification isn't translated, it is run

This is where CaseFlows differs from spec-driven development as the market usually means it. There, the specification is an assignment for an agent that writes code, and afterwards the code can drift away from the specification.

In CaseFlows the runtime runs the specification itself. Which phases a case goes through, what each role can see and do, which checks are required: that is in the spec, and the server enforces it while the case runs. Change the spec and the behaviour changes. There is no second truth that can fall behind.

To be precise about the line: the runtime executes the caseflow directly, with its phases, roles, permissions, checks and the services it calls. The screens people work in are code: a code assistant builds them from the page specification, and every change is measured against the spec again. AI does a lot in development; in production, an agent works only within a case role.

%%{init: {"theme":"base","themeVariables":{"primaryColor":"#FFFBF3","primaryBorderColor":"#211D18","primaryTextColor":"#211D18","lineColor":"#211D18","secondaryColor":"#FCE3D2","secondaryBorderColor":"#EC6A22","tertiaryColor":"#ffffff","tertiaryBorderColor":"#D9CFBE","clusterBkg":"#F5EFE4","clusterBorder":"#D9CFBE","fontFamily":"Instrument Sans, system-ui, sans-serif","fontSize":"15px"},"flowchart":{"padding":18,"nodeSpacing":40,"rankSpacing":45}}}%%
flowchart TB
  subgraph usual["Usual spec-driven development"]
    direction LR
    S1["Spec"] --> A1["Agent writes code"] --> C1["Code runs"]
    C1 -. drifts .-> S1
  end
  subgraph cf["CaseFlows"]
    direction LR
    S2["Spec"] --> R2["Runtime runs it<br/>and enforces it"]
    UI["Screens"] -. measured against .-> S2
  end
  usual ~~~ cf

Scroll sideways to see the whole diagram.

A spec that is yours

Because the specification is the system, whoever owns the specification owns the system. That is why the formats are open: readable without CaseFlows, and portable as ordinary files.

And because the intent stays separate, a problem can be traced to the right layer: the execution, the specification, or the intent itself. How that works in practice is the next deep dive.

Next: an organisation that learns

How what people run into in real cases becomes a signal that can change the process — for employees and for partners.

Read on →