How Business Users Can Correct AI Agent Context Without Changing Code

Business users can correct an AI data agent's knowledge without changing code when the correction concerns editable business context. Capture the disputed answer, identify the authoritative source, and decide whether the change is a clarification, a scoped business rule, or a proposal to change a governed metric. Review that decision before making it shared context, then check the resulting answer.

Orion by Gravity supports business-context editing and review through Knowledge Base pages. The useful operating question is what to approve: a person who says “customer means something different to my team” may have identified a valid departmental definition, an ambiguous question, or a calculation that needs engineering review.

Last reviewed: October 7, 2026. The workflow and examples below are recommendations, not a report of a customer implementation.

What is a business-context correction?

A business-context correction is a reviewed change to the information an agent uses to interpret a business question. It can clarify terminology, identify an authoritative source, explain an exception, or establish which approved metric applies to a particular task.

Correcting context is different from accepting the user's desired answer. A useful submission explains why the previous interpretation was wrong and supplies evidence for the replacement. “The number should be higher” is an incident report; “this campaign report counts prospect accounts, while the answer used paying accounts” identifies a possible interpretation error.

Keep the reported answer separate from the proposed rule. That separation lets the reviewer accept the business observation without approving every suggested fix. The reviewer may instead request clarification, narrow the rule, or route the incident to the data owner.

Which corrections can business users make without code?

Business experts can usually propose terminology, operating notes, source references, and task-specific guidance through an editable knowledge system. Changes to calculations, joins, filters encoded in a governed metric, warehouse policies, and tool routing still belong with their technical owners.

Use this correction-routing matrix before editing shared context. These are recommended decisions; the labels are not an Orion feature or configuration format.

A no-code editor makes a correction easier to submit. It does not decide which source owns a rule. That decision should remain explicit even when the platform can turn a chat message into a proposed edit.

How do you avoid changing the metric when you only meant to clarify a term?

Preserve the authoritative calculation and change the mapping around it. The dbt Semantic Layer centralizes metric definitions on existing models and uses MetricFlow. When that is your governed metric system, keep calculation changes in its review process.

Suppose “customers” could mean paying accounts, campaign prospects, or active product users. If those measures already exist and are approved, a business page can explain which one applies to a marketing report. If the requested population requires a new filter or calculation, the proposal needs a metric owner before it becomes reusable guidance.

Give distinct measures distinct names. Avoid a broad instruction such as “always use Marketing's customer definition.” A safer proposed rule names the task, population, approved measure, and conditions that require clarification. The context can point to the governed definition instead of copying a formula into prose.

If your stack uses another semantic or metric system, apply the same ownership boundary there. Semantic Layer vs. Business Context explains the broader division of responsibilities.

What should a business user submit for review?

Use a correction disposition sheet to connect the observed mistake to a specific decision. Fill it in before approving shared context. The sheet is an original operating template, not a required Orion schema.

The disposition is the important field. It records what was accepted and why. For example, a reviewer may accept “the campaign question was misinterpreted” while declining “redefine customer everywhere.” Keep both outcomes visible in the incident record.

Avoid collecting unnecessary sensitive data in a correction sheet. Link authorized reviewers to the evidence they need and follow your organization's existing access rules.

How would a scoped correction work in practice?

Consider this hypothetical example. Marketing asks, “How many customers did the September campaign reach?” The agent selects an approved paying-account measure. Marketing intended the campaign's prospect-account audience. Finance still uses paying accounts in its customer reporting.

The correction should resolve the ambiguous campaign term while preserving Finance's calculation.

1. Capture the mismatch. Save the question and selected measure. Record Marketing's intended population and the campaign source that supports it.
2. Check that an approved measure exists. Ask the metric owner whether the prospect-account measure is already governed. If it is missing, route a metric proposal before treating a new count as approved.
3. Write a scoped proposal. For September campaign reach questions in the Marketing reporting context, use the approved prospect-account reach measure. For an unqualified company-wide customer count, ask which population is intended. Reference the measure rather than reproducing its formula.
4. Review the boundary. Marketing approves the interpretation; the metric owner confirms the reference. The proposal does not redefine Finance's customer population or expand anyone's data access.
5. Apply it at the selected source. Update the owned terminology page or source document through the appropriate review path. Record the decision and applicability.
6. Check the two outcomes. The campaign question should now use prospect-account reach. A Finance question about paying customers should retain its approved interpretation. Inspect the selected measure and reporting period, not just the final wording.

