Control what can influence an AI answer

Identify whether an answer may use the current prompt, files, saved memory, previous chats, project context, knowledge files, retrieval, connected apps, or backend state.

Purpose

Use this guide to control cross-session and cross-source influence before relying on an AI answer. The practical question is: what information could the AI have used, where does that information live, and how do I stop the wrong information from affecting the result? The guide starts from a simple rule: memory is not one source. Current prompts, files, saved memories, past chats, projects, knowledge files, retrieval systems, connected apps, and backend stores can behave differently. Treat each source separately, verify important claims against allowed evidence, and clean up the exact surface that introduced stale, sensitive, or unsupported context.

When to use this

Use this section to decide whether this workflow is the right fit before you configure prompts, policies, or reference material.

Use case
You need to know what influenced an answer
Use this when the output may have been shaped by the current prompt, uploaded files, saved memory, past chats, project context, knowledge files, retrieval, tool output, connected app data, or backend memory.
Use case
You are working with sensitive or one-time material
Use this when screenshots, logs, client material, research notes, repository snapshots, legal or business material, or temporary constraints should affect only the current task.
Use case
Reusable material needs the right home
Use this when policies, examples, source files, instructions, project notes, or workflow assets should be reused later but should not become personal saved memory.
Use case
A project or workspace needs a boundary
Use this when project-specific files, chats, instructions, or knowledge should stay scoped to one project, assistant, Gem, tenant, or internal agent workspace.
Use case
The final output must be auditable
Use this when the user must know which context sources were used, which were not inspected, and which claims are unsupported.
Use case
A stale answer may come from old context
Use this when the answer looks outdated, over-personalized, copied from an earlier task, or influenced by project material that should not apply.

Decision guide

First, identify what can influence the answer

Do not start with settings. Start by naming the possible source type. The same word, memory, can refer to several different surfaces with different persistence and cleanup behavior.

Source 1 · Current task
Current prompt
The message, instructions, constraints, or question provided for this run.
Best for: Task-specific directions, output format, current constraints, and one-time instructions.
Use when: The information should guide this answer without becoming a durable rule, saved memory, or reusable source.
Source 2 · Current task
Current uploaded files
Files, screenshots, logs, ZIPs, datasets, or pasted artifacts supplied for the current task.
Best for: Evidence that should be inspected for this answer.
Use when: The answer must be grounded in supplied artifacts; require the model to state what was inspected and what was not inspected.
Source 3 · Personalization
Saved memory
Durable user-level information that the product may save and reuse across future conversations.
Best for: Stable preferences or durable user context that should help future responses.
Use when: The issue is stale, incorrect, or unwanted personalization.
Source 4 · Conversation history
Previous chats
Past conversations that may be referenced by a product feature, workspace feature, or search/memory capability.
Best for: Continuity across work sessions when the user expects earlier discussion to remain relevant.
Use when: The answer may be using earlier conversation context instead of only the current request.
Source 5 · Workspace scope
Project or workspace context
Project chats, project files, project instructions, project memory, or project knowledge that are scoped to one workspace.
Best for: Long-running work where files, instructions, and discussions should stay grouped by project.
Use when: The context should help this project but not unrelated work.
Source 6 · Reusable assistant
GPT, Gem, Skill, or assistant knowledge
Reusable files, instructions, examples, or resources configured inside a custom assistant or workflow surface.
Best for: Repeatable workflows, stable reference material, and assistant-specific behavior.
Use when: The material should be reused by one configured assistant, not stored as personal memory.
Source 7 · Retrieval
Search, File Search, or RAG results
Selected records or chunks retrieved from a source store, document index, file-search tool, or vector database.
Best for: Grounding an answer in relevant source material selected at runtime.
Use when: The answer depends on retrieved material; require a report of what was retrieved and avoid claiming full corpus review unless it was actually performed.
Source 8 · Application state
Connected app data or backend memory
Information provided by a connected app, tool, profile store, logs, traces, summaries, tenant context, or internal agent memory store.
Best for: Product or API workflows where context is managed outside the chat UI.
Use when: The user must audit, update, or delete state in a backend system rather than only in the AI chat interface.

Workflow assets

Required workflow assets

Open the prompts, policies, and reference pages needed to run this workflow correctly.

