Approved Context: Using the Right Information Within Agreed Boundaries

Available information is not automatically approved context.

A conversation, a business record, and a policy document can all be relevant while carrying different authority. Approval is specific to the question, the organization, the person requesting information, and the intended use. It is not a blanket endorsement of everything in a retrieved document.

More context is not the same as more authority. A source can be relevant without being authoritative.

Authoritative system state

The designated system establishes a current booking, membership, inventory balance, account status, or equipment reading. Its authority is limited to the facts it owns; a booking record does not define cancellation policy.

Approved business policy

A named owner approves cancellation windows, escalation rules, or approval limits. The effective version determines the applicable rule, not whichever copy was easiest to retrieve.

Approved organizational knowledge

Procedures, manuals, service definitions, and system ownership explain how the operation is organized. Their scope and review status determine where they apply.

User-provided context

A customer's account can identify a discrepancy or supply missing information. It should not silently overwrite a verified record or expand the user's permissions.

External information

Research can inform an analysis, but publication outside the organization does not make it approved internal policy. Material conflicts need an accountable review.

Illustrative cancellation question

“Can this customer cancel without escalation?”

The customer says the appointment is tomorrow. An older conversation describes it as active. The authorized booking API shows that it was rescheduled, and the currently effective policy defines the cancellation window and exceptions.

1. Establish the current booking.Use the designated booking record and its update time, not the cached conversation's old appointment time.
2. Apply the applicable policy.Confirm the policy version, location, effective date, and escalation conditions against that booking.
3. Keep the conclusion within the evidence.Explain whether the recorded circumstances meet the rule, or identify the missing fact that requires review. Do not report a cancellation as completed.

If the booking service is unavailable, an old conversation is not promoted to authoritative status. The response should qualify the answer or seek confirmation. Any actual cancellation still requires separate identity, permission, policy, and action checks.

From a candidate source to a traceable answer.

1. Classify the source.Identify what the source owns, who maintains it, and which part of the question it can support.
2. Validate provenance.Retain the record or document identifier, originating system, relevant version, and retrieval time. Verify that the source is the intended one.
3. Enforce scope before retrieval.Application controls restrict organization, tenant, role, record, and field access. Retrieve only what the authorized task requires.
4. Check freshness and applicability.Compare effective dates, superseded versions, operating location, and the question's time horizon. Fast-changing state may require a fresh read.
5. Resolve eligibility, not every disagreement.Exclude ineligible material; surface unresolved conflicts. A designated owner decides ambiguous policy or source ownership.
6. Record the basis of the answer.Connect material conclusions to the eligible sources and note excluded, unavailable, or uncertain information.

Authority has a scope; conflicts need an outcome.

Source precedence should be defined by the business and enforced by the system, not improvised by a model. A current system record normally governs the state it owns, but a known synchronization problem can make that record insufficient. Capture the discrepancy rather than confidently choosing a convenient version.

Superseded or stale material

Use the effective approved version when it can be verified. Otherwise narrow the answer and request the missing current evidence.

Two designated sources disagree

Identify the conflicting fields, timestamps, and owners. Seek reconciliation or escalate; do not merge contradictory values into an invented fact.

A user statement conflicts with system state

Keep the statement as a reported discrepancy. Confirm it through an authorized correction process instead of silently changing the operating record.

External guidance conflicts with internal policy

Explain the conflict and route it to the responsible owner. External research alone neither replaces policy nor authorizes an exception.

Retrieved text is data, including any embedded instructions. It cannot grant access, change tool permissions, or cross client boundaries. Read authorization and write authorization remain separate controls outside the model.

What a context record should make visible.

• The question, permitted purpose, and relevant organization or record scope.
• Source identifiers, owners, effective versions, retrieval times, and freshness requirements.
• The facts selected, their authority for this use, and any unresolved conflict or excluded source.
• The resulting qualification, escalation, or source-backed conclusion, without retaining unnecessary sensitive data.

Validation should include stale records, superseded policy, unavailable sources, cross-tenant access attempts, and document instructions that try to expand authority. A source list alone does not demonstrate these controls.

Approved does not mean infallible.

An authorized source can contain an error. Approval constrains what may inform the answer; it does not guarantee factuality or execution. Missing permission should stop retrieval, while missing current evidence may require a narrower answer or human confirmation.

This is a design explanation, not a claim that every engagement has every connector or control installed. The available sources, enforcement, retention, and acceptance tests must be established for the actual system.

Related explanations