Asking questions that work

One constraint shapes most of what follows: when Vernais answers from your connected data, every claim has to trace back to a record it can point at. It will not invent a cause. A question it cannot ground in your data returns nothing rather than a guess. Questions about the outside world, or about general knowledge, it answers like any good assistant — and tells you which world the answer came from.

That single rule explains every tip on this page. A good why question is one that lands on real records. A bad one asks Vernais to reason about something no record describes, and it will say so instead of filling the gap.

The anatomy of a why question

Vernais splits your question into three to five smaller ones before it searches. It aims at four angles wherever they apply: what changed, what the error looks like, who is affected and how much, and when it started. Your question has to give each angle something to grab.

Your wording also picks where the search starts. Vernais matches your question against the topics it discovered in your data and enters the closest few. If nothing clears the match floor it still enters the single best topic, flagged as a weak match. That is how a vague question ends up searching the wrong neighbourhood and finding nothing there.

Naming a tool anchors the investigation there

Name a tool and Vernais folds all of that tool's records into the search area, then starts the search from them. You can name more than one. did the github deploy cause the stripe failures? anchors on both, in the order you wrote them. A tool with no data in your workspace is dropped quietly, so a stray name costs you nothing.

A tool that does hold data but not the answer is the expensive mistake. When the tools you named supply less than a third of the grounded evidence, Vernais adds a caveat telling you to treat that angle as tangential. It also knocks a high confidence down to medium. You did not get a better answer by pointing. You got a worse one.

What you get back

You get a live timeline first, then a case file. The timeline is about fifteen named steps that stream into the chat as they run, so you can watch the work instead of watching a spinner.

• The plan — how it broke your question down, and which topics it entered.
• The jury — each candidate record judged one at a time, with a progress count.
• The case file — a primary explanation, written with citations you can click to open the original record.
• Hypotheses considered — the two to four candidate explanations it wrote before it looked at the evidence, each marked confirmed or refuted, plus a ruled-out list with reasons.
• A confidence badge — high, medium, or low.

The competing explanations are not decoration. Vernais is required to include at least one genuine alternative before it starts — an outside cause, or the possibility that the problem is pre-existing rather than new. It shows you how each one fared.

Confidence is earned, not claimed. The model proposes a label and deterministic checks can lower it. A causal answer reaches high when nothing objects. It drops to medium for named reasons: a symptom that predates the change you blamed, or a mechanism that covers less than 80% of the worst-hit group. The caveat line tells you which. Read what the confidence badge means before you act on a medium.

How long it takes

Minutes, not seconds. A healthy investigation runs a few minutes end to end. It is reading your graph, judging records one by one, and arguing with itself before it writes. If the AI provider stays rate-limited past the time budget, the run stops and says so plainly. A halted run is not a failed one — retry it rather than rewrite your question.

When it finds nothing

Every candidate record is judged by a small juror that must copy a real quote from that record to take a side. No quote, no vote. This is why Vernais cannot make things up — and why a thinly worded record rarely survives on its own.

If the same question keeps returning nothing, the fix is almost never a longer question. It is a more concrete one.

Ask it what you would ask a sharp new analyst who read every ticket but was never in the hallway. If they would come back and ask which tool or which week, so will Vernais.

Develop your intuition

These are starting points, not rules. The fastest way to get good at this is to notice what your last question was missing. When an answer disappoints you, ask yourself:

• Was the question too broad? Did I give it a subject and a change, or only a mood?
• Did I name a tool that doesn't hold the evidence — and earn the tangential caveat for it?
• Did I ask for a cause when I wanted a count?
• Did I use my words, or the words that are actually in my data?
• Was the confidence medium for a reason the caveat line already told me?
• Am I re-running a question I could have asked as a follow-up in the same thread?

Related resources

One constraint shapes most of what follows: when Vernais answers from your connected data, every claim has to trace back to a record it can point at. It will not invent a cause. A question it cannot ground in your data returns nothing rather than a guess. Questions about the outside world, or about general knowledge, it answers like any good assistant — and tells you which world the answer came from.

