> ## Documentation Index > Fetch the complete documentation index at: https://docs.aperium.apps.hillspire.com/llms.txt > Use this file to discover all available pages before exploring further. # Prompting & getting good results > Give context, be specific, iterate — then spot a bad answer and diagnose prompt, data, or model. Two people ask Aperium the same kind of question and get very different quality answers back — same tool, same model, different prompt. That gap is almost always the prompt. And even a well-crafted prompt sometimes still comes back wrong — that is normal too. This page covers both halves: the habits that close the quality gap, and the troubleshooting skill for the moment it still goes wrong. ## The one mental model Treat every prompt like delegating a task to a very capable **new hire who started this morning.** They are smart and know a lot in general — but they know nothing about Hillspire, this specific task, your audience, or what "good" looks like to you, until you tell them. The quality of your delegation instructions is the quality of what comes back. Keep this analogy in your pocket — later it becomes the bridge into diagnosis. Even a great new hire can misread a rushed ask, or lack a document they needed. ## The recipe: context, specific, iterate Who you are, what the output is for, and who is going to read it. "Write an email about the Q3 numbers" gives no audience and no goal. The stronger version tells it you are the ops lead, the audience is non-finance execs, and what the email needs to accomplish — same topic, completely different starting point. Name the task, the format, and the length. "Summarize this memo" could come back as one paragraph or ten bullets. "3 bullets, ≤20 words each, for a board member skimming before a meeting, focused on financial impact and the decision needed" leaves nothing to chance. If you have a past example or template, hand it over instead of describing the shape in words — for example, prepping for a CFO meeting by attaching last quarter's prep doc and saying "match this structure." One example often does the work of a paragraph of instructions. The first answer is a draft, not a verdict. When the first CFO-prep pass comes back generic — wordy talking points, a vague risk section — a short follow-up ("cut talking points to ≤15 words each, pull the actual Q3 budget number from the attached doc into the risk line") gets it the rest of the way. Two or three rounds is normal, and far faster than rewriting from scratch. ## False flags: prompt superstitions These feel like they should help, but none of them change what the model is capable of or how hard it "tries": * **"You are an expert in X."** Does not change what the model actually knows or can do. * **Politeness padding.** Say please if you like — just do not expect it to move quality either way. * **"Make no mistakes" / "be 100% accurate."** The model is not holding back effort waiting to be told to try harder. * **Threats** ("I'll lose my job") and **bribes** ("I'll tip you \$200"). No real effect on quality. What actually moves quality is everything in the recipe above: context, specificity, format constraints, and examples. ## When it still goes wrong A tool that [predicts plausible text](/literacy/how-llms-work) will sometimes predict wrong text, even with a good prompt. That is not a malfunction — it is how the tool works. Same as the new-hire analogy: a smart colleague can misread a rushed ask or lack a document. The skill is not "never get a bad answer" — it is noticing one fast and knowing what to do next. Do not abandon the tool over one miss; do not blindly trust a fluent one either. ### Spotting a bad answer | Signature | What it looks like | Tell | | ---------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | | Confidently wrong facts | A precise but wrong figure — e.g., a fund AUM that does not match the real report. | Sounds exactly as certain as a correct answer. | | Made-up specifics | An invented artifact that does not exist — e.g., a "March 2026 board resolution" that was never passed. | Same confident tone; no such thing exists. | | Missed instructions / format | Asked for 3 bullets ≤20 words, got two paragraphs and four extra sections. | Usually the most obvious — and easiest to fix. | | Stale / unknown info | Does not know a policy that changed last month, a renamed system, or a deal closed after training cutoff — and guesses instead of saying "I don't know." | Different root cause than a hallucination, same surface symptom. | | Going off the rails | Deep in a long chat about three portfolio companies, it mixes up which numbers belong to which. | It was fine earlier in the same chat and has drifted since — a [context-window](/literacy/ai-vocabulary) problem, not a knowledge problem. | Sounding certain is not evidence. Confidently-wrong facts and made-up specifics both sound exactly as sure as a correct answer. ## Diagnose: prompt, data, or model? Once you have spotted a bad answer, ask three questions **in this order**, because each is cheaper to check than the next. Was my ask clear and specific enough that a smart colleague could have understood exactly what I wanted? If not, that is the habits above wearing a different hat — the cheapest fix. Did it actually have the real source it needed, or did it have to guess? If it never saw the source, no amount of clever wording fixes it. Is this a genuine limit — no access to that system, past its knowledge, or right at the edge of what any model does well? Land here only once you have ruled out the first two. Quick test: would a sharp new colleague have gotten it right **if asked more clearly**? That is a prompt problem. **If handed the file**? Data. **Neither**? Model. ## Recover: five moves Match the move to the diagnosis: * **Re-ask more specifically** — narrow the ask, restate format and length (prompt fix). * **Provide the source** — paste the doc, attach the file, point it at the real report (data fix). * **Break the task into smaller steps** — a narrower ask resets a rushed or drifted request. * **Start a fresh session** — a chat that has drifted needs a clean desk, not a longer explanation (context-window fix). * **Verify manually against the real source** — this one always applies. **PROMPT check** — the ask was reasonably specific, so that is not it. **DATA check** — it never saw this quarter's actual report. **Diagnosis: data.** **Recovery:** attach the real report and re-ask. ## Verify before you trust Whatever the diagnosis, output does not get trusted, acted on, or forwarded until it is checked against the real source — figures, names, dates, and specifics especially. A wrong answer caught early costs nothing; one forwarded to a client or used in a decision costs real credibility. This one habit is what makes "it goes wrong sometimes" a non-issue in practice. ## Recap * **Prompt well:** context, specific, iterate. * **Skip the theatrics:** false flags do not move the needle. * **When it goes wrong:** diagnose prompt, then data, then model — in that order — then recover. * **The one rule:** verify before you trust. ## Where to go next This is the last core foundations page. Today, run one prompt through the four-step recipe; next time you get a bad answer, run the prompt → data → model check before deciding what to do.