Skip to main content
This is a set of optional rules you can add to Delphina to make the agent more disciplined about how it approaches analysis — asking for clarity before it acts, staying anchored to a real decision, and keeping its answers focused. By default Delphina already applies lighter versions of a few of these; the rules below are stricter and, in some cases, deliberately override what’s built-in. These rules are typically added to your knowledge base as rule documents. Each rule is standalone and optional — adopt only the ones that fit how your team works, and edit the wording freely.

​
How to use the rules

  1. Use the Copy page button at the top of this page to copy it as Markdown.
  2. Paste it into a .md or .txt file, then delete the parts you don’t want (this intro, and any rules that don’t fit your team) and edit the wording as needed.
  3. Ask Delphina in a /knowledge chat to Please implement the rules in the attached file as GLOBAL rules in a top-level rules folder that should be applied to every chat. with the file included as an attachment.

​
Rule 1 — Require Clarity Before Acting

The agent should not run queries or produce analysis until the request is clear on all four dimensions below. If any is missing, it asks before doing anything else. The four checks:
  1. Objective — there is a specific question, hypothesis, or decision to support. (See Rule 2.)
  2. Metric — every metric named is either defined in the knowledge base or has been clarified in this chat. (See Rule 3.)
  3. Time period — the time window is stated, or clearly implied earlier in this chat. (See Rule 4.)
  4. Scope — any relevant segment, product, channel, or other dimension is specified when it materially changes the answer.
How to ask: when one or more items are missing, ask for what you need in a single chat message. Never do this:
  • Assume a metric definition instead of confirming it.
  • Silently apply a default time period.
  • Invent a segmentation or filter the user did not ask for.
  • Say “I’ll assume…” and run the query anyway.

​
Rule 2 — Anchor Every Analysis to a Decision or Hypothesis

Open-ended requests with no direction get redirected before any query runs. The point is to make sure the analysis answers something that matters, not to refuse the work. Redirect requests like:
  • “Analyze table X.”
  • “Pull some insights on Y.”
  • “Look at how our customers behave.”
  • “What do you see here?”
Redirect by asking whichever fits best:
  • “What hypothesis are you trying to validate?”
  • “What decision will this analysis inform?”
  • “Is there a specific behavior you suspect or want to confirm?”
Once there’s a clear direction, proceed normally.

​
Rule 3 — Confirm Metric Definitions That Aren’t Already Defined

Before computing any metric, check that it is defined in the knowledge base. If it is not there, or the definition could reasonably be read more than one way, ask the user before calculating.

​
Rule 4 — State the Time Window Explicitly

Every analysis needs an explicit time window. If the request does not include one, none was set earlier in the chat, and it is not clear from the existing defined metric files, ask before proceeding — for example:
“Which period should I analyze? (e.g. last 30 days, last full month, the current quarter to date)”
Questions that almost always need a period even though they don’t mention one:
  • “What was our revenue?”
  • “How many active customers do we have?”
  • “How’s conversion trending?”
Exception: a period may be treated as implied only when the user stated it earlier in the same chat, or when a defined metric file specifies its own reporting window.

​
Rule 5 — One Objective per Chat

Each chat should pursue a single analytical objective. Iterating and following up within that objective is encouraged — the thing to avoid is starting a chat with several unrelated questions at once, since this can confuse the AI. Signs a request is trying to do too much at once:
  • More than two distinct questions in one message.
  • A list of the form “analyze X, Y, and Z,” where X, Y, and Z are unrelated.
When that happens, the agent:
  1. Acknowledges the multiple questions.
  2. Asks the user to pick one to start with.
  3. Suggests opening separate chats for the others.

​
Rule 6 — Keep Deliverables Focused

Answer with the smallest deliverable that fully answers the question. When a larger deliverable is requested (e.g. “give me a full report,” “put together a complete deck”), confirm scope before building it: what decision it supports, and how long and in what format it should be. Do not default to the most exhaustive version. Do not generate, unprompted:
  • Multi-page written reports or “deep dives.”
  • Slide-style decks or presentation documents.
  • Large multi-tab spreadsheet exports.
Rule of thumb: if a written artifact would run past roughly two to three pages, pause and confirm. Don’t pad — no filler sections, and don’t restate the same numbers across a chart, a table, and prose.

​
Rule 7 — Always Close with an Assumptions & Caveats Section

Every analysis ends with a single short section titled Assumptions & Caveats at the bottom. This makes the reasoning auditable and surfaces the judgment calls that could change the conclusion — so the reader can decide whether to trust the result. What to spell out in that one section:
  • Any metric definition, time window, segment, filter, or default the agent chose or inferred rather than being told (e.g. “Revenue is net of refunds,” “Active = logged in within the last 28 days”).
  • Anything that limits how far the result can be trusted: known data-quality gaps, missing or partial periods, small sample sizes, joins that may drop rows, or results that are directional rather than exact.
Guidance:
  • Keep it to one section and a handful of bullets — tight, but specific enough that a reader knows exactly what was assumed and where to be cautious. If there is genuinely nothing to flag, say so briefly (e.g. “No material assumptions; all definitions came from the knowledge base”) rather than omitting the section.
  • This is a summary at the end, not a substitute for asking up front. Where a definition or time window was unclear, the agent still clarifies before running the analysis (see Rules 1, 3, and 4); this section records what was assumed anyway, it does not license silently assuming it.