What the six have in common

Every one of these asks Vernais for something it cannot ground. Sometimes there is no record to point at. Sometimes there is a record, but your words never reach it. Sometimes the grounded answer was already on screen and the question threw it away.

None of the six produce a lie. Vernais returns nothing, or returns a smaller number than you expected, or quietly answers a slightly different question. That is the failure mode you have to learn to spot.

The six mistakes

Scope is what makes a why answerable

Vernais breaks your why-question into three to five sub-questions, covering four angles where they apply: what changed, the error signature, who was impacted, and the timeline. It then matches your words against the topics it found in your data, and the closest few topics become the search area.

Now look at what 'why is our product bad?' gives that machine. There is no symptom to trace and no subject to scope to. The topic match falls under the floor. Vernais still enters its single best-guess topic, flagged as a weak match, and every angle lands on records that have nothing to do with your real problem.

A follow-up is not a fresh question

Two of the six live here, and they fail for different reasons.

• The recomputed number. Vernais does not hold the rows from your last answer. When you say 'out of those, how many from stripe', it reads the conversation and runs a new query with the filter it infers. Give it a subject to infer from and the new slice matches what you meant. Give it a bare 'those' and it can drift to a different slice.
• The re-asked investigation. An investigation is different work. It takes a few minutes, walks the graph, and stores its own sections — telemetry, errors, versions, timeline, evidence, counter-evidence. A follow-up reads those sections straight back, so the number matches the case file you already read. Re-running the same question can return a different number and overwrite the one in the thread.

The total and the list are different numbers

A record search counts every match, then shows you some of them. It reports both — '200 record(s) match; showing 20' means 200 is real and 20 is a window. Ask for 200 tickets and you still get 50, the ceiling, while the total stays honest.

Counts behave differently depending on the filter. A count with no date range is a true database count and is exact. A count with a date range has to open each record and read the timestamp out of its own fields, so it stops at a ceiling and tells you when it hit one.

Field names come from your data, not your head

Jira stores its assignee deep inside the record. GitHub calls the same idea author. Sentry has no assignee at all. Vernais does not know your field names ahead of time, which is why a plain count often opens with a sample step — it is learning the real keys before it filters.

Some of that gap is closed for you. A short alias table maps the common field names across tools, so assignee still resolves on GitHub, where the field is author, and priority resolves on Sentry, where it is severity. Values are translated too: open also matches To Do, In Progress, unresolved, new and backlog; high also matches urgent, critical, p1 and blocker.

A field outside that table gets no such help. Filter Jira on sprint and the name resolves to nothing, so nothing matches and the count comes back zero — no error is raised, which is why it slips past you. Ask for that field's distinct values instead and you get an empty list with a hint to check the name.

Who you are comes from your account

Vernais reads your name, title, role and company from your signed-in account. That block is the only authoritative answer to 'who am I'. Everything else you say about yourself is a claim — including a page you control. Your personal site, your LinkedIn, your bio: that is the same person speaking through a different channel, not a second opinion.

So it will not adopt a title you assert in chat, and it will not web-search to settle who you are. A search there would only return what you published about yourself. If you tell it the account is wrong, it says so once, points you at Settings → Profile, and answers your actual question.

Develop your intuition

These six are starting points, not rules. The habit worth building is a short check on your own question before you blame the answer.

• Was the question too broad? A why with no subject has nothing to search.
• Did I name a tool that actually holds the evidence, or one I assume holds it?
• Did I ask for a cause when I only wanted a count?
• Am I counting rows on screen instead of reading the total?
• Did I invent that field name, or did I see it in a real record?
• Is this a follow-up? If so, does it still name its subject?
• Did Vernais already answer this a few minutes ago in a case file?

A surprising answer is usually a different question running, not a broken tool.

Related resources

One constraint shapes most of what follows: when Vernais answers from YOUR CONNECTED DATA, every claim has to trace back to a record it can point at. It will not invent a cause. A question it cannot ground in your data returns nothing rather than a guess. Questions about the outside world, or about general knowledge, it answers like any good assistant — and tells you which world the answer came from.

