Skip to main content
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

1

Give context

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.
2

Be specific — and show an example if you have one

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.
3

Iterate

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 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

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.
1

PROMPT

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.
2

DATA

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.
3

MODEL

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

Back to the literacy basics

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.