Add and improve context

When an answer reveals a rule your team will need again, save the checked rule as context. Then reload it and test a new answer. The useful cycle is to analyze, validate, capture what you learned, and reuse it. Conversations do not automatically become shared context.

Start with one question, the code and result it produced, and an independently checked answer. You'll need permission to edit workspace files. Publishing a working copy has separate permission checks, and querying a datasource requires its own access. See Users, roles and groups.

1. Decide what should be reusable

Separate a lasting rule from a choice made for one question. If your team always excludes refunded orders from revenue, capture that definition. If someone asked for Germany last quarter, keep that filter in the question.

Open Context and select the datasource used by the analysis. In a workspace that uses changesets, select the working copy you intend to edit or choose New changeset. Check its base and source before changing a rule: an older copy may lack recent shared edits.

Look for an existing entry before adding one. Correct the smallest place that owns the knowledge:

For the file layout and loading rules, see Context files. Avoid copying the same definition into several places.

2. Correct the entry

Suppose the synthetic seven-order example in Analyze your data sums paid September orders in USD using paid_at in UTC, but forgets to exclude refunds. It includes refunded order C and returns 180 USD. Excluding C gives the checked total of 150 USD.

Open the datasource's existing revenue entry under Knowledge. Keep its valid rules and add the refund exclusion. The resulting body can read:

Revenue is the sum of amount for orders where status = 'paid'
and refunded = false. Each row is one order; amount is USD.
Use paid_at in UTC for reporting periods, with an inclusive start
and exclusive end. Do not join other tables for this calculation.

This is a synthetic business definition, not a built-in Querio formula. For your data, check the actual fields, grain, currency and refund policy before saving a rule.

Check Name, Description and Agent sees it. Choose Always for a short rule that should be included whenever this datasource is selected. Only when relevant gives the agent the entry's name, description and path; the agent must choose to read the body when a question needs it. Neither setting applies knowledge from an unselected datasource.

If no suitable entry exists, use Knowledge > New, choose the datasource if prompted, and select Markdown. Give it a clear name and a description of when to use it. Creating the entry writes its initial file to the selected target; save any subsequent body or metadata edits. Knowledge examples guide the agent; loading them does not execute their SQL or Python.

3. Review and save

Edits save automatically a moment after you stop typing. Wait for Saved in the header, then reopen the entry to confirm its body, description, datasource and Agent sees it setting. If you see Couldn't save, use Retry and check what persisted before editing again. If you leave while saving, Querio finishes the save first; if it fails, it asks before discarding your edits.

Where edits save depends on the target:

Check the entry's File information if you need its path. The configured context root can vary; Context files gives the supported layout.

4. Publish a working copy when needed

If you edited a branch and want the team to use the rule, open Changes after saving finishes. Review every changed path, not just the revenue entry. If an inline diff is unavailable, inspect the complete file before publishing.

Publish only when the whole branch is ready. The action depends on your workspace's GitHub connection:

• Without a GitHub connection, select Publish. Querio publishes the whole checkpoint to canonical files. It does not publish only the file you edited.
• With a GitHub connection, select Open PR. Check the returned pull request; canonical files have not changed. Review and merge through your team's Git workflow, then publish the reviewed source. See Use Git and CI sync.

If publication reports an older base, conflict or failure, inspect the current shared files before retrying. A failed publication can leave some canonical files changed. Publishing does not update other existing working copies. See publication and conflicts.

5. Reload and check a new answer

First confirm the analysis session uses the files you edited or the source published through your workflow. An existing environment stays bound to its selected working copy; publishing another copy does not switch it. Files and versions explains these targets.

In the app's analysis conversation, send /reload by itself and wait for Reloaded. It rebuilds context and skills from that session's current directory. It does not publish files, switch working copies or rerun notebook cells.

Ask the September revenue question again. Request the included order IDs, query and a fresh calculation. In Notebook, use Expand code and check the executed query and output:

• The query includes status = 'paid' and refunded = false.
• paid_at covers September 1 inclusive through October 1 exclusive, in UTC.
• Orders A, B and G are included; refunded C is excluded.
• The executed total is 150 USD, matching 100 + 40 + 10, rather than 180 USD.

If the rule is absent, check the saved file, session directory, selected datasource and loading format. A visible entry does not prove the agent loaded it; follow Check what loaded. If the rule loaded but the code still omits the exclusion, correct and rerun the analysis. Loading guidance does not guarantee the agent follows it, and earlier notebook outputs can remain after an edit. Verify an answer covers further checks.

Record the corrected definition, file target, affected question and verification date. Recheck the analysis before sharing it.