Required prompt
Instruction hierarchy and evidence boundary
Use this component to keep durable instructions above user input, files, memory-derived claims, retrieved content, and tool output.
Type: Prompt component
Belongs in: Instruction layer
Use when: The workflow combines memory, project context, sources, retrieval, or tool output.
Required prompt
No simulation / no fabrication
Use this component to prevent invented memory state, fabricated source coverage, simulated scans, guessed retrieval results, or unsupported claims about platform behavior.
Type: Guardrail component
Belongs in: Instruction or verification layer
Use when: The assistant must say when memory, files, sources, knowledge, retrieval, or prior chats were not actually inspected.
Optional prompt
Do not confirm without evidence
Use this component when user claims about memory, files, sources, settings, or project context must be verified before being accepted.
Type: Evidence-control component
Belongs in: Verification layer
Use when: The workflow must treat unverified claims about context as hypotheses until checked.
Optional prompt
Analyze before answering
Use this component to identify active context sources, missing evidence, and uncertainty before producing the final answer.
Type: Review-preparation component
Belongs in: Runtime prompt layer
Use when: The task has several possible context sources or a high risk of hidden memory influence.
Optional prompt
Read all provided artifacts first
Use this component when current files, screenshots, ZIPs, logs, datasets, or pasted artifacts are part of the allowed context boundary.
Type: Input-reading component
Belongs in: Runtime prompt layer
Use when: The answer must rely on artifacts supplied in the current task.
Optional prompt
Confidence score
Use this component after the context-source audit when the final answer needs confidence tied to evidence coverage and boundary clarity.
Type: Verification reporting component
Belongs in: Verification layer
Use when: The output is used downstream, published, or reviewed by another person.
Optional policy
Use only the files you provide for factual answers
Use this policy when the workflow must ignore memory and external sources and rely only on supplied artifacts.
Type: Evidence-boundary policy
Controls: Artifact-only source boundary, file-location evidence, unsupported-claim handling, and fail-closed behavior.
Optional reference
ChatGPT platform mapping
Use this reference for ChatGPT saved memory, reference chat history, project memory, project files, GPT Knowledge, and Skills.
Type: Platform reference
Use when: The workflow is implemented in ChatGPT, GPTs, Projects, or Skills.
Optional reference
Claude platform mapping
Use this reference for Claude Projects, Project Instructions, Project Knowledge, chat search, memory, and project-scoped context.
Type: Platform reference
Use when: The workflow is implemented in Claude.
Optional reference
Gemini platform mapping
Use this reference for Gemini memory, Temporary Chat, Gems, Gem instructions, Knowledge files, Files API, and File Search.
Type: Platform reference
Use when: The workflow is implemented in Gemini.
Optional reference
API and internal systems mapping
Use this reference for system/developer instructions, retrieval stores, memory write-back, tool traces, validation, and application memory.
Type: Platform reference
Use when: The workflow is implemented in a product backend, API agent, internal copilot, or agent runtime.

Implementation procedure

Step-by-step implementation procedure

