What is a system prompt and why is it a product asset rather than a code detail?

Lanternway is Hollowfield Systems' internal search assistant: point it at a company's HR handbook, IT steps, and expense rules, and an employee gets a plain answer in seconds instead of hunting through five documents. Millport Freight, a logistics company, has run it for two years. Elspeth Ferraday owns Lanternway's system prompt, the file that decides how it's allowed to answer. Godwin Adesanya runs benefits for Millport Freight. He's the one who found out what a single wording change had been quietly telling people.

How to answer this, stage by stage

Nobody's grading whether you can define "system prompt" like a glossary entry. They're grading whether you'll notice the moment a wording change starts deciding something a lawyer would call company policy.

Let's learn

Say a company installs an AI helper that reads every internal page it owns, the HR handbook, the IT steps, the expense rules, and answers a worker's question in plain words instead of making them hunt through five different documents.

Before, a worker with a benefits question dug through a policy PDF or waited on hold with HR, and a straight answer took about fifteen minutes, sometimes a full day if HR was busy. Now the helper answers in about ten seconds. And it answers with confidence, stating the policy as settled fact instead of hedging.

One file. Every kind of question the company gets asked, routed through the same wording.

At its worst, the helper spends five weeks telling employee after employee that they qualify for a benefit they don't actually have yet, because one line of the real policy sat below the sentence the new wording stopped checking.

What I would leave alone: a wording change to how the helper says hello, or how it formats a list, never needs this much ceremony. Spend the review budget on the sentences that decide money, safety, or someone's job, not the ones that decide how friendly the greeting sounds.

The lesson: a system prompt looks like a string of text sitting in a file, so it's tempting to edit it the way you'd edit a comment. But it's the one place that decides, in plain language, what the product is actually allowed to say. Anything that decides that deserves the same care as the button that submits a payment.

Now here is the same thing as a story

The short version above is what you'd actually say in the room. Read this one when you want to feel exactly what a skipped review cost, sentence by sentence.

Every Thursday afternoon, Elspeth Ferraday pulled up Lanternway's support queue and read every single ticket end to end, even the ones marked low priority. She'd written Lanternway's very first system prompt herself, three short paragraphs telling it how to greet a worker, how to cite its source document, and when to say "I'm not sure, ask HR" instead of guessing. Two years in, she still knew which sentence controlled which behavior, off the top of her head.

For the first year, every wording change to that prompt got a Slack thread and a nod from a reviewing engineer before Elspeth merged it, even a change as small as softening how the helper apologized for a bad search. Some weeks it felt like overkill. Nothing had ever gone wrong from it.

Nobody decided, on any single day, to stop reviewing wording changes. It thinned out in three quiet steps.

By the second year, only changes that opened a whole new question category got that treatment. A one-line tone tweak just went in. By the eighteen-month mark, a wording tweak rode along inside whatever pull request Elspeth already had open that day, reviewed by whoever was reviewing the unrelated code next to it, if anyone.

Then Millport Freight's contract came up for renewal, and one number on the account dashboard bothered everyone in the room: satisfaction was fine, but forty percent of benefits questions still ended with Lanternway saying "confirm with HR." Millport wanted that number down before they signed again.

So on a Thursday, Elspeth rewrote the benefits section of the prompt. The old wording said: for any eligibility question, always tell the worker to confirm with HR, and only quote the general policy text. She tightened it: state the policy's conclusion directly when the source document reads as clear, and save the HR line for anything the document itself flags as unclear. She folded the change into a pull request that also fixed how footnote numbers rendered in citations. The engineer reviewing signed off on the citation fix. It shipped that afternoon.

Millport's parental leave policy reads, in its first line, "full-time employees are eligible for sixteen weeks of paid parental leave." Three sentences later, a clause about tenure adds: employees under ninety days get unpaid leave only, under state law. The old wording had always deferred on this question entirely, so the tenure clause never mattered to what Lanternway said. The new wording read the first line as clear enough to state outright, and never got to the tenure clause at all.

Godwin Adesanya runs benefits for Millport Freight. Five weeks after the change shipped, he ran his usual month-end reconciliation and found six payroll correction requests in a single week, employees who'd started leave expecting full pay and weren't getting it. He pulled Lanternway's chat logs to see what each of them had actually been told.

Fourteen employees, over those five weeks, had asked some version of "am I eligible for parental leave" and been told, plainly, yes. Not one of them had reached ninety days.

I want to say the problem was one careless edit. It was a real cause, but it's not really the story. Elspeth never had a rule she was slowly bending. She had a switch: either a wording change went through a second reviewer and a real test, or it didn't. By month eighteen, there was no version of a quick prompt fix that still got the first one.

Here's the decision I'd take back. Not "read more carefully," and not "hire a reviewer." The actual decision got made in Lanternway's first month, when the prompt was three paragraphs and every tweak was cosmetic: reviewing a wording change felt like the same weight as reviewing a line of code, so it lived in the same pull request, checked by whoever was already looking at that PR. Nobody revisited that once the prompt grew to cover a dozen policy categories with real money and real leave attached to them.

Run the same Thursday again, with one thing changed back in month one: a wording change to the system prompt is its own pull request, tagged separately, and it can't merge until it clears Lanternway's golden set, forty real past questions the model has to answer correctly, including, now, the tenure-exception question added the week after this incident. Elspeth drafts the same confidence-tightening wording, for the same reason, under the same pressure from the same renewal meeting. The golden set catches it the same day: the test case answers "yes, you qualify" for a worker at day forty, which is wrong. She adds a tenure check to the wording instead of removing the caveat outright. It ships two days later. Zero employees get the wrong answer.