If the campaign question still selects paying accounts, do not close the incident because the page was approved. Investigate whether the consuming agent read the applicable page and whether its tool path used the intended measure. If the problem is routing, another glossary edit may add confusion.

This example deliberately contains no customer deployment, measured accuracy gain, or benchmark result. Use a real incident from your environment to validate the process.

What does Orion by Gravity support today?

Orion's page-management documentation describes Markdown editing, revision history, and change requests on locked pages. Other non-admin editors submit proposed changes; content remains unchanged pending approval. Admins and page creators can review requests, and their own edits can bypass review. The documented statuses include auto-approved changes, so verify the applicable path rather than assuming every edit requires human approval.

The same guide documents project-selected pages and optional tenant or group defaults. Use the narrowest appropriate scope; projects cannot opt out of defaults. These features provide editing and scope controls. The routing matrix and disposition sheet remain a process your team implements.

For analysis review, Orion's notebooks retain instructions, logic, and code. Use the available analysis artifact to check what changed. Confirm historical context and result retention separately; a rerunnable notebook does not establish a complete immutable record of every input.

Orion's dbt connection guide describes model-description and lineage enrichment. Verify the actual governed calculation path separately; metadata import does not establish mandatory MetricFlow execution.

Where should you edit context imported from another wiki?

Choose the source of authority before making a local correction. Orion's external wiki documentation distinguishes Sync Only pages, which follow their external source on a daily schedule and prohibit manual edits, from editable Read & Write imports with manual source syncing. A sync replaces page content and can discard local edits. Those modes do not establish automatic two-way write-back.

If the source wiki owns a policy, submit the correction there and verify the refreshed consumer. If the team intends to own the imported copy in Orion, document that decision and reconcile any source refresh deliberately. Avoid maintaining two independently editable versions of a supposedly authoritative rule.

For an urgent correction, establish when the updated content actually reaches the consuming experience. Keep the incident pending until the affected answer has been checked. A recorded approval and a refreshed answer are different pieces of evidence.

How should you compare tools for business-user corrections?

Choose the tool around the edit that needs to happen. A document knowledge system may suit operating notes; a semantic system may suit governed metric and vocabulary changes; a custom application may be necessary for specialized routing or approval rules. Each option assigns your team different maintenance work.

For adjacent examples, Relevance AI describes plain-text or Markdown knowledge editing, while Actian AI Analyst documents glossary mappings and Steward-proposed updates. Verify permissions, approval behavior, and the consuming calculation path in each candidate; editing alone does not prove your workflow is enforced.

Ask each vendor to demonstrate one disputed answer, one reviewed scoped correction, and one unaffected question. Include a source-owned page and a privileged editor. These cases reveal whether the product's review and synchronization rules match the process you need.

For broader selection criteria, use How to Evaluate an AI Analytics Agent Before You Buy. To evaluate this workflow with Orion by Gravity, bring a real correction to Gravity and ask which steps are supported in your intended deployment.

Frequently asked questions

Does correcting context retrain the AI model?

This workflow changes the information supplied to an agent, not the model's trained weights. Check how the chosen product retrieves the update and whether existing conversations, cached results, or saved artifacts need a separate refresh.

Can a business user change a revenue formula without engineering?

A business user can propose the policy change. If the formula is implemented in a governed metric or data model, its owners must review and implement it through that system. Editing a wiki description should not silently override the approved calculation.

What if two departments are both right?

Keep the legitimate definitions distinct and name their scope. Map each task to its approved measure. Ask a clarifying question when the requested population is ambiguous instead of choosing whichever correction arrived last.

Does approving a context correction grant data access?

It should not. Treat meaning and access as separate decisions. Check the affected question using the intended user identity and existing data permissions before exposing an answer or its supporting evidence.

Should every correction become a company-wide default?

No. Promote a correction only as broadly as the evidence and owner decision support. A one-time clarification may stay with the request; a departmental convention may belong in scoped context. Global guidance needs review of its broader effects.

How do we know a correction reached another assistant?

Check the actual consumption path and resulting answer. Orion's MCP server provides compatible assistants access to Orion resources. A connection alone does not guarantee that an independent assistant uses the corrected source for every request.

When is the correction complete?

When the authoritative change has been applied, the reported question behaves as intended, and a relevant boundary example retains its correct behavior. Record unresolved consumers separately. An approved page edit can still leave an answer incident open.