Turning a wish list into test rules a tester can actually run.

Bad test rules cost months. Good ones are hiding in the company's own papers.

Imagine a teacher writes "the science fair project should be good". You cannot grade that. A better version says "given a project with a hypothesis, when it is presented, then it must show the data it collected". Software has the same problem. A vague wish becomes a wrong program. The details needed to write good test rules are already in other documents: which fields exist, which error messages the other systems send, how past wishes were tested. Nobody has time to read all of it for every wish.

The same eight stops as the price job. This time the writer does real work, so the filter matters.

What makes this job about wishes instead of prices is a set of settings: four recipe cards for reading, five kinds of fact, eight questions, and a list of cases each kind of wish must cover.

Because it grows models from your own data, on computers you own, with any language model you choose.

HomeGrwn is the product the Brain runs inside. Its job is to turn a company's own records into models that belong to that company: rules with versions today, trained helpers per question once there are enough labels. The language model that writes the words is your choice. The tests on this page used a small open model on a laptop; a bigger model with your own API key plugs into the same slot, because the writer never decides anything. Here is where each part of the feature refinement job actually ran.

Four files, exactly as the company keeps them.

The test files were made by a generator we wrote so we would know the answers. They look like real project files, but they are not a real company's files.

A peek inside

The wish list
REQ-PC-001  If PolicyDriver.AccidentCount is over 3 the system applies the high-risk surcharge of 12%.
REQ-PC-002  Premiums must be accurate as expected for all cases, etc.
REQ-PC-008  Approving the quote binds the policy and also sends the welcome email and also schedules the inspection.
REQ-PC-016  On entering a VIN the system calls VINLookup and fills PersonalVehicle.Symbol from the response within 3 seconds.

The field-name sheet          old name          new name
                              LEG_POL.MPD_FLAG  PolicyPeriod.MultiPolicyDiscount
                              LEG_POL.TERM_CD   PolicyPeriod.TermType
                              (there is no row for PolicyDriver.AccidentCount, so wish REQ-PC-001 talks about a field the company does not have)

The other-systems sheet
Error codes returned by VINLookup: TIMEOUT, VIN_INVALID, NOT_FOUND.

An old wish from Jira
{"story_id": "PC-900", "title": "When a Personal Auto quote is rated and ...", "status": "done",
 "acceptance_criteria": ["Given the rating inputs, when the quote is rated, then the premium equals the worked example to the cent"],
 "reviewer_edits": 2}

From a file on the shelf to facts in folders, one file at a time.

Every file took the same trip: the front door stamped it and guessed what it was; a person said yes; a recipe card cut it into pieces; each piece became facts; each fact passed six checkpoints; the facts were filed in folders. Two of the recipe cards first had the wrong reading shape (a grid instead of rows), and every row from those files was held back; the fix was a settings change, not code.

Totals: 109 pieces, 114 facts, 65 folders, 20 names in the name list (16 fields, 4 systems), 0 facts held back, 0.3 seconds.

Two agents did the reading and one more built the name list. A person only clicked yes.

The front-door agent (the manifest)

It scores each recipe card against the file ending, the words in the file name ("BRD", "Mapping", "Spec", "jira") and the first row. The wish list scored 3 (only the name helped); the sheet and the Jira export scored 11 (their headers matched the card). It reads the version from the name (2026.2, v3).

The reader agent (the recipe cards)

The paragraph reader opens a folder for every numbered heading and makes one fact per sentence under it. The row reader makes one fact per row, naming it from the columns the card points at (Target Object and Target Field). Nothing here knows what a "policy" is.

The name-list agent

After reading, it walks the field facts and the system facts and builds the name list: 16 field names like PolicyPeriod.TermType and 4 systems with their error messages. This list is what question 6 checks against and what the writer is allowed to mention.

The six checkpoints

Same shelves as the price job. Different things on them.

A new wish list is a new drop, not a new copy.

The same rules as the price job, applied to documents.

Each wish gets a folder. What the other documents say about it goes in the same folder.

The clearest example is question 6, "does it name a field the company lacks?". Wish REQ-PC-001 talks about PolicyDriver.AccidentCount. Memory holds the company's field names. The Brain looks for that name in the list, does not find it, and writes that down, pointing at both the wish and the sheet.

A map where similar sentences sit close together. It brings the writer good examples. It never answers a question.

