A completed CAB. Source material and generation settings sit on the left; the generated document opens on the right.
Why It Exists
Requirements work usually starts with a blank page, and the blank page is the expensive part. Reading a 200-page solicitation and turning it into entities, roles, screens, workflows, and rules takes weeks, and the result varies with whoever did it. A CAB inverts that. The platform does the first pass across everything you give it and produces a complete draft in one structured shape. You start from a document to correct rather than a document to write, and the parts you correct are the parts that needed a person. The output covers 10 sections, from the problem statement through to the questions your source material left open. See Blueprint Output Reference for what each one contains.Generated, Then Refined
A CAB moves through two distinct phases: Automated Generation. You choose your sections and a quality setting, and the run proceeds through seven phases without further input. Nothing asks you to fill anything in. Editing to Refine and Clarify. Once a blueprint exists you can change it directly, or ask the CAB agent to change it for you. Either way the change goes through a review step before it updates the CAB: every proposed change is tagged as coming from a person or from the AI, and you will review and accept or reject each one.CABs fit into the traditional SDLC by serving as the foundation for your Joint Application Development (JAD) or Requirement Clarification sessions.The CAB will provide detailed user stories, a comprehensive system spec, and suggested questions about the body of work.This output, available just hours after starting the process - makes you ready to support stakeholder discussions immediately - not after several months of work!
When to Build a CAB
Not every project needs a CAB. It is possible to go straight into Tickets or to use the Builder directly. But the CAB is your surest and smartest path towards an Enterprise-grade and Production Quality build. Use a CAB when:- You have source material and need a specification. A solicitation, a requirements pack, an existing system, or a mix.
- You are modernizing a system that is poorly documented. See Legacy Code Translation Guide.
- You need to know what your requirements do not explicitly say. The User Stories and Generated Questions are very useful output for helping ensure you have captured complete and clear scope.
When Not To
- You have no source material. A CAB is generated from what you supply. With nothing to read, there is nothing to generate.
- You want to explore an idea rather than specify one. Prototype Mode is the faster route to mock up something you can look at, this can also be a valuable tool for supporting JAD sessions.
- Your want to Experiment with a living Prototype. Use the builder Directly - guided by manual direction, mock ups, or other light documentation. This allows you to very quickly pop up an application which may support generating clear requirements downstream.
Where to Go Next
Start by generating your first CAB. The pages in this section follow the order you use them in.Generate your first blueprint
What you set before a run, the seven phases, and how to pause or resume.
Check what you can upload
Accepted file types and how each is handled.
Read what came back
What each of the 10 sections tells you about your application.
Correct it before you build
How manual edits and AI suggestions are reviewed and applied.
Turn a codebase into requirements
How uploaded source code becomes a specification.
Find what your requirements left open
How the blueprint surfaces gaps and turns them into questions.