Inception Phase — Planning the Idea

In the last lesson, we met Robo and learned that AI-DLC has three phases: Inception, Construction, and Operations. Now let's pick one real problem and actually do Inception — step by step — so you can see exactly what it looks like in practice.

Phase 1 of 3: Inception Goal: turn a fuzzy idea into a clear, agreed-upon plan.

Our Problem

Ms. Sharma runs the class library. Right now she tracks borrowed books on paper. Books keep going missing, because nobody remembers who borrowed what, or when it was due back. She wants something simple to fix this.

That's it. That's the whole starting idea — one sentence, a bit fuzzy, no technical detail. This is completely normal. Inception exists precisely to turn this into something buildable.

What Actually Happens in Inception?

Inception isn't Robo silently typing — it asks first, like a good reporter interviewing you before writing the story. Anything you don't write down gets forgotten or misremembered later, so as the questions get answered, they get turned into documents as you go.

The Real Steps Inside Inception

The real AI-DLC methodology breaks the Inception phase into seven possible stages (each phase is made of stages — Inception, Construction, and Operations are the only three phases). Not every project needs all seven — Robo decides which ones actually add value for your project, shows you that plan, and you can always add a skipped one back in:

1. Workspace Detection (always runs) — is this a brand-new project with nothing built yet ("greenfield"), or are we adding to something that already exists ("brownfield")? Ms. Sharma's library tracker is greenfield — there's no app here yet, just paper and a problem.
2. Reverse Engineering (brownfield only) — if there's already code, Robo studies it first: how it's built, what it already does, what it depends on — before touching anything.
3. Requirements Analysis (always runs) — the question-and-answer stage you're about to see below.
4. User Stories (runs when it adds value) — turning "what we need" into "who needs it and why," sometimes with a quick persona, like "Ms. Sharma: a busy teacher with about two minutes between classes to log a loan."
5. Workflow Planning (always runs) — Robo shows you which of these stages it thinks are worth running for your project, and why, before running any of them.
6. Application Design (runs for anything with real components) — sketching the pieces the app is made of and how they talk to each other.
7. Units Generation (runs when there's more than one clear piece) — splitting the design into small units of work, each buildable and checkable on its own — exactly what Construction builds, one at a time.

For a tiny project like ours, several of these stay short or get skipped entirely. For something a school — or a company — will really depend on, running them properly is cheap insurance against expensive surprises later.

How the Questions Actually Arrive

Here's a detail that surprises people: AI-DLC doesn't ask its questions in the chat. It writes them into a file, in multiple-choice format, and waits for you to fill in the answers there — so there's a durable, precise record of exactly what was decided, not a chat log that scrolls away and gets forgotten.

Robo creates a file — something like aidlc-docs/inception/requirements/requirement-verification-questions.md — that looks like this:

## Question 1: Who uses this app?
A) Only Ms. Sharma
B) Ms. Sharma and students, self-service
C) Ms. Sharma manages it; students just tell her what they're taking

[Answer]:

## Question 2: Is there a limit on books per student?
A) No limit
B) Yes — a fixed number per student
C) Yes — but it varies by grade
X) Other (describe below)

[Answer]:

## Question 3: What happens when a book is overdue?
A) Nothing automatic — Ms. Sharma checks manually
B) It shows up on an "Overdue" list
C) The app sends a reminder

[Answer]:

You open that file, type your answer after each [Answer]: tag — a letter, a combination like "B and C," or your own words after X — then go back to the chat and say something like "We've answered your questions, please re-read the file and continue." Robo reads your actual answers off disk, not its memory of the conversation, and moves on.

Notice what didn't happen: Robo didn't just start coding. It asked first, in writing, because a wrong guess here is cheap to fix — a wrong guess after the code exists is not.

A note on how this really happens: in real teams, filling in that file usually isn't one person alone — it happens as a group, sometimes called mob collaboration. The product owner, the developers, maybe a tester, all looking at the same question file together, so the answers reflect what the whole team actually knows, not just one person's guess.

A note on who typically drives which phase: in practice, the product owner usually owns Inception — the requirements, the user stories, sometimes even the answers to Robo's questions — while developers take over once Construction starts. Some teams connect Robo to their existing tools (Jira, Confluence) so a product owner can pull requirements from and push user stories straight back to the tools the rest of the organization already uses, instead of everything living only inside the chat.

What the Inception Document Looks Like

Here's the document Robo produces once the questions are answered. To keep this lesson simple, we're showing everything combined into one document — but it's worth knowing that the real AI-DLC tooling actually splits this across several files inside aidlc-docs/inception/: requirements/requirements.md, requirements/requirement-verification-questions.md (the file you just saw), and later user-stories/stories.md and user-stories/personas.md. Same ideas, just organized as separate documents instead of one:

# Inception Document: Class Library Loan Tracker
Status: Draft — v1
Workspace: Greenfield — no existing app or codebase

## Problem Statement
Ms. Sharma's class library tracks borrowed books on paper.
Books are frequently lost because there's no reliable record
of who borrowed what, or when it's due back.

## Goals
- Let Ms. Sharma record when a student borrows a book.
- Let Ms. Sharma record when a book is returned.
- Show which books are currently out, and which are overdue.

## Non-Goals (out of scope for now)
- Students logging in and self-service borrowing.
- Fines or penalties for late books.
- Barcode scanning.

## Users & User Stories
Persona: Ms. Sharma — a class teacher with about two minutes
between periods to log a loan or return. Needs this to be fast,
not fancy.

- As Ms. Sharma, I want to mark a book as borrowed by a
  student, so I know who has it.

- As Ms. Sharma, I want to mark a book as returned, so it's
  available for others again.

- As Ms. Sharma, I want to see a list of overdue books, so I
  can remind students to bring them back.

## Domain Model (the "things" in our system)

    Book { title, author, is_available }
    Student { name, class }
    Loan { book, student, borrowed_on, due_on, returned_on }

## Acceptance Criteria
- GIVEN a book is available, WHEN Ms. Sharma records a loan,
  THEN the book becomes unavailable.

- GIVEN a book is returned, WHEN Ms. Sharma records the
  return, THEN the book becomes available again.

- GIVEN today's date is past a loan's due date and it hasn't
  been returned, THEN it appears in the "Overdue" list.

## Open Questions & Risks
- Q: Is there a limit on books per student? (see review below)
- Risk: paper records already exist — do we need to enter
  old loans, or start fresh?

A quick diagram of the same entities, because pictures make relationships click faster than a paragraph of text:

erDiagram
    STUDENT ||--o{ LOAN : borrows
    BOOK ||--o{ LOAN : "is borrowed in"
    STUDENT {
        string name
        string class
    }
    BOOK {
        string title
        string author
        bool is_available
    }
    LOAN {
        date borrowed_on
        date due_on
        date returned_on
    }

How We Review It

This draft is not final — it's a starting point for you to check. Reading an Inception document, you're asking yourself three simple questions:

1. Does this actually match what I meant?
2. Is anything important missing?
3. Is anything here more complicated than it needs to be?

While reviewing our draft, Ms. Sharma remembers something important: earlier in the conversation, she said "a limit makes sense" but never said what the limit is, and Robo's draft left it as an open question instead of guessing. That's exactly the kind of gap Inception is meant to catch.

Review note from Ms. Sharma: "Let's cap it at 2 books per student at a time. Also — if a book someone wants is already borrowed, the app should just say so clearly, not let it be double-booked."

This is normal and expected — nobody gets the plan perfectly right on the first try, human or AI. The point of Inception is to surface exactly this kind of gap now, while it's just a sentence to add, not code to rewrite.

Iterating Until Approved

Robo takes the feedback and updates the document. Here's the relevant section, before and after:

v1 (draft):

## Acceptance Criteria
- GIVEN a book is available, WHEN Ms. Sharma records a loan,
  THEN the book becomes unavailable.

## Open Questions & Risks
- Q: Is there a limit on books per student?

v2 (revised):

## Acceptance Criteria
- GIVEN a book is available, WHEN Ms. Sharma records a loan,
  THEN the book becomes unavailable.

- GIVEN a student already has 2 books on loan, WHEN Ms. Sharma
  tries to record a 3rd loan for them, THEN the app blocks it
  and explains why.

- GIVEN a book is already on loan, WHEN someone tries to
  borrow it again, THEN the app blocks it and shows who has it.

## Open Questions & Risks
- ~~Q: Is there a limit on books per student?~~ Resolved: 2
  books max per student.

This review → revise loop repeats until there's nothing left to correct:

flowchart LR
    D1["Draft v1"] --> R1["Human Review"]
    R1 -->|"changes needed"| D2["Draft v2"]
    D2 --> R2["Human Review"]
    R2 -->|"looks right!"| A["Approved"]

    classDef ok fill:#c8e6c9,stroke:#388e3c,stroke-width:2px;
    class A ok;

Once nothing's left to fix, the document's status line is updated:

Status: Approved — Ready for Construction

Why Bother With All This Before Writing Any Code?

Because a misunderstanding caught here costs two minutes — you just edit a sentence. The same misunderstanding, caught after the code is written (or worse, after Ms. Sharma is already using it), can cost hours of rework, or a broken app in front of real users. Inception is the cheapest place in the whole process to be wrong.

What's Next

The Inception document is approved. It's no longer just an idea — it's a blueprint. In the next lesson, we'll watch that blueprint turn into real, working, tested code during the Construction phase, and answer a very practical question: what files actually get created, and where?

Continue to: Construction Phase — Building It for Real