Brackets Are the Proof It Didn't Fabricate

When someone runs the first prompt in module 4 for the first time, they tend to ask why there are brackets in the output.

[year] in the founding date section. [town, Indiana] in the location. [X] miles in the service area. They expect a finished document. What they get has placeholders.

We call those the money moment.

The prompt interviewed them, asked about their products, their customers, their voice, the words they'd never use, and the mistakes they've already made. It built a real document from their answers. And where it didn't have an answer, it wrote a bracket instead of filling the gap.

That's not an incomplete output. That's the output working correctly.

What the Alternative Looks Like

A model that doesn't leave placeholders will fill gaps with plausible content. It knows the rough geography of Indiana grain farming. It knows ag retailers are typically established in a certain era. It knows a believable service radius for a rural input dealer.

None of that is your business.

The founding year it generates might be 1987. Yours is 1994. You won't catch it because it sounds right. You paste it into the file. For the next six months, every time Claude writes something that references your history, it uses 1987. You don't notice because it's always been there.

That's the fabrication problem in miniature: a plausible detail that's wrong, embedded in a source document, reproduced in every downstream output.

The Bracket Is the Constraint Working

The business file prompt includes an explicit rule:

Never fabricate specifics. Do not invent founding years, locations, staff counts, product line names, or testimonials. If the user's answers don't include a detail, use a bracketed placeholder like [year founded] or [town, Indiana]. Leave the bracket, don't guess.

That instruction is why the brackets appear. Not because the model didn't know how to fill them in. Because the prompt told it not to.

The same rule covers testimonials, staff counts, and any number the user didn't provide. If the information didn't come from the interview, it gets a bracket.

What You Do With the Brackets

Fill them in from what you actually know. That's the only correct source for those values.

The brackets also tell you which sections of the file need the most attention. A file with ten brackets tells you where the interview ran thin. A file with two tells you the interview was thorough. You can look at the brackets and know exactly how much work is left.

We designed the Freedom Ag worked example the same way. The example shows what a finished business file looks like when it's done correctly. Every value only a specific retailer would know is left as a bracket: [year], [town, Indiana], [X] miles, [add your other lines here]. Everything general to how they operate is filled in, because we knew it.

The distinction between the two is visible in the file itself.

Why This Matters Beyond the File

The right question when you look at AI output is not "does it sound right." It's "does it tell me when it doesn't know."

Output that marks its gaps is easier to audit than output that fills them with plausible-sounding guesses. A bracket is a question that still needs an answer. A confident fabrication is a wrong answer that passed the smell test.

The business file prompt was designed to produce the first kind. The brackets are evidence that it did.