One design finds this five weeks and fourteen employees later, from a payroll spreadsheet. The other finds it the same afternoon, from a test that was built to catch exactly this.

What I'd tell my past self, the one who filed that first wording tweak next to a citation bug because splitting it into its own pull request felt like busywork: "it's just wording" is true right up until the wording is the only thing standing between a worker and a policy that isn't actually theirs yet. You don't find out which sentence that was until afterward.

FLIPS, or how a wording fix quietly becomes a policy

Not a trick to sound structured. FLIPS is what makes you notice the moment a sentence in a config file starts deciding something a lawyer would call company policy.

Four setup and payoff letters, and one hard question in the middle of all of them.

Elspeth's review habit was never a dial easing down. It was a switch, and eighteen months of quiet tweaks flipped it without anyone deciding to.

Same five weeks. Same kind of wording change. The only thing that moved is what stood between the wording and the employees.

The whole answer, in one picture. Nobody designed a dial. Everybody got a switch.

Three things worth being direct about, since this is where the real judgment sits. We considered the obvious fix first: just add a disclaimer banner, "Lanternway's answers aren't guaranteed," instead of a review gate. Rejected, because a banner doesn't change what the sentence said with full confidence, the employee still walks away with the same wrong plan in their head, just with a legal footnote nobody reads. The AI-specific failure worth naming is silent behavior drift from a wording change alone: no error, no crash, no code diff a normal review would ever flag, just a different sentence coming out of the same model. The guardrail is a golden set of real, hard past questions that every wording change has to clear before it ships, not a person's read-through. And there's a real trade-off, accepted on purpose: a wording change that used to ship in about an hour now takes at minimum a day, one eval run plus a short staged window. That's slower for the tweaks that really are harmless, and we don't get to know in advance which ones those are.

And if you want to be sure it really works, try it somewhere else

Same five letters, a different kind of overload. This time the team already built a review gate, and it still didn't catch the failure, because of what the gate was actually tested against.

Kestleworth Field Services runs Ductline, an AI assistant technicians open on a tablet in the truck. Point it at a make and model and it reads the equipment manual, then walks the technician through the fix, including any high-voltage safety warning buried inside it. Ottakar Draye has kept Ductline's golden eval set, the questions every wording change has to pass, for just over a year.

For the first ten months, every new case in that set came straight from a real manual: the actual page, appendix and all, pasted in whole. Building one that way took Ottakar the better part of an afternoon. Building one from memory, a clean two-paragraph version of the same scenario, took ten minutes and passed the model just as well. Nobody was watching which method he used, because both kinds of case had always caught the bugs they were supposed to catch.

A technician in the field opened Ductline on a discontinued heat-pump unit with a wiring warning tucked into a footnote on page thirty-four of a sixty-one-page manual. Ductline walked him straight past it. Nothing in the golden set had ever included a warning shaped like that, because sixty-one of Ductline's eighty cases by then were Ottakar's own tidy rewrites, and a tidy rewrite never keeps a footnote.

Same idea, different failure shape. A review process is only as honest as what it actually tests against.

F · Ottakar Draye, who has kept Ductline's golden eval set for a year, at Kestleworth Field Services.
L · He stopped building every new golden-set case from the real source manual, once a quick, clean rewrite had passed the model just as reliably, a dozen times running.
I · The pre-editing flip, a different shape from Elspeth's. Old setting: builds each case from the real document, page numbers and appendix included. New setting: writes a short, tidy version of the scenario himself, because the real manual is a hassle to extract from. No middle: either the golden set is built from real documents, or it's quietly built from someone's summary of them.
P · When the golden set started at twelve cases, a hand-typed clean example covered the idea just as well as the real page. Nobody revisited that shortcut once the set reached eighty cases and the manuals behind it got messier and longer.
S · New rule: every golden-set case gets pasted in directly from the real source document, never rewritten by hand. The next messy manual, a different unit with a wiring note buried in a footnote, gets caught in the eval run the same week it's added to the set, not months later from a technician standing in a driveway.

Swap the trigger and it still runs.
Speed: an interviewer caps you at ninety seconds. Skip straight to it: a review process only tests what's actually sitting in the test pile. If the pile is all clean examples, the process is theater with extra steps.
Cost: no budget for a dedicated reviewer. Pasting the real source straight into the golden set costs nothing extra, it's the same copy-paste as writing a clean version, just without the tidying.
The model got better, for real: say Ductline's overall accuracy hits 99 percent next year. Doesn't matter. A golden set built from easy examples will still miss a real footnote, no matter how good the model behind it gets.

Where people run it wrong.
They treat "we have a review process" as the finish line, without ever checking what the review actually tests against.
They let whoever's fastest at writing a test case decide how realistic that case gets to be.
They wait for a rewritten case to fail before questioning it, when a rewritten case is built, by definition, to pass.

How to use it live. When an interviewer asks what a system prompt actually is, ask yourself one thing before answering: who's allowed to change it, and does anything real stand between that person and production? If the honest answer is "nobody, really," that's the whole question, answered.

Flashcards (tap any card to flip it)

Check yourself Score: 0 / 0