How to Configure Contextflo for Repeatable, Reliable Queries

An LLM does not know your business metrics or your terminology. Contextflo is where you tell it, so that anyone can ask "what's GMV for last week" and get the same answer as everyone else who asks.

There are three ways to encode that knowledge, and they solve different problems:

1. Metrics: business measurements with a SQL definition
2. Business concepts: plain-language definitions of your terminology
3. Saved queries: proven SQL patterns the model can reference

When someone asks a question, the model calls find-related-resources and Contextflo returns whatever metrics, concepts and saved queries are semantically similar. Those come back before any SQL is written, which is the whole point: the model is working from your definitions rather than inferring one from column names.

1. Metrics

A metric is a business measurement with its SQL definition attached. When someone asks about MRR, the model uses your calculation rather than a plausible-looking guess.

Monthly Recurring Revenue (MRR)

Sum of active subscription amounts at month-end.
Excludes trials, one-time purchases, and paused accounts.

SELECT
  DATE_TRUNC('month', billing_date) AS month,
  SUM(subscription_amount) AS mrr
FROM subscriptions
WHERE status = 'active'
  AND is_trial = false
  AND billing_type = 'recurring'

Notice the exclusions. Those three lines are the actual content of the definition, and they are exactly what a model guessing at your schema would get wrong. Every metric you write should say what it leaves out, not just what it counts.

Good candidates: revenue metrics like MRR, ARR and GMV, user counts like DAU and MAU, conversion rates, retention rates.

2. Business concepts

Concepts are plain-language definitions for terms specific to your company. No SQL, just the explanation.

Enterprise Customer

Anyone with ACV >= $50,000, OR anyone on an Enterprise plan.
Lives in 'enterprise_accounts' table, not 'customers'.

Churned Customer

Subscription ended and not renewed within 14 days.
Paused subscriptions don't count as churn.

Both of these encode something no schema can tell you. The first says where the data actually lives, which stops the model reaching for the obvious-but-wrong table. The second sets a boundary (fourteen days, and pausing is not churning) that two people in your company would otherwise answer differently.

Good candidates: customer segments, user states, date conventions like fiscal year, and anything you have had to explain to someone twice.

3. Saved queries

Saved queries are SQL patterns that already work. The model uses them as a starting point instead of writing from scratch.

Customer Lifetime Value

SELECT
  c.customer_id,
  c.email,
  COUNT(DISTINCT o.order_id) AS total_orders,
  SUM(o.amount) AS lifetime_value
FROM customers c
LEFT JOIN orders o ON c.customer_id = o.customer_id
WHERE o.status = 'completed'
  AND o.is_refunded = false
GROUP BY c.customer_id, c.email

The is_refunded filter is the reason to save this one. It is easy to forget, nobody notices when it is missing, and the number is simply wrong in a way that looks fine.

Good candidates: queries with tricky joins, filters that are easy to forget, and anything that took several attempts to get right.

Where to start

You do not need all three on day one, and writing definitions in the abstract is a good way to waste an afternoon on terms nobody asks about.

The cheaper path is to let real questions tell you. Ask a handful of things you already know the answers to. Wherever the model gets it wrong, that gap is a metric, a concept or a saved query, and you will have written the four definitions that matter before you would have finished guessing at forty.