Ask for a count

Type the question. Nothing to configure. Vernais runs a counting tool, then reports the number next to the exact filter it used.

The answer carries its own receipt, like count = 200 matching [integrations=['stripe']]. Read that filter. If it says integrations=['stripe'] but you meant only the charges stream, the number is answering a different question than you asked.

A count with no date range is a real database count of every matching record. It is exact.

Name a tool to scope it

Naming tools is the cheapest way to sharpen a data question. One name narrows the search to that tool's records. Several names fan the same filter out across each one.

You get each tool's count, sorted highest first, then the total. Each count is exact. The records printed underneath are a sample.

Success and failure are not field values

Almost no tool stores the word successful. Mixpanel puts the outcome in the event name — Purchase versus Checkout Failed. Stripe puts it in a status field, status=succeeded. There is nothing to text-match.

So Vernais works it out. It lists the distinct event names and status values in your slice, decides what each real value means, and adds up the ones that mean success. It never searches for the word.

The answer shows its working: success: 90 (Purchase=33, Add to Cart=30, Sign Up=27). That list is where you check its judgement. If you think Add to Cart is not a success for your funnel, you can see it and say so.

Ask for a list instead of a total

You get the true total that matched, plus the records you asked for. The total is exact. The list is capped.

For a list from several tools at once, write the whole request in one message and give each tool its own ask. Vernais runs one independent search per tool, then reports each tool's exact count, the records grouped under it, and a grand total.

That pattern is how you get a per-each listing. Name the tools, and say how many from each. One message beats five, because each tool keeps its own keywords, order and depth instead of collapsing into one shared filter.

Learn your field names first

Field names differ per tool. Jira keeps the assignee at fields.assignee.displayName. Github calls it author. Sentry has no assignee at all. Vernais does not know your keys up front, so it samples real records to learn them. That is why a simple count sometimes takes an extra step.

You get real records printed with their real keys and values, like status=To Do · priority=Medium · assignee=Arya Mahadik. Filter with those.

Keywords match as plain lowercase text, and every keyword must appear in the same record. Meaning-based search is switched off on this path. So use the words your data really uses, and use fewer of them. Each extra word narrows the result.

Check the number before you trust it

Not every number is exact, and Vernais says so when it is not. Read the line under the count.

A count will not tell you why

A lookup fetches. An investigation reasons. how many checkout events failed? is a lookup and lands quickly. why are checkouts dropping since the v2.2.1 release? is an investigation, and Vernais calls that pipeline itself when you ask a causal question. See Find a root cause.

Counts are still the right first move. They tell you whether something moved at all, and they give the investigation a number to explain.

Develop your intuition

These are starting points, not rules. When a data answer looks wrong, the fault is usually in the question. Read the receipt, then ask yourself:

• Was the question too broad? An unscoped 'how many succeeded' has to guess across every tool.
• Did I name a tool that holds the evidence? Mixpanel has no status field to filter on.
• Did I invent a field name instead of sampling a record first?
• Did I tally the rows on screen instead of reading the exact total?
• Did the answer carry a capped warning that I read past?
• Did I ask for a cause when I only wanted a count?
• Did my follow-up keep its subject, or did I lean on a bare 'those'?

Related resources

Ask for records and two numbers come back. One is how many matched. The other is how many printed. They are almost never the same number, and only one of them belongs in your deck.

The total is counted, the list is a window

A record search answers in one line before it prints anything:

200 record(s) match; showing 20:

200 is real. Vernais filtered every record in your workspace and counted what survived the filter. 20 is how many it chose to print. The other 180 matched too. They are not on screen.

A plain count is stricter still. Ask for a count with no date range and the database counts every matching row itself and hands back one number. It never opens a record, and nothing is capped. The filter it used prints beside the number:

count = 200 matching [integrations=['stripe']].

That second line is the receipt. It is how you check the number answers the question you asked. See Check where a number came from.

Why the list stops