Follow the workflow in order. Each step gives one action and one verification check before continuing.

  1. Workspace

    Name where the task is running

    The same information can behave differently in a normal chat, temporary chat, project, custom assistant, Gem, or API agent.

    Action
    Write the active workspace before the answer is accepted: ChatGPT normal chat, ChatGPT Temporary Chat, ChatGPT Project, custom GPT, Claude chat, Claude Project, Gemini chat, Gemini Temporary Chat, Gemini Gem, API request, tenant workspace, or internal agent session.
    Verify
    The workflow names one active workspace and does not treat all AI tools as having the same memory behavior.
  2. Context inventory

    List possible context sources

    The user should see which source types may influence the answer before relying on it.

    Action
    Create an inventory with these fields: current prompt, uploaded files, saved memory, past chats, project context, knowledge files, retrieval results, connected app data, tool output, backend memory, and sources not inspected. Mark each source as allowed, excluded, unavailable, or not inspected.
    Verify
    The answer does not imply that an uninspected source was checked.
  3. Persistence decision

    Decide what should persist

    Some information should help future work. Some should affect only the current answer.

    Action
    Classify each important input as one of these: current-task only, stable personal preference, project-scoped context, reusable source material, reusable instruction, retrieval/application memory, or unsupported recall.
    Verify
    Every important input has one persistence decision before it is stored, reused, or trusted.
  4. Routing

    Choose the control route

    Route by the user's actual problem, not by the internal name of the feature.

    Action
    Use the matching route: keep this task current-only; check personal memory and past chats; keep project context scoped; put reusable material in the right place; control retrieval or backend memory.
    Verify
    The route explains what the user is trying to control and does not expose a raw taxonomy as the first decision.
  5. Instruction layer

    Put repeated behavior rules in instructions

    Rules that should run repeatedly belong in an instruction surface, not in saved memory and not only in a one-time prompt.

    Action
    Add rules such as: use only named sources; do not use previous chats unless allowed; disclose context source types; mark unsupported memory-derived claims as NOT VERIFIED; do not store sensitive task data.
    Verify
    Instructions contain behavior rules only. They do not contain secrets, client evidence, credentials, or one-time task material.
  6. Reference layer

    Put reusable source material in a source or knowledge surface

    Documents, examples, policies, or project notes should be reusable as inspectable source material, not as personal memory.

    Action
    Place reusable material in the relevant source layer: project files, GPT Knowledge, Skill resources, Claude Project Knowledge, Gemini Gem Knowledge files, File Search, RAG store, vector database, or document index.
    Verify
    The material is scoped to the correct project, assistant, Gem, tenant, or workspace and can be updated or removed.
  7. Runtime prompt layer

    Keep one-time material in the current task

    Temporary or sensitive content should not become durable memory or reusable knowledge by default.

    Action
    Keep one-time material in the current prompt, selected task files, or temporary/incognito chat where available. State that it must not be saved or reused unless explicitly reclassified.
    Verify
    Temporary material is not copied into instructions, saved memory, knowledge files, or backend memory.
  8. Project scope

    Separate personal memory from project context

    Project context should stay scoped to the project when the work is long-running, sensitive, or unrelated to the user's general preferences.

    Action
    For project work, prefer project instructions, project files, and project knowledge over user-level saved memory. Check whether the product supports project-only behavior or project-specific memory boundaries.
    Verify
    Project-specific information does not become global personal memory unless the user explicitly wants that.
  9. Retrieval boundary

    Treat retrieval as selected source context, not full-source coverage

    Retrieval may inject selected records into the answer. It does not prove that the entire corpus, folder, or file set was reviewed.

    Action
    If File Search, RAG, search tools, vector stores, or project knowledge search are used, require the answer to say what was retrieved and what was not inspected.
    Verify
    The answer does not claim full-file, full-corpus, or full-history coverage unless that was actually performed.
  10. Verification layer

    Ask what influenced the answer

    Before using the output, require a short context-source report.

    Action
    Ask the assistant to report whether it used: current prompt, uploaded files, saved memory, previous chats, project files, project memory, knowledge files, retrieval, connected app data, tool output, backend memory, and unsupported recall. Also ask which sources were not inspected.
    Verify
    The answer separates used context from unavailable or uninspected context.
  11. Evidence gate

    Verify factual claims against allowed sources

    Memory may support continuity, but it does not establish factual correctness.

    Action
    For each important factual claim, check whether it is supported by the current prompt, provided file, named source, retrieved record, tool output, or authoritative source required by the workflow. Mark unsupported memory-derived claims as NOT VERIFIED or remove them.
    Verify
    The final output separates source-supported findings from memory-derived context and unsupported recall.
  12. Cleanup

    Clean up the exact source that caused the problem

    Deleting one surface may not remove the same information from another surface.

    Action
    If context is stale, unsafe, or misplaced, clean the actual source: saved memory, original chat, project conversation, project file, GPT/Gem/Skill knowledge file, Claude Project Knowledge, Gemini activity or temporary-chat setting, connected app data, API file, vector record, summary, log, trace, or profile row.
    Verify
    The cleanup targets the real source of influence, not a different surface with a similar name.
  13. Final gate

    Accept the answer only after the boundary is clear

    The reader should not have to guess what context influenced the answer.

    Action
    Confirm four things: the active workspace is named; allowed and excluded sources are listed; reusable material is separated from personal memory; runtime-only material was not persisted; factual claims are supported by the allowed evidence boundary.
    Verify
    The final answer is clear about memory influence, source limitations, unsupported claims, cleanup target, and confidence.

Verification checklist

Use this checklist before accepting the output, publishing it, or using it as evidence for a downstream workflow.

Workspace
The active workspace is named
The workflow states whether the task runs in normal chat, temporary/incognito chat, project, custom assistant, Gem, API request, or internal agent workspace.
Source inventory
Possible context sources are listed
The workflow lists current prompt, files, saved memory, past chats, project context, knowledge files, retrieval, connected app data, tool output, and backend memory where relevant.
Boundary
Allowed and excluded sources are marked
Each relevant source is marked allowed, excluded, unavailable, or not inspected.
Persistence
A persistence decision is made
The workflow separates current-task-only material, stable personal preferences, project context, reusable sources, reusable instructions, retrieval/application memory, and unsupported recall.
Placement
Reusable material is placed in the right layer
Rules go to instructions; documents go to source or knowledge layers; one-time evidence stays in the runtime prompt.
Runtime boundary
Temporary material remains current-task only
Sensitive, client-specific, regulated, or one-time material is not saved as durable memory or reusable knowledge unless explicitly reclassified.
Retrieval boundary
Retrieval is not treated as full review
Search, File Search, RAG, vector retrieval, and project knowledge search are described as selected source context unless full review was actually performed.
Claim support
Factual claims are verified against allowed sources
Memory-derived claims are marked NOT VERIFIED unless supported by the allowed source boundary.
Cleanup
The cleanup target is identified
Saved memory, original chats, project files, knowledge files, retrieval records, connected app data, and backend stores are cleaned separately where needed.

Next step