Project IRIS
An adaptive interview that turns a vague business request into a structured brief, then builds a working clickable prototype from it, so the first meeting has something real to react to. A redesign, not a retrofit: turn the AI off and this process does not run slower, it does not run at all.
Business requests arrive as a sentence in a meeting or a paragraph in a chat. Two requests for the same underlying thing look nothing alike, so nothing can be compared or ranked, and the loudest stakeholder wins.
Discovery took about four weeks of workshops, write-ups and clarification rounds before anyone saw anything concrete. Feedback that could have changed the idea arrived after the idea was already fixed. The goal was to halve that.
A form gives you comparable answers and shallow ones, because it does not follow what the person actually said. A free conversation goes deep but produces something you cannot line up against anything else. The question was whether one system could do both.
- 01InterviewOne question at a time, each chosen from what has been said, not from a script.
- 02CompletenessUnderstanding is scored per dimension (problem, context, requirements), not by questions answered.
- 03GateSynthesis will not trigger until the load-bearing dimensions each clear a floor.
- 04BriefStructured output, shareable by link, and directly comparable against every other brief.
- 05PrototypeA self-contained clickable page built from the brief, opened in a headless browser and checked before anyone sees it.
- 06PipelineBriefs move through stages with scoring attached, so triage runs on evidence, not volume.
An adaptive interviewer will confidently produce fiction
Ask a model to synthesise a specification and it will always produce one: fluent, structured, complete-looking, and invented wherever the conversation was thin. The gate exists because of this: without a floor on problem, context and core requirements, any spec it writes is fiction, and a fluent fiction is far more dangerous than an obviously empty form.
The prototype narrowed the conversation instead of opening it
A clickable page is persuasive, and that works in both directions. Business owners who arrived with a fixed picture of what they wanted saw it rendered back at them and stopped looking for anything better. The prototype confirmed the vision they walked in with instead of testing it. It also flattened hard problems. A screen showing a number implies the number is available, so a mock of the easy version set expectations the real version could not meet.
A working frontend changed what people thought we were for
The lab builds capabilities, not applications. Once stakeholders saw a working clickable interface in the first meeting, the question stopped being whether the capability was worth building and became when we would deliver the frontend. A tool meant to shorten discovery moved us into a delivery conversation we are not set up for, and that is a harder expectation to walk back than a slow process.