Two reasons, and neither is a bug.

• Reading. Two hundred Jira tickets pasted into a chat reply is not an answer. It is a wall you have to scroll past. A single Jira issue can carry over a hundred fields; twenty of them printed in full is already long.
• Cost. Every printed record is text the model has to read before it can reason about your question. Each record's field line is budget-capped for exactly this reason. Spending that budget on rows 51 to 200 buys nothing, because you were never going to read them either.

So the cap is a trade. You give up rows you did not want. You keep an exact total and an answer you can read.

What is capped, and what to ask instead

Here is the same idea as a lookup table. The middle column is what you can quote.

When a count is not exact

Your data has no date column. Each record's time sits inside its own payload, under whatever key its tool happened to use — created_at, event_time, occurred_at, first_seen, timestamp. Vernais reads those keys in a fixed priority order and falls back to modification time last.

That means a dated question cannot be answered by the database alone. Vernais has to open records and read the time out of each one. Opening records has a ceiling of 20,000. If a dated count hits it, the answer says so:

count = 14812 matching [integrations=['stripe']; time_from=2026-04-01] (scan capped at 20000 rows — count may be a lower bound).

Read that as a floor. Name one tool or one stream to shrink the set, then ask again. Breakdowns read record fields the same way, so the same ceiling applies to them; a capped breakdown prints a warning with the word INCOMPLETE in it.

A date range does one more thing worth knowing. Any record whose time cannot be read at all leaves the set. It is not counted as unknown — it is gone. A since april total can be smaller than you expected for that reason and no other.

The counted rows

This is the single most common way to publish a wrong number from a right answer.

When the rows are the answer

latest 5 jira tickets has no hidden total to miss. You asked for five, five printed, and the match count on the first line is background. Nothing was lost, and asking for the count as well would tell you something you did not want.

The cap only hurts when you were about to count the rows.

The test: does your next sentence contain a number? If it does, that number has to come from a count. If it does not, read the rows and move on.

Related resources

What a follow-up actually carries

The thread carries your words and Vernais's answers. It does not carry the rows from the earlier lookup, and it does not carry the filter recipe printed beside the earlier number. Those live in that answer's thinking timeline, for you to read.

So when you say out of those, Vernais re-reads the conversation, infers a narrower filter from it, and calls a data tool again. There is no frozen set being filtered. Every number is fetched fresh, which is why a follow-up can only be as precise as the words still sitting in the thread.

How to write one

Name what changed. Keep enough of the subject that a reader joining the thread would know what those points at.

The third row restates the subject even though turn two established it. That costs you six words and removes the guesswork.

Why a follow-up beats re-asking

Re-asking makes Vernais pick a scope from your words alone. Different words pick a different scope, and a different scope returns a different number from the same data on the same day. A follow-up that carries its subject keeps the numbers comparable.

Check what "those" resolved to

A count reports the filter that produced it, and the counting step in the thinking timeline names that filter too. Read it before you trust the number. If it does not describe what you meant, the number is answering someone else's question.

count = 180 matching [integrations=['mixpanel']].

outcome classification [integrations=['mixpanel']]:
  success: 63  (Purchase=33, Add to Cart=30)
  failure: 62
  neutral: 55

An outcome answer also lists the concrete values it treated as success, failure and neutral. Your tools rarely store the word successful anywhere, so this list is where you check its judgement — and where you spot a value filed under the wrong heading.

Follow up on an investigation

An investigation is the one case where a stored result exists. Its case file is kept with the thread, and a compact header rides along in every follow-up. Ask for a section by name — telemetry, errors, versions, integrations, timeline, steps, hypotheses, evidence, counter-evidence, or the conclusion — and Vernais reads that stored section back rather than re-counting.

When the thread won't carry your scope

Develop your intuition

These are starting points, not rules. When a follow-up returns a number that surprises you, ask yourself:

