Duonaut — homePL

The requirements loop — from a client conversation to a working solution

REQLOOP

A system that turns a recorded client conversation into a working solution — a website, an automation or an agent. It guides requirements through eight stages and four loops until every measurable completion criterion is met.

Before

Requirements are undocumented, contradictory and shift mid-project, while the build quietly drifts away from what was agreed.

After

Every requirement is traceable all the way to the solution, and every change passes through the loop before it reaches the build.

Where the name comes from

Requirements Loop — requirements in a continuous loop.

In a typical project, requirements are written down once, at the start. Then the company changes, new ideas and comments emerge, and the original document falls out of step with reality. The solution being built begins to diverge from what the company actually needs.

REQLOOP works differently. Every new conversation, change or comment returns to the loop. The system compares it with what has already been agreed: what it changes, what it contradicts and which parts of the solution need to be updated as a result. Only then does the change reach the build.

We also keep to a simple sequence: first we establish what the company needs, and only then do we decide how to build it. The client approves the requirements, and they are the reference point for everything that is produced. Every addition along the way goes through the client, and every change is made with the client’s knowledge.

How it works

From a conversation to a working solution.

Eight stages in three sections. In each section, one party creates and another checks independently — a machine or a person.

  1. 01what and why

    Discovery

    Establishes what the client needs and leaves all design for later. It records only what was actually said, flagging gaps and turning them into questions.

    1. 01Requirements extraction from the recording
    2. 02Fidelity audit against the conversation
    3. 03Merging answers and changes

  2. 02how

    Design

    Decides what to build and with what, and sets a measurable definition of done. A person approves every architectural decision.

    1. 04Solution architecture
    2. 05Loop scenario and completion gates

  3. 03execution

    Build

    Builds iteration by iteration until every gate passes. It works only from the agreed requirements and keeps the bar exactly where it was set, right to the finish.

    1. 06Iteration build
    2. 07Independent gate verification
    3. 08Loop control

Four loops

Every loop knows when to stop.

It ends with a finished result or by handing the decision to a person. Every loop has a defined end and declares success only once the goal has been reached.

  1. 01 · machine ↔ machine

    Fidelity loop

    Extraction and an independent audit exchange feedback until the requirements faithfully reflect the conversation. Three rounds at most — then a person decides.

  2. 02 · person ↔ client

    Completeness loop

    Open questions go to the client, and the answers return to the specification and are audited again — until every critical gap is closed.

  3. 03 · machine + human gates

    Build loop

    Build, verification and control, iteration after iteration, until every gate passes. Three failures of the same gate trigger escalation or a return to design.

  4. 04 · client · outer ring

    Acceptance loop

    Client feedback after the presentation always returns as a change to the requirements and reaches the code only through them. The loops run again — informed by the new knowledge.

Gates

Gates as the foundation of an effective loop.

A gate is a specific condition that can be checked: met or not met. The client approves the list of gates before the build starts, and the solution is ready once it meets all of them.

  • AUTO

    Checked automatically

    These conditions are checked by a machine, based on evidence of how the solution actually behaves. The check is performed by a different model from the one that built it, so every piece of work is assessed independently.

  • HUMAN

    Checked by a person

    Where human judgement is needed — for example, whether the solution is easy for the team to use — work pauses and waits for a decision. We group these moments together so that people can stay focused on their own work.

Artefacts

Traceability from requirement to working solution.

Every element has a permanent identifier that stays the same throughout. Every part of the solution can be traced back to the client’s requirement.

artefacts / trace

  1. REQ-014Client requirement
  2. ARCH-03Architectural decision
  3. GATE-07Completion gate
  4. ITER-2Build iteration
  5. ✓Working solution

Requirement change

  • REQ-014SUPERSEDEDreplaced, kept in history
  • REQ-031ACTIVEnew version of the requirement
  • ARCH-03STALEdecision due for review
  • GATE-07STALEgate due for review

build paused until the trace is clean

A change is a new version

A changed requirement is recorded as a new one, and the previous version stays in the history — so it is clear what changed, when and why.

Protection against drift

Everything that followed from the changed requirement is flagged for review. The build resumes once every dependent decision and gate has been revisited.

Human in the loop

Five moments when a person decides.

  • 01StartThe recording of the client conversation sets the whole process in motion.
  • 02After discoveryAcceptance of the requirements and answers to the open questions that close the gaps.
  • 03After architectureApproval or rejection of each architectural decision individually.
  • 04Before the buildSign-off on the definition of done, that is, the full set of gates. The build starts once it is signed.
  • 05During and after the buildAssessment of the human gates and presentation of the finished solution. Between these moments, the system works on its own.

Why

The problem it solves

Requirements are a classic breaking point in IT projects. They often go undocumented because “everyone knows what is needed”. They can be contradictory because each department describes the same process differently. And they change along the way, because only a working solution reveals what is really needed.

The technology usually holds up. The weak point is the path from conversation to build: agreements get lost along the way, changes go straight into the code, and the solution quietly drifts away from what was agreed. REQLOOP structures this path as loops with a measurable end, so that gaps and contradictions surface at the requirements stage, well before production.

Where it is used

REQLOOP is used in the AI readiness audit and in pilot preparation. Together with Automatic Workshop Analyser, it carries a project from process discovery, through requirements, to a working solution.

The division of work is simple: the system extracts the requirements, checks them and builds, while a person approves everything that calls for a decision. The client receives the results of this work — approved requirements, an agreed definition of done and a working solution — while the tool itself stays with us.

What it means for the organisation

The organisation receives requirements it can read, verify and approve before paying for the build — and a definition of done it signs off before the build begins.

A solution built on this foundation is also easier to maintain and develop. Every part of it can be traced to the requirement it comes from, so every later change has a clear reference point.

What it means for the client

The company receives exactly what it agreed and knows from the outset how it will recognise that the solution is ready.
The build stays on course when the company changes its mind mid-project — the change passes through the loop and reaches the solution in an orderly way.

Other systems

Let’s talk.

30 minutes · no slides · no commitment

Book a callBoard sessionAI readiness audit
info@duonaut.com