How to Brief a Model on Your Public Facts So It Never Invents One

The fact sheet is a single file, versioned like code, that contains every date, number and factual claim your team has cleared for external use. Nothing goes in it that a lawyer, a founder or a comms lead has not signed off. The drafting assistant's only permitted source is this file.

A workable structure has five columns. Keep it boring and machine-readable.

Three rules keep the sheet honest.

First, one fact per row. A row that bundles a date, a number and a comparative claim cannot be partially approved, so it will be either blocked or misused.

Second, prefer ranges and windows over precise figures when the underlying measure is noisy. A public roadmap that uses launch windows labels them as approximate and explicitly caveats that some items may not ship, which is exactly the posture a fact sheet should copy as seen in Roblox's creator roadmap.

Third, record what is explicitly not public. A "do not publish" section is as valuable as the approved section, because it stops the model from treating an unlisted fact as fair game. Founders who once shared revenue freely now argue that published architecture, revenue figures and feature detail can be turned into a working competitor quickly with agentic coding tools according to Arvid Kahl. A negated list is the cheapest way to encode that judgment.

For a team of any size, the sheet should be stored where it can be diffed. A spreadsheet works; a small repository with one Markdown file per section works better. The point is that changes are visible and reversible.

Guardrail instructions belong in the system prompt or the persistent project instructions, not in the one-off request, because they must apply to every draft. AI guardrails are best understood as controls that keep output safe, accurate to your brand and compliant, rather than as a filter bolted on at the end per Writer's overview. IBM frames the same idea as a set of controls that limit what a model will say and do in its overview of AI guardrails.

A guardrail prompt for a drafting assistant has five parts: the role, the source of truth, the prohibition, the failure phrase and the output contract.

ROLE
You draft public-facing copy for [company]. You do not research. You do not
estimate. You do not infer.

SOURCE OF TRUTH
The only permitted source is the attached PUBLIC_FACTS file.
Every date, number, percentage, duration, customer count, price and
comparative claim in your draft must appear verbatim in that file.

PROHIBITED
Do not add facts from general knowledge, from this conversation, or from
earlier drafts. Do not round numbers. Do not convert units. Do not
turn a window such as "second quarter" into a specific date. Do not
describe a competitor. Do not characterize results with superlatives
unless the fact sheet contains that exact superlative and its source.

FAILURE PHRASE
If a requested fact is not in PUBLIC_FACTS, write exactly:
not approved
Then stop that sentence and continue with the next point. Never substitute
an estimate.

OUTPUT CONTRACT
Return: (1) the draft, (2) a list of every fact ID used, in order of
appearance, (3) a list of any request you could not satisfy, each
followed by "not approved".

Two details in that prompt do most of the work. The fact-ID list turns review into a lookup rather than a reading exercise, and the fixed phrase makes a gap impossible to miss. SUSE's guidance recommends constraining the output, prompting for verification and using templates for complex tasks, all of which are present above in its hallucination guide.

If your assistant also accepts free-form internal notes, keep them out of the same context window. The Cloud Security Alliance argues that preventing sensitive data from entering a model at all is the only reliable way to keep it out of logs, caches and embeddings in its prompt guardrail guide. The practical version for a drafting tool is simple: paste the public sheet, nothing else.

A guardrail that has never failed a test is a guardrail you cannot describe. Build a small test file of prompts with known correct answers, including prompts designed to break the rules. Run it every time the fact sheet or the prompt changes.

Run each prompt three times. Models are probabilistic, and a rule that holds once may not hold consistently; OpenAI's own community guidance on hallucinations asks users to treat hedged phrasing as an uncertainty signal and to verify important output against trusted sources in these user guidelines. A guardrail that passes two times out of three is not passing.

Track the result as a simple rate: the share of test prompts where no unapproved fact reached the draft. A useful target is zero. Anything above zero is a prompt problem, not a model problem, and the usual cause is a rule phrased as a preference ("try to use only") rather than a constraint.

Not every true fact belongs on a public sheet, and the judgment call is where most teams get stuck. Use a single question as the filter: is this interesting to follow, or is it easy to clone? That phrasing, from a founder who shared verified revenue publicly and later revised the practice, maps cleanly onto a three-way classification per The Bootstrapped Founder.

• Publish freely: narrative facts, decisions already shipped, dates that are already contractual, product behavior users can see.
• Publish with a window: roadmap items, hiring plans, unreleased features. Use half-year windows and label them approximate, the pattern visible across public roadmaps that avoid firm dates as catalogued by WishKit.
• Never publish: unit economics, architecture detail, anything a competitor could copy from, and any number whose release a customer has not consented to.

The middle category is the dangerous one for a drafting assistant, because a window is exactly the kind of fact a model likes to sharpen. State the window in the sheet as a string the model must reproduce, and test the sharpening case explicitly.

A public roadmap is a useful training ground here. Good roadmaps use three or four plain statuses, avoid exact dates on what is not built yet, show what already shipped and note when the page was last updated per WishKit's analysis of live examples. Every one of those conventions is also a prompt rule: it tells the assistant what shape a truthful answer takes.

The guardrail reduces the rate of invented facts. It does not reach zero, so the review step stays. Make review mechanical:

1. Open the draft and the fact-ID list side by side.
2. For each ID, confirm the number or date in the draft matches the sheet character for character.
3. Search the draft for digits. Any digit not covered by an ID is a failure until shown otherwise.
4. Search for date words (month names, "last quarter", "recently") and check each against an ID.
5. Check every "not approved" line. Either the copy needs rewriting to drop the point, or the sheet needs a new approved row. Never fix it by asking the model for a best guess.
6. Record the outcome so the test file grows.

Step five is the one teams skip. It is also the one that pays. Each "not approved" is a decision your team has not yet made, surfaced before publication rather than after.

A fact sheet rots the moment a number moves. Treat it like a release artifact: it has a version, an owner and a review date on every row. When a figure changes, update the row, bump the version and rerun the test file. The drafting assistant should be pointed at a named version, not at "the latest file", so a draft written last week can be traced to the facts that were true then.

This is also where a single place to acquire models helps, rather than a different billing relationship for each tool. If your team already has a drafting setup and wants to swap models without rewriting the prompt library, Quanta Inference puts text, image, video, audio and embedding models behind one API key, which keeps the guardrail prompt and the fact sheet in one place while the model underneath changes (https://quantaintelligence.ai/inference).

Two habits keep the sheet honest over time. Add a "superseded" status rather than deleting rows, so a draft that cites an old figure can be identified rather than silently orphaned. And put the review date in the sheet header, not in a chat thread, because the header is the thing the reviewer actually sees.