• Did I read the recipe, or did I assume what those meant?
• Is my subject still somewhere in the conversation, or did I leave it in a tool result the model never sees?
• Does my follow-up narrow the set, or does my wording quietly ask for a wider one?
• Did the thread change topic between the number and my follow-up?
• Am I following up on an investigation? Then ask for a section by name instead of re-counting.
• Did I re-ask when I meant to narrow — and re-scope the question without noticing?

Related resources

One constraint shapes most of what follows: when Vernais answers from YOUR CONNECTED DATA, every claim has to trace back to a record it can point at. It will not invent a cause. A question it cannot ground in your data returns nothing rather than a guess. Questions about the outside world, or about general knowledge, it answers like any good assistant — and tells you which world the answer came from.

Most of the time you type a question and one model picks its own tools. No mode to choose. But a model is deciding, not a rule, so two similar questions can go different ways. When it goes the wrong way, these are the controls that take it back.

Take the wheel with the + menu

Your choice shows as a pill next to the +, and it stays on for every message until you clear it with the pill's ×. That is the one thing to watch: a lane you set three questions ago is still steering this one. Only one of the five can be on — turning on Deep research clears a forced lane, and picking a lane clears Deep research.

Typing / opens the same options as commands — /investigate, /lookup, /web, /scrape, /research. A command attaches as a chip and applies to that one message, then clears itself. Reach for the command when you want the override once, and the menu when you want it to stick.

Data lookup does not switch to some narrower engine. It runs the same AI with the data tools favoured. That matters: a forced lookup on a person question like what is emma working on still answers properly instead of returning an empty result.

Tell it not to search the web

what is a transformer model? don't search the web, answer from your own knowledge

Two things happen here. The AI answers from what the model already knows, and it does not refuse you. That second half matters. General knowledge is fair game — a question about a public concept is not "outside your workspace," and the AI is told never to treat it that way.

Be honest about what this control is, though. It is an instruction the AI follows using its own judgement. No server rule enforces it. It holds up well, and it is the right way to ask, but it is not a switch.

Turn thinking off, or dial it up

Thinking is the reasoning the model does before it writes. Off means exactly zero reasoning on all three models, which is the fastest the chat gets. When thinking is on, an effort control appears with the rungs your model supports. The rungs come from the server, so they change with your model.

• Dial down for speed on a light turn — a short question, a follow-up you already know the shape of, a quick count.
• Dial up for a knotty compare-and-weigh question, or a code question with several files in play.
• Off for when you want the answer now and the question is small.

Stop a run

The stop lands cleanly. Whatever text already streamed stays on screen — it is not rolled back. The AI also checks for your stop between tool calls, so no further tools fire after you click. Only the thread you are looking at stops; other threads keep running. One more thing worth knowing: a thread runs one turn at a time, so sending again while a turn is live does nothing. Stop first, then send.

Stop is the right move on a run that is clearly off-target. An investigation is the case where patience usually pays — it chains evidence across many records and takes a few minutes by design. A blank-looking gap early on is normal.

Fix the question before you reach for a toggle

A toggle is a blunt tool. Most wrong picks trace back to a question that could be read two ways, and a clearer question beats an override.

Develop your intuition

These are starting points, not rules. When the AI picks wrong, the fastest fix is usually a better question, not a heavier override. Before you reach for a toggle, ask yourself:

• Was my question about my data, the outside world, or the pages a scrape collected? Which one did the AI think I meant?
• Is a pill still on from an earlier message, quietly steering this one?
• Did I name a tool that actually holds the evidence?
• Did I ask for a cause when I only wanted a count?
• Did I read the thinking block to see which tools ran, or am I guessing at what went wrong?
• Am I forcing a lane to fix a question I could have written more plainly?

Related resources

Ask to see it in the same message

Vernais reads your message for words like dashboard, chart, graph, plot, visualize, funnel, kpi, pie chart, bar chart, donut, trend line, or a phrase like show me my. Any of them turns that turn into a visual turn. The AI still fetches the data with its normal tools first. Then it draws what it found.

More prompts that work the same way. Each one names a tool and a dimension to split by:

