AI Developer · Module 2 · The Craft of Developing

Frame: Problems, Requirements and Intent

The lesson treats D1 Frame: finding the problem behind a request, writing requirements with a reason and a source, and keeping the specification as the source of intent. Participants learn what AI adds to framing (drafting, clarifying questions, summarising, surfacing what is missing), the six failure modes that follow, and how a specification record SPC keeps the acceptance criteria as an oracle the generator does not own.

Lesson 5 of 33Chapter 575 minutes

Read the chapterThe whitepaperThe slides

All courses / AI Developer / Module 2 / Chapter 5

Learning objectives

After the lesson the participant can:

Key concepts

Three kinds of ambiguity
Vocabulary (a word such as household means different things in the form and in the case system), scope (a request with no edge) and condition (a rule that does not say how it is established). Each needs a different remedy: a glossary entry, an out-of-scope list, a boundary scenario with a named rule owner.
Specification as the source of intent
A specification kept as code in version control, so that it can be tested, versioned with the change and found by an agent. Traceability runs both ways between need, requirement, criterion and test.
The same ambiguity, moved
A generating tool does not stop at a gap in the specification; it fills it with something plausible. The control is an assumptions field and a review step asking which decisions an artefact embodies that no record contains.
Circular verification
The most consequential failure for the book: one assistant drafts requirements and criteria, another generates the code and a third writes the tests, so the loop is closed by machines alone. The control is criteria owned by a person who is not the generator, written before code is generated.
Specification record
The artefact SPC, for example SPC-NR-2030-0001, that links need, requirement, criterion and test, names the owner and the oracle owner, and records what the assistant did. Generation of code begins only after the criteria are committed.

Interactive exercises

Do them here and get feedback at once. Choose a card and then where it belongs, or drag it.

Interactive exercise 1 · Match

Failure modes of framing and their controls

Match each failure mode of AI in framing to the control the chapter gives for it.

Interactive exercise 2 · Put in order

From a request to a committed specification record

Put these steps of the practical guide for turning a need into a specification record in order.

Teaching plan

10 minThe teacher presents a request that arrives as a solution, such as a ticket titled add consent checkbox, and the room restates it as a problem for a named group of users.
15 minLecture on the three kinds of ambiguity, the four kinds of requirement and the three moves from need to testable statement.
15 minWhat AI adds and the six failure modes; participants match each failure mode to the field of the specification record that controls it.
25 minExercise: groups turn a need into a specification record following the ten steps of the practical guide.
10 minReview in plenary: who owns the scope, who owns the oracle, and what the assistant was used for in each record.

Discussion

  1. A summary of seven interviews shows the majority view. How would you make sure that the case handler who works the hardest cases is still heard in the specification?
  2. Assistants tend to agree with the framing they are given. What does that mean for a product owner who asks an assistant whether a proposed scope is right?
  3. Nordvik Region sets specify at Level 0 Advisory and Hansa Mutual at Level 1 Assisted. What in the two organisations explains the difference, and which would you choose for your team?

Written exercise

Exercise · 25 minutes

Turn a need into a specification record

Take a real request from your backlog, or the home-care application form of Nordvik Region. Restate it as a problem for a named group of users and record the evidence, including one source the requester did not choose. List legal and policy requirements with their source. Draft three requirements, each with a reason and a source. Write an acceptance criterion as a scenario for each, with at least one boundary case, and name the person who owns the criteria and is not the generator. Add the assumptions, the open questions, an out-of-scope list and a dissent field, and state what an assistant was or was not used for.

Deliverable: A specification record with owner, oracle owner, requirements with provenance, scenarios, out-of-scope list, dissent field and a review date.

Self-test

Choose an answer to see whether it is right, or open the answer below each question.

  1. The form says household and means the applicant's family; the case system uses the same word for everyone at the address. Which kind of ambiguity is this, and what remedy does the chapter give?

    Show the answer

    C. Vocabulary ambiguity, remedied by a glossary entry agreed with the case handlers
    The chapter's table gives this as the example of vocabulary ambiguity, with a glossary entry in the specification agreed with the case handlers as the remedy.

  2. In the Nordvik Region specification record, how is the baseline for returned applications recorded, and why?

    Show the answer

    A. As not measured, because the claim can only be tested against a baseline that exists
    The chapter calls this a deliberate detail: the baseline is recorded as not measured rather than estimated, since a claim of fewer returned applications needs a real baseline to be tested against.

  3. Where do the Level 4 prohibitions bite on framing, according to the chapter?

    Show the answer

    B. No agent changes the acceptance criteria its own output is tested against
    The chapter treats the criteria as the oracle: changing a criterion changes what counts as correct, which falls under the prohibition on a system changing its own test oracles, so a named person makes the change.