Querri: give recurring data questions a definition you can check

Ask “What are this month’s sales?” every week, and you may get different answers. One person includes all orders, another counts only paid orders, and a third subtracts refunds. The difficult part is deciding which records belong in the calculation before adding them up.

Querri brings questions in everyday language, data preparation, and outputs into one product. You can upload a spreadsheet or connect a source, ask about the data, inspect processing steps, then create a chart or export a prepared table. Operations staff can start with a business question, while analysts can inspect the calculation behind it.

This article focuses on its Library. Alongside files, it organizes business rules, recurring questions, and Views. A View is a saved calculation and the table it produces—for example, spending totals with one row per customer. A rule might say that only paid orders count as sales; the resulting table prepares data using that definition so later answers can reuse it. The original data is not rewritten.

This suits recurring questions. A simple, one-off total may not need a complete Library first. And if your team has not agreed how to handle refunds, AI cannot settle that business definition for you.

The suggested exercise below follows one task: total paid orders by channel for a single month and currency. The small example is easy to check by hand. It is neither real customer data nor a product test result.

1. Create a project and import data. Following the official getting-started guide, sign in, choose + New Project, give it a recognizable task name, then use + to upload CSV or Excel. Prepare three records: web, paid, 100 yuan; web, unpaid, 80 yuan; store, paid, 60 yuan. Include channel, status, and amount, leaving out unrelated fields such as customer names.
2. Define what counts first. Ask: “For this calculation, sales include only orders marked paid. Sum the amount by channel and explain which records you exclude.” If this is also the definition your team wants to retain, explicitly add: “Remember this rule for this orders table: sales include only paid orders. Use that definition from now on.” The Facts & Rules documentation explains that rules established in chat are recorded on the relevant table. Find the entry in the Library’s Facts & Rules, check the attached table and wording, and confirm it is recorded before building a View. A temporary condition in one question is not evidence that a rule has been saved. You can request Show the query to inspect the calculation. This example should retain web 100 and store 60, exclude unpaid 80, and total 160 yuan.
3. Create a View for the result you need repeatedly. On the relevant question, choose + Build a view to answer this, or choose Save this table as a view for a table in chat. Specify that each row represents one channel in one month, so order details are not mixed with channel totals. The Librarian is Querri’s assistant for organizing the Library. It looks for an existing View first and asks when a business decision is needed.
4. Read the assumptions before approving. Check the assumptions, match counts, and exclusions reported after the build. The View is saved to the Library only after you approve it. For this sample, check that there are two channels with amounts of 100 and 60. If the definition is wrong, adjust the request first: a coincidentally correct grand total is not sufficient.
5. Ask a follow-up and deliver the result. Ask “How much paid-order value did each channel contribute?” and check the View named in the answer. To present it, request a chart or export the prepared table as described in the getting-started guide. Before sharing, compare the chart labels with what each row means. Do not rename “paid-order value” as “net revenue,” which would imply a refund policy you have not established.

The Views documentation says later syncs of a connected source rebuild affected Views in dependency order—one table follows the table it is calculated from. A View is not rebuilt from inputs that failed during that sync, and frozen snapshots remain unchanged. The panel shows the build time. Dashboards and projects read fresh Views on their next run, so automatic refresh does not mean every result is current at every moment.

Rules stay with the data

If “paid orders only” exists only in one conversation, the next question may use a different calculation. Querri attaches business definitions to a table and applies them to later questions and newly built Views. Users can also inspect the query’s filters. The discussion can move from “Does this answer look right?” to “Was this rule applied correctly?” That helps only if the rule itself is correct. A changed refund policy calls for checking the old definition too.

Assumptions return to a person before saving

Combining systems often requires deciding what counts as the same customer. Querri’s View documentation shows a matching decision being requested and unmatched data being reported, with saving held until user approval. A person can catch a bad relationship before it becomes a reused result. The tradeoff is that initial preparation still needs someone who understands the business; a generated table alone is not a reason to skip the check.

The question’s scope determines reuse

The anchor-question mechanism organizes related material, rules, and results around a main question. Querri looks for a View that actually covers the question, neither more narrowly nor more broadly. Without a suitable View, it answers from sources and says so. A table containing only paid-order totals, for example, cannot simply answer a question about unpaid orders. This illustrates the boundary: similar wording does not imply the same data scope.

Updates follow dependencies, with a boundary for failure

Preparing a customer-matching table before customer summaries lets several results share the same preparation. Rebuilding in dependency order after a sync can reduce repeated cleanup downstream; skipping a rebuild when its inputs fail avoids treating bad input as a fresh result. A retained result must still be distinguished from a successfully refreshed one. The transferable principle is to make the rules, sources, and update time inspectable alongside the result, so reuse rests on decisions people can explain.