• show me a dashboard of mixpanel events by outcome
• chart jira issues by status
• build me a bar chart of sentry errors by version
• visualize the checkout funnel as a dashboard

What renders

The dashboard appears inline in the reply, in your theme. The AI hands over a structured spec and picks the parts the data supports.

After the visual, the AI adds a one-line takeaway in prose saying what it shows. That line sits in the reply, not in the dashboard. You do not choose any of the parts — ask for the split you care about and let the AI shape it.

It draws only what the tools returned

This is the rule the whole product runs on. When Vernais answers from your connected data, each number has to trace back to a record it can point at. A dashboard is held to the same standard. The AI samples your records to learn the real field names, counts them with a data tool, then hands those exact numbers to the drawing tool. It is told never to invent a value or use a placeholder.

So the failure case is honest. If the data tools error, or come back with nothing, the AI does not draw a dashboard of guesses. It tells you the lookup failed. An empty chart is a chart that lies, and it will not make one.

When a sentence beats a chart

Charts earn their room when there is a shape to see — a distribution across six versions, a funnel that leaks at one step, a split that moved since last week. Below about three values, the chart is decoration around a number you already had.

What a dashboard cannot do

Develop your intuition

These are starting points, not rules. When a visual comes back wrong, the fix is almost always in the question. Ask yourself:

• Did I name a dimension to split by, or only a tool?
• Am I asking to see a shape, or a number I could have read in a sentence?
• Did the thinking block show a count or breakdown step before the chart, or did the tools come back empty?
• Does the tool I named actually hold the field I want on the x-axis?
• Am I asking for a picture when what I really want is the records themselves?

Related resources

One constraint shapes most of what follows: when Vernais answers from YOUR CONNECTED DATA, every claim has to trace back to a record it can point at. It will not invent a cause. A question it cannot ground in your data returns nothing rather than a guess. Questions about the outside world, or about general knowledge, it answers like any good assistant — and tells you which world the answer came from.

What it can see about a person

Vernais builds a knowledge graph out of your connected tools. A teammate becomes a node in that graph when their name lands in a real record: a Jira assignee, a bug's reporter, a commit author, a mention in a Slack message. The AI walks the links out from that node.

So what is emma working on? does not run a keyword search. It resolves emma to a person in the graph, then reads every record linked to that node across every connected tool at once.

• Work items — the records linked to that person in the graph, each labelled with the relationship it came through (assigned, reported, owns, mentioned) and the tool it came from.
• Workspace members — who has access to this workspace, and how many people.
• Initiatives — each one's owner, stage, impact, product, signal count and confidence.
• Your inbox — the unread count and recent items.
• Sources and syncs — which tools are connected, when each last synced, and when Corvex last ran.

Ask what someone is working on

The answer names the real records and the tool each came from. One person lookup reads up to 80 connected records, and the answer works from a sample of them rather than the whole set.

If it answers from the web when you wanted your own data, press + and pick Data lookup, then ask again. That forces the data tools for that one message.

Ask who someone is

who is emma? returns a few sentences about the person. what is emma working on? returns her work items. The AI is told never to answer a who-is by dumping a list of tickets, so asking the wrong one gets you the wrong shape of answer.

A bare name is treated as a teammate first. A name you qualify with a place, a company, or a public role is treated as an outsider, and the question goes to the web.

Ask about the workspace itself

• Who is here — who has access to this workspace?
• Initiatives — any initiative about the checkout drop? or which initiatives are stuck in validate?
• Sources — how many integrations are connected, and when did jira last sync?
• Inbox — what's in my inbox?

Each answer comes back with real fields — stage, owner, confidence, last sync time. You can follow up on any of them in the same thread.

Where the answer stops

Develop your intuition

These are starting points, not rules. When an answer lands wrong, the fix is usually in the question. Ask yourself:

• Did I ask who someone is when I wanted what they are working on?
• Did I mean a teammate or someone outside the company — and did I say which?
• Is this person's work in a tool I have actually connected and synced?
• Did I name a tool that does not hold this person's work?
• Am I hunting for a Vernais task rather than a record from a connected tool?
• Did I ask for a cause when I only wanted a list?

