Skip to content
Is2Be

The principles of the method

Is2Be (from as-is to to-be, with AI) is two independent methodologies that chain together: Evidence-First for business processes (Is2Be Process) and Spec-First for software (Is2Be Software). They work with any AI assistant: the prompts are plain text, with nothing proprietary.

The AI prepares, synthesizes, models, compares, generates and documents. It doesn’t interview anyone, doesn’t observe the real work and doesn’t decide. Every phase ends with a human approval gate: whoever is accountable approves before moving on, and any conditions attached are recorded.

Nothing is taken for granted. Every statement about how a process or system works today carries its source. Anything unverified is marked as an assumption and becomes a question for the business. Contradictions between sources (what the procedure says versus what people actually do) are findings, not mistakes to hide.

In software, the specification is generated and validated before any code is written: requirements, architecture, decisions (ADRs), build plan and test plan. Tests are written with every module, not at the end.

No activity that adds no value gets automated: first it is removed, merged or simplified. Technology comes afterwards, on top of a clean process.

Every hard-to-reverse decision is recorded with its options, criteria and consequences: a PDR (Process Decision Record) for processes and an ADR (Architecture Decision Record) for software.

A sentence from an interview can be followed all the way to a software test: evidence → discrepancy → problem → root cause → requirement → decision → business rule → process activity → software requirement → test.

If the redesigned process needs software, the last piece of Evidence-First (the briefing) is the input to Spec-First. What the business approved reaches the development team intact.