A vector is a long list of numbers that works like a pin on a map. Two sentences that mean nearly the same thing get pins close to each other. Old wishes and system sentences get pins after their names are hidden. The writer asks for the three old wishes nearest to the new one and sees their test rules as examples of how this team writes.

the original (sealed on the shelf)
  "PC-912 · Reported by maria.chen@acme-mutual.example: when the Home
   policy for customer Dale Okafor was cancelled, the Auto quote kept
   its multi-policy discount."

with names hidden (what gets a pin, what the model sees)
  "PC-912 · Reported by [[email:9a41c2e07b3d]]: when the Home policy
   for customer [[name:e2f70c11ab98]] was cancelled, the Auto quote
   kept its multi-policy discount."

the pin (a list of numbers; 768 of them with a real embedding model)
  [-0.0412, 0.0937, 0.0088, ...]

Each question has its own helper. Most helpers are rules, not AI.

The model writes one line at a time. The filter reads every line before anyone else does.

The writer gets the wish, the eight signed answers, the names it may use, and one case to cover. It writes the story once, then one test rule per case. Each line goes through the filter: every field name must be in the name list; every number must appear in the wish or in a fact; the case must be one that was asked for; words from the never-say list are cut. A deleted line is kept in the notebook with its reason, and the writer gets one more try with that reason in front of it.

513 lines for 57 wishes: eight answers and one draft each.

A line says: which wish, which question, the answer, whether a rule or the model answered, which rule version, which facts were read. The draft line holds the story, every test rule kept, and every line deleted with its reason. The database refuses to change or delete a line, and the seals were verified intact.

A quiz with 57 wishes. We wrote some of them badly on purpose and kept the answers to ourselves.

Like a spelling quiz: the teacher keeps the answer sheet, the student only gets the quiz. A program we wrote made the four files with 57 wishes. On purpose, 6 of them cram two or three wishes into one sentence, 9 are too vague to test, and 6 mention a field the company does not have. It also wrote a secret answer sheet: for each wish, how many wishes it really is, whether it can be tested, what kind it is, and which cases its test rules must cover. The Brain was given only the files, never the answer sheet. When it finished, we compared its notebook with the answer sheet to score it.

What the Brain wrote, what it refused to write, and what the filter deleted.

From the last try with llama3.2:3b. Every line below is in the notebook, with the answers it was written from. Every deleted line is there too, with the reason.

Wish REQ-PC-016 · a call to another system, written in full

"On entering a VIN the system calls VINLookup and fills PersonalVehicle.Symbol from the response within 3 seconds." Seven cases to cover, three from the error messages the systems sheet lists.

Seven of seven cases covered, nothing deleted. The "too slow" line is weak: it repeats the case name instead of saying what the screen should show. A reviewer would fix it, and that fix is what the Brain learns from.

Wish REQ-PC-015 · a price formula, where the model made up numbers

"The comprehensive premium is the base rate for the vehicle's PersonalVehicle.Symbol and territory multiplied by the deductible factor for PersonalVehicle.CompDeductible, rounded to the cent, and never below 25.00."

The surviving example has no real numbers because the wish has none to give. Real numbers live in the price tables, which are in the other job's Memory. Connecting the two is the next step.

Wish REQ-PC-001 · sent to a person, nothing written

Wish REQ-PC-008 · three wishes in one sentence

Correct, but still one story for three wishes. The next change splits the sentence into three folders first, so each part gets its own kind and its own cases.

Four tries. The ones that looked best were the least honest.

A short glossary.

wish (requirement)

one sentence saying what the software should do

test rule (acceptance criterion)

"given this, when that, then this should happen"; a tester can run it

drop

a batch of files handed to the front door at one time

recipe card

a settings row that tells a reader how to cut a kind of file into facts

fact

one true thing read from a file, with its type, value, dates and source

folder (item)

everything known about one wish; it has numbered, dated versions

name list (entities)

the field names and systems the company really has, built from its own sheets

notebook (ledger)

the append-only, sealed list of every answer and every draft

helper (model)

whatever answers one question with a version and a signature: a rule set, or a language model behind a filter

filter (firewall)

the checklist every written line must pass

vector (pin)

a list of numbers that places a piece of text so similar text sits nearby

vault

the locked store of real values behind the hidden names