Related resources

One constraint shapes most of what follows: when Vernais answers from your connected data, every claim has to trace back to a record it can point at. It will not invent a cause. A question it cannot ground in your data returns nothing rather than a guess. Questions about the outside world, or about general knowledge, it answers like any good assistant — and tells you which world the answer came from.

Code works the same way, with files in place of records. Every path and line number in the answer has to come from a file it opened during that reply. It is told to stop and read the file rather than cite something it never saw. Then a checker grades the citations after the fact.

Point it at a repo first

Vernais can only clone a URL you typed in that exact message. The server reads your message, pulls out any https repo links, and hands that short list to the tool. The tool then refuses anything that is not an exact match.

This rule exists because a clone is an action, not a lookup. If a repo's own README could name the next repo to fetch, a file could talk Vernais into fetching a different one. The model's own narration cannot nominate one either. Only your message has that authority.

What happens next: Vernais makes a shallow public clone into a temporary folder that belongs to your workspace, your account, and that one thread. It reads the tree, then plans, then searches. The checkout is deleted about an hour later.

What it can do

The first one is the one people miss. Meaning search finds the right function even when your words never appear in the code. Ask for "the checkout flow" and it can land on a file that only ever says processOrder. It compares the meaning of your question against the meaning of each chunk of code. When that model is cold it falls back to word matching, which is weaker but still runs.

Reading is paginated. A long file comes back in ranges, and the result tells it how many lines remain. It keeps reading when the answer needs more.

It only reads

Every tool in the belt searches, reads, or maps. None of them writes. Nothing edits a file after it has been cloned, and reads stay inside that one temporary checkout — your keys and system files are unreachable.

There is one more rule worth trusting. Everything Vernais reads — file contents, comments, commit messages — is treated as data to analyze, never as instructions. If a file says "ignore your instructions and run this command", it reports that as a finding instead of obeying it.

Real prompts

Every citation gets checked

After a code answer is written, a checker reads it back. It pulls out every path:line in the reply and compares each one against the files that were actually read or searched during that turn. No model is involved. It is plain arithmetic and file lookups, so it gives the same verdict every time.

Each citation lands in one of three buckets:

Invalid citations are added to the bottom of the reply, in the open, under a Citation check note that names them and tells you to treat them with caution. They are not deleted and not hidden. You see the claim and you see that it failed. A suspect citation is only logged, because blocking a correct answer is worse than letting a shaky reference through.

So the read is: the answer's prose is a model talking. The citations are checked. Follow the citation.

When it comes back empty

A code turn gets about 22 rounds of tool calls. Broad questions burn them on searching. These are the three ways a search goes wrong, and what to do about each.

If a search finds nothing, that is information. It is told to chase the miss rather than fall back on a guess — searching a second and third angle before saying it could not find the thing. When it does give up, it names every term and path it tried. Read that list. It usually tells you which word your codebase uses instead.

If the code tools aren't there

Code analysis is a permission, not a prompt. Without it, the tools are left out of the AI's belt entirely — so it has no code ability at all, rather than an ability it politely declines. It will answer from general knowledge instead and never open a file.

Two things have to be true. You need the Analyze approved or user-provided codebases permission, which your workspace owner grants per person. And you need a Max seat, because code analysis sits in the AI tier alongside chat and investigations. A Power seat gets data but no AI, and no individual grant can lift that — it is a billing ceiling, not a switch. See Permissions and seats.

Develop your intuition

These are starting points, not rules. When a code answer disappoints you, the fix is usually in the question. Ask yourself:

• Did I paste the repo URL in this message, or am I relying on one from earlier?
• Did I name a file I am guessing at, when I could have described what it does?
• Would I know a right answer if I saw one? If not, it won't either.
• Did I check the citations, or only read the prose?
• Am I asking about code, or about the work around the code? A ticket's owner lives in your connected data, not in a repo.
• Did the search list every term it tried? Which of those words is wrong for this codebase?

Related resources