Build Source-Linked Institutional Memory for ChatGPT and Codex: Entity Resolution, Citation Graphs, RAG Fallback, and Freshness Controls

What “source-linked institutional memory” means in practice

Source-linked institutional memory is a structured memory layer that lets ChatGPT, Codex, or an API-based assistant answer organizational questions by tracing each important claim back to approved source material. In a serious implementation, “memory” is not a vague bucket of past chats or an uncontrolled pile of embeddings. It is a governed system of source records, extracted facts, entity identities, relationships, timestamps, access labels, contradiction states, deletion markers, and retrieval traces that can be inspected when an answer is challenged.

The September 21, 2026 OpenAI customer story about V7 is a useful reference point because it describes an institutional-memory architecture rather than a simple document-search interface. OpenAI says V7 Go turns files from repositories such as SharePoint and Google Drive into a Context Graph containing entities, relationships, facts, attributes, metrics, and cited evidence. According to the same customer story, that graph powers MCP search and repeatable workflows, and when the graph does not contain enough information, V7 can still search underlying documents with retrieval-augmented generation, or RAG. This tutorial uses those design ideas as an implementation pattern, not as a claim that every organization can reproduce V7’s metrics, model mix, architecture, or product behavior.

For developers and technical leaders, the core lesson is that institutional memory should be designed like a controlled evidence system. A user should be able to ask, “Which vendor contract governs the renewal notice period for Project Northstar?” and receive an answer that names the relevant entity, cites the exact source document and span, reports the effective date, identifies conflicting clauses if they exist, and refuses to answer if the available evidence is stale, unauthorized, ambiguous, or insufficient. A useful system should also separate the act of retrieving evidence from the act of taking action, such as sending a termination notice, updating a CRM record, opening a pull request, or changing workspace permissions.

This distinction matters for ChatGPT and Codex users because “remembering” is often used informally to describe several different capabilities. Active context is what the model can currently see in the conversation, task, file, or tool output. Semantic retrieval is a search mechanism that finds related passages based on meaning. A citation graph connects claims to source evidence. Entity relationships describe how customers, contracts, repositories, tickets, controls, people, and systems relate to each other. Action tools perform operations outside the model, such as querying a system, creating a workflow, or modifying a record. Mixing these layers creates security, accuracy, and governance failures.

A source-linked memory layer is especially valuable in environments where facts change, names collide, access varies by role, and output quality depends on evidence rather than fluent summarization. Enterprise administrators need revocation and audit controls. Security teams need to know whether sensitive context was shared with a connector. Legal-technology professionals need source-grounded citations, privilege boundaries, and contradiction handling. Educators need to distinguish source-supported study assistance from unverified answer generation. Developers using Codex need a memory layer that can point to current design decisions, repository conventions, and issue history without silently treating old context as authoritative.

This Deep Research implementation guide covers source controls, live steering, citations, and editable deliverables in ChatGPT Work and Codex, supplying a concrete operating pattern for evidence-linked institutional memory. The How to Run Deep Research in ChatGPT Work and Codex: Source Controls, Live Steering, Citations, and Editable Deliverables article is a focused companion for Source Controlled Deep Research because it is the catalog’s closest implementation guide for source-controlled research workflows and citation-preserving deliverables.

The V7 customer-story architecture: useful pattern, bounded evidence

OpenAI’s V7 customer story reports that V7 Go ingests files from repositories such as SharePoint and Google Drive and transforms them into a Context Graph of entities, relationships, facts, attributes, metrics, and cited evidence. The same story says the graph powers MCP search and repeatable workflows, and that V7 can fall back to RAG over underlying documents when the graph lacks enough information. It also says V7’s MCP server exposes Context Graph querying and ingestion to ChatGPT and lets users create V7 Go workflows from Codex.

Those statements support a practical architectural pattern: use extraction to build structured memory, use retrieval to preserve access to original documents, use citation links to validate answers, and use MCP or similar tool interfaces to expose controlled capabilities to assistants. They do not establish a universal product recipe, benchmark, or guarantee. Your organization’s data formats, access rules, source quality, ontology, review process, costs, latency targets, and evaluation sets will determine whether the pattern works.

OpenAI’s customer story attributes several reported model and workflow results to V7. V7 reports using GPT-5.6 Luna for high-volume extraction, GPT-5.6 Terra or Sol for reasoning and tool use, and beginning to use GPT-6 Astra on its hardest graph-query tests. V7 reports 89% GPT-6 Astra accuracy on its hardest graph-query tier versus 78% for GPT-5.6 Sol. V7 also reports a tool-call error-rate change from 2.7% with GPT-5.5 to 0.2% with GPT-5.6 Sol in V7’s Context Graph benchmark, and reports 78% lower cost per document and 11.6 percentage points higher accuracy with GPT-5.6 Luna in cited workloads.

Those numbers should be treated as V7-reported results in an OpenAI customer story, not as independent or universal benchmarks. The source does not fully disclose datasets, denominators, confidence intervals, evaluation code, all failure modes, or production incident rates. A procurement team, platform group, or startup founder should not assume the same accuracy, cost profile, tool-call behavior, or model-routing strategy will transfer to their documents. The correct operational response is to build a local benchmark that tests your own files, entity types, permissions, failure cases, and answer policies.

Non-universality warning: A context graph is not automatically current, complete, authorized, non-sensitive, correctly resolved, or true. Semantic similarity is not truth. A citation is not proof that the cited span supports the generated claim. A successful tool call is not authorization to take consequential action. Every memory implementation needs local evaluation, access checks, deletion handling, human review paths, and “insufficient evidence” behavior.

Five memory layers you must keep separate

A dependable institutional-memory system separates at least five layers: active context, semantic retrieval, citation graph, entity relationships, and action tools. Teams often begin with retrieval because it is easy to index documents and ask questions over chunks, but retrieval alone does not resolve duplicate entities, record temporal validity, track contradictions, or authorize downstream actions. A graph alone is also insufficient because extracted facts can be incomplete, stale, or wrong, and the original documents still matter when the graph has gaps.

Active context is the material visible to the model during the current interaction. It can include the user’s message, selected files, system instructions, retrieved passages, tool results, and prior conversation turns that remain in context. Active context is powerful but temporary and capacity-bound. It should not be treated as a governed institutional record unless it is explicitly captured, classified, linked to sources, and retained according to policy.

Semantic retrieval finds text chunks that are meaningfully similar to a query. OpenAI’s retrieval guidance describes semantic search over vector stores that can return chunks, similarity scores, and file-of-origin metadata, with support for query rewriting, attribute filters, ranking controls, and hybrid-search weights. This makes retrieval a strong fallback when a graph lacks coverage, but the returned chunks still need evidence review. A high similarity score can mean “topically related,” not “legally operative,” “current,” “authorized for this user,” or “the right entity.”

Citation graphs connect claims to source evidence. In this tutorial, a citation is not merely a filename appended to an answer. It is a structured pointer that can include source ID, document version, page or section, character span or chunk ID, extraction time, provenance hash, and confidence or review status. A citation graph supports audits because reviewers can inspect whether the answer’s claim is supported by the cited evidence and whether the evidence was current and authorized when used.

Entity relationships make memory institutionally useful. A company may have three vendors with similar names, multiple contracts for the same supplier, old and new project codenames, renamed repositories, and employees who share a surname. Entity resolution assigns canonical IDs and records aliases, source mentions, confidence, merge decisions, split decisions, and review notes. Relationship records then express structured facts such as “Contract C-2026-014 covers Vendor V-008,” “Repository R-119 implements Service S-044,” or “Policy P-021 supersedes Policy P-017 as of a specified effective date.”

Action tools perform or initiate operations beyond answering. Through MCP or other tool layers, an assistant may be able to query a graph, retrieve documents, create workflows, update tickets, or hand work to Codex. OpenAI’s MCP guidance warns that malicious MCP servers can exfiltrate sensitive context. It also notes that approval is requested by default before data is shared with a connector or remote MCP server, and recommends reviewing and optionally logging the data shared. For institutional memory, this means retrieval access and action authorization must remain separate controls.

Layer	Primary job	Typical input	Failure mode	Required control
Active context	Gives the model immediate working material for the current turn or task.	User prompt, selected files, retrieved chunks, tool results, current Codex task context.	The model treats incomplete, old, or user-supplied context as authoritative.	Mark context source, scope, time, and review status; do not persist it as institutional fact without ingestion rules.
Semantic retrieval	Finds relevant passages from indexed documents.	Vector-store chunks, metadata filters, rewritten queries, hybrid search settings.	Relevant-looking chunks are stale, unauthorized, contradicted, or about the wrong entity.	Apply access filters, freshness checks, entity checks, and citation validation before answering.
Citation graph	Links extracted claims and generated answers to evidence.	Source IDs, document versions, spans, hashes, extraction runs, reviewer decisions.	The answer cites a document that does not actually support the claim.	Evaluate citation precision, claim support, provenance integrity, and source status.
Entity relationships	Connects canonical entities, aliases, facts, dates, and relationships.	Organizations, people, systems, contracts, repositories, controls, projects, tickets.	Entity collision or mistaken merge causes the assistant to combine unrelated facts.	Use canonical IDs, alias rules, merge review, confidence thresholds, and contradiction states.
Action tools	Allows assistants to query systems or initiate workflows.	MCP tools, API calls, workflow triggers, repository operations, ticketing operations.	A retrieved fact becomes an unauthorized external action or data disclosure.	Restrict allowed tools, require approval for consequential calls, log shared data, and separate read permissions from write permissions.

Why a graph-plus-RAG design is safer than “just search the documents”

Document search is often the fastest way to ship a first assistant, but it has predictable limits. A search result may contain the right clause without knowing that a later amendment superseded it. It may find a customer name without distinguishing the parent company from a subsidiary. It may retrieve a security policy without recognizing that only a subset applies to a specific business unit. It may answer a question from a stale file because the document was still indexed when access or source status changed.

A graph-plus-RAG design reduces those risks by using the graph for structured facts and relationships while retaining RAG for source-level fallback. The graph can represent canonical entities, effective dates, supersession relationships, contradiction states, and source citations. RAG can retrieve the underlying text when the graph lacks enough information or when a reviewer needs the original wording. The assistant can then answer only when graph facts and retrieved evidence agree, or clearly explain that evidence is incomplete or conflicting.

Consider a legal-operations question: “What notice period applies if we terminate the logistics agreement with Atlas North?” A retrieval-only system might find several documents containing “Atlas,” “North,” and “termination.” A source-linked memory system should first resolve whether “Atlas North” is a vendor, subsidiary, project alias, or internal region. It should identify the active agreement, amendments, renewal status, jurisdiction, and effective dates. It should cite the clause and any amendment that modifies it. If two documents conflict, the system should report the conflict rather than choose a confident-sounding answer.

For Codex users, the same pattern applies to engineering memory. A question such as “Which service owns invoice reconciliation?” should not rely on a random design doc from last year if the ownership moved to a different repository. A graph can connect service IDs, repositories, ownership files, architectural decision records, issue labels, and current deployment metadata. Retrieval can supply the exact ADR or ownership file excerpt. Codex can use that evidence to plan code changes, but opening a pull request, modifying permissions, or changing production configuration still requires the authorized human workflow.

OpenAI’s retrieval guidance reinforces the need for explicit controls because removing a file from a vector store is eventually consistent, meaning results may briefly contain removed content. That behavior is important for governance: deletion, source revocation, and access changes cannot depend only on whether search no longer returns the file. A robust memory layer needs deletion tombstones, revocation checks, source-status filters, and response-time enforcement that prevents newly unauthorized material from being used even if an index has not fully converged.

Reference architecture for a governed institutional-memory layer

The tutorial sections that follow will build a vendor-neutral implementation pattern using synthetic data, but the opening architecture is straightforward. Start with an authorized-source inventory. Assign every source a stable ID, owner, repository, access class, retention rule, update cadence, and deletion behavior. Ingest documents into both a retrieval index and an extraction pipeline. Extract candidate entities, relationships, and facts. Resolve entities into canonical IDs. Attach every fact to cited evidence. Store effective dates, expiry dates, contradiction states, access labels, provenance hashes, and extraction-run metadata. Expose read-only graph lookup and retrieval through controlled tools. Require separate approval for consequential actions.

The minimum viable design should include an “insufficient evidence” path from the beginning. If the assistant cannot identify the right entity, lacks current evidence, sees conflicting sources, or lacks authorization to use the relevant source, it should say so and ask for a permitted next step. This is not a product nicety; it is a safety and quality requirement. Many institutional-memory failures come from systems that always try to answer, even when the right behavior is to refuse, defer, or escalate.

A practical data model should distinguish source records from extracted fact records. A source record describes the document or system record: source ID, title, repository, owner, version, access class, ingestion timestamp, effective status, deletion status, and provenance hash. A fact record describes the claim: subject entity, predicate, object value, supporting citation spans, extraction confidence, reviewer status, effective date, expiry date, contradiction group, and supersession relationship. This separation lets you revoke or reprocess a source without pretending that generated summaries are independent truth.

The graph should also record negative and uncertain states. For example, a vendor entity may have two possible canonical matches, a policy may be superseded but still referenced by an older procedure, or a repository ownership file may conflict with the platform team’s service catalog. If the system only stores “best” facts, the assistant will hide uncertainty. If it stores contradiction states and review requirements, the assistant can answer with the appropriate caveat or route the issue to a human reviewer.

The article is an implementation guide for building enterprise data loss prevention policies for ChatGPT and OpenAI Codex adoption. The How to Build Enterprise Data Loss Prevention Policies for ChatGPT and Codex: Complete Implementation Guide article is a focused companion for ChatGPT and Codex Data Loss Prevention because this is the exact semantic match for governance around sensitive institutional knowledge, access boundaries, and safe use of ChatGPT and Codex.

What this tutorial will build, and what it will not assume

This tutorial will show how to design the memory layer as a set of auditable records and workflows rather than as a single magic index. The implementation examples will use synthetic entities and pseudocode-style structures to avoid exposing private company data, credentials, protected records, or confidential source code. The goal is to give developers, founders, enterprise administrators, security teams, and advanced ChatGPT and Codex users a practical blueprint they can adapt to their own stack, not a claim that one database, model, or connector is always correct.

The build will cover authorized-source inventory, canonical entity IDs, relationship records, fact extraction, citation spans, access-control metadata, effective and expiry dates, contradiction handling, semantic retrieval, graph lookup, RAG fallback, MCP exposure, explicit approvals, freshness jobs, deletion and revocation handling, unanswerable-query behavior, and evaluation. Each component exists because a real institutional-memory system must survive changing facts, disputed evidence, evolving permissions, and model uncertainty.

The tutorial will not assume that a context graph is complete. It will not assume that semantic search returns authorized or current material. It will not treat a citation as automatically supportive. It will not recommend disabling approvals as a universal default. It will not blur the line between retrieving evidence and taking action. It will not use customer-story metrics as performance promises. Where OpenAI’s V7 customer story reports V7-specific results, those results will remain attributed to V7 and bounded to the customer-story context.

For MCP exposure, the conservative rule is to import only the tools needed for the task, restrict tool availability where supported, require human approval for consequential operations, and log what data is shared with external connectors or remote MCP servers. OpenAI’s MCP guidance says developers can restrict tool imports with allowed_tools and notes that keeping the mcp_list_tools item in context avoids refetching tool definitions on every turn. Those controls help reduce unnecessary exposure, but they do not replace access review, connector trust assessment, data classification, or human approval.

The first design rule: evidence before eloquence

The most important design rule is simple: the system must gather and check evidence before producing a confident institutional answer. A fluent paragraph that summarizes the wrong vendor, cites a stale policy, or ignores a revoked document is worse than an explicit “I do not have enough authorized evidence to answer.” Institutional memory should optimize for traceability, reviewability, and safe escalation, not merely for answer completion.

A strong answer should identify the source of each material claim. If the user asks for a policy summary, the answer should cite the policy version and effective date. If the user asks for a customer-status explanation, the answer should distinguish CRM records, contract documents, support tickets, and meeting notes. If the user asks Codex to modify code based on prior architecture, the assistant should cite the current design decision or repository standard before proposing changes. When evidence conflicts, the answer should name the conflict and recommend the authorized review path.

The evaluation plan must test this behavior directly. OpenAI’s evaluation best-practices guidance is included among the required sources for this tutorial because memory quality is not just answer correctness. You need to evaluate citation accuracy, instruction following, tool-call behavior, latency, cost, refusal behavior, and handling of unanswerable queries. You also need red-team-style cases for stale facts, entity collisions, permission boundaries, revoked sources, contradictory sources, and misleadingly relevant retrieval results.

A useful institutional-memory system therefore behaves less like a chatbot that “knows the company” and more like an evidence clerk with controlled tools. It can search, compare, cite, and explain. It can identify when the graph has enough support and when it must fall back to source retrieval. It can tell Codex which repository convention is supported by current evidence. It can refuse to act when approval, authorization, or evidence is missing. That is the standard the rest of this tutorial will use.

Design the ingestion inventory before you extract a single fact

A source-linked memory system fails early if ingestion begins as an engineering convenience rather than an authorization exercise. The V7 customer story published by OpenAI describes an architecture in which files from repositories such as SharePoint and Google Drive become a Context Graph of entities, relationships, facts, attributes, metrics, and cited evidence, with RAG available when the graph lacks enough information. That pattern is useful, but it does not remove the need to prove which repositories are allowed, which users may access the resulting records, which sources are stale, and which facts are contradicted by newer material.

The practical starting point is an authorized source inventory. Treat every connected repository, folder, file class, issue tracker, wiki, CRM export, policy library, design document, and code documentation set as a governed source category. The inventory should say who owns it, what it contains, what the permitted use is, how often it changes, how deletion is handled, what access labels apply, and whether the material can be shown to ChatGPT, Codex, an MCP server, a vector store, a graph database, or a human reviewer. Do not allow a model-generated answer to become the first place where an access decision is made.

Inventory field	Purpose	Conservative rule
source_collection_id	Stable identifier for a repository, folder class, or document stream.	Assign before ingestion; do not reuse an ID for a different collection after migration.
system_of_record	Names the authoritative system for the source category.	If two systems claim authority, mark the collection as contested until an owner resolves it.
data_owner_role	Identifies the business or technical role accountable for permission and lifecycle decisions.	Use a role mailbox or group, not a single employee name, where possible.
allowed_uses	Declares whether content may be indexed, summarized, quoted, used for code assistance, or exposed through tools.	Deny external publication, customer messaging, legal commitments, and deployment actions unless separately approved.
access_label_policy	Maps source permissions into labels used by retrieval and graph queries.	Prefer least privilege; a broad source does not imply broad access to derived facts.
retention_and_deletion_rule	Defines how source removal, expiry, legal hold, and revocation propagate.	Require deletion tombstones and revocation checks; do not rely only on search results disappearing.
freshness_sla	Sets expected re-ingestion cadence and maximum tolerated staleness.	Mark answers as potentially stale when the latest successful ingestion exceeds the allowed window.
sensitive_categories	Flags regulated, confidential, youth, employee, legal, security, or financial material.	Exclude or heavily restrict sensitive categories unless there is a documented business need and policy approval.

The inventory should be reviewed by the data owner, security team, legal or compliance stakeholders where appropriate, and the product owner for the memory layer. For example, a product-requirements folder may be approved for internal engineering Q&A but not for automated customer roadmap statements. A security-incident archive may be authorized for a small incident-response group but not for broad workspace search. A school or education deployment may need stricter treatment of student records and assessment material than a public curriculum repository.

Use a source onboarding checklist that blocks ingestion until the owner has answered operational questions. The checklist should ask whether files contain customer data, employee records, privileged legal material, unreleased financial information, export-controlled technical details, credentials, assessment answers, or secrets. It should also ask whether the organization has rights to index the material, whether third-party contracts limit use, and whether derived metadata can be stored outside the original system. If any answer is unknown, classify the source as restricted and postpone automated ingestion.

Define canonical IDs before alias resolution becomes a guessing game

Entity resolution is the difference between a useful institutional memory system and a confident rumor engine. Product names, teams, customer accounts, repositories, services, policies, projects, vendors, metrics, and feature flags often have aliases, former names, abbreviations, spelling variants, and ambiguous acronyms. A model can suggest matches, but the system should store canonical identifiers and resolution evidence rather than trusting a natural-language label as identity.

Create a canonical entity registry with durable IDs that do not encode mutable names. Avoid IDs such as team-growth-2026 if the team may rename itself or split. Prefer opaque or structured IDs such as ent_team_8f41c2 and keep display names in attributes. For code-oriented deployments, a repository, package, service, API surface, migration, and runtime environment may each be a different entity even if humans use the same shorthand for all of them.

{
  "entity_id": "ent_product_9a7c21",
  "entity_type": "product",
  "canonical_name": "Synthetic Analytics Workspace",
  "status": "active",
  "created_at": "2026-09-22T10:15:00Z",
  "updated_at": "2026-09-22T10:15:00Z",
  "source_of_creation": {
    "source_id": "src_doc_44b20d",
    "citation_span_id": "span_6e0b8a"
  },
  "access_labels": ["internal_product"],
  "owner_label": "product_operations",
  "merge_state": "unmerged",
  "deletion_state": "active"
}

Alias records should be first-class records, not comma-separated strings. An alias may be a current nickname, a legacy brand, a code name, a localized name, an acronym, a vendor’s spelling, a repository slug, or a common typo. Store the alias text, alias type, language or locale where relevant, validity dates, evidence source, and confidence. Do not automatically merge two entities solely because they share an alias; “Phoenix” could be a project, a release train, a customer code name, or a retired incident.

{
  "alias_id": "alias_54ca02",
  "entity_id": "ent_product_9a7c21",
  "alias_text": "SAW",
  "alias_type": "acronym",
  "valid_from": "2026-04-01",
  "valid_to": null,
  "evidence": [
    {
      "source_id": "src_doc_44b20d",
      "citation_span_id": "span_6e0b8a"
    }
  ],
  "confidence": 0.74,
  "review_state": "needs_owner_review"
}

A practical resolution workflow has four stages: candidate generation, evidence comparison, decision, and audit. Candidate generation can use deterministic keys, exact aliases, fuzzy matching, embeddings, and graph neighborhoods. Evidence comparison should inspect source citations, dates, ownership, and surrounding entities. The decision may be “same entity,” “different entities,” “related but distinct,” or “insufficient evidence.” The audit trail should preserve who or what proposed the merge, which citations were used, and when a human approved or rejected it.

For enterprise administrators, the key policy decision is whether the memory layer is allowed to create new canonical entities automatically. A conservative approach allows automatic creation for low-risk public or internal documentation but requires review for people, customers, regulated matters, security incidents, legal matters, vendors, and financial accounts. For Codex workflows, require extra care when resolving similarly named repositories, packages, branches, services, or environments, because a wrong match can lead to incorrect implementation advice.

Store relationships separately from facts

Relationships and facts look similar in prose, but they need different lifecycle controls. A relationship says that two entities are connected in a typed way, such as “service A depends on database B,” “team C owns repository D,” or “policy E supersedes policy F.” A fact says something about an entity or relationship, such as a status, threshold, metric, date, requirement, or constraint. Keeping them separate lets the system update a metric without rewriting ownership, expire a policy requirement without deleting the policy entity, and represent contradictions without collapsing the graph.

{
  "relationship_id": "rel_3f19bd",
  "subject_entity_id": "ent_service_22d4a1",
  "relationship_type": "depends_on",
  "object_entity_id": "ent_database_90bce4",
  "effective_from": "2026-06-15",
  "effective_to": null,
  "source_evidence": [
    {
      "source_id": "src_arch_7184af",
      "citation_span_id": "span_92fe11"
    }
  ],
  "access_labels": ["internal_engineering"],
  "confidence": 0.86,
  "contradiction_state": "not_contested",
  "record_version": 1
}

{
  "fact_id": "fact_15a9d3",
  "entity_id": "ent_service_22d4a1",
  "predicate": "deployment_freeze_window",
  "value": {
    "type": "date_range",
    "start": "2026-12-15",
    "end": "2027-01-05"
  },
  "unit": null,
  "effective_from": "2026-11-01",
  "expires_at": "2027-01-06T00:00:00Z",
  "source_evidence": [
    {
      "source_id": "src_policy_6db7e8",
      "citation_span_id": "span_b42f0a"
    }
  ],
  "access_labels": ["internal_engineering", "release_management"],
  "confidence": 0.92,
  "contradiction_state": "not_contested",
  "deletion_state": "active",
  "record_version": 1
}

The relationship schema should include directionality. “Team A owns service B” is not equivalent to “service B owns Team A.” The schema should also declare whether a relationship is exclusive, time-bounded, many-to-many, hierarchical, or evidentiary only. For example, “mentioned_with” may be useful for exploration but should not be treated as operational ownership. “Supersedes” may imply that older facts should be downgraded, but only if the organization’s policy process defines that behavior.

Fact records should include typed values rather than only text. A date, number, boolean, controlled vocabulary value, URL-like repository identifier, document reference, or localized text field can be validated and compared. A prose-only value is sometimes unavoidable, but it should be marked as unstructured and require stronger citation display. Where metrics are stored, include unit, measurement period, calculation method, and source. Do not compare two numbers if one is a monthly active-user count and the other is a weekly event count just because both mention “usage.”

This production RAG handbook covers the retrieval stack from ingestion through semantic search and operations, giving engineers a deeper companion for designing source-linked institutional knowledge systems. The The Complete RAG Engineering Handbook 2026 article is a focused companion for Knowledge Base Retrieval Design because it addresses retrieval architecture directly rather than only upstream file naming and folder organization.

Give every source, span, and derived record durable provenance

A citation graph depends on source IDs and citation spans that are precise enough for a reviewer to inspect. A source ID should represent a specific version or snapshot of a document, not merely a current file path. File paths change, cloud documents are edited, and ticket descriptions can be rewritten. If the memory layer says a fact came from a policy, the reviewer needs to know which version, which paragraph, and which extraction run created the record.

{
  "source_id": "src_policy_6db7e8",
  "source_collection_id": "coll_policy_library",
  "source_kind": "document",
  "origin_system": "synthetic_policy_repository",
  "origin_reference": "policy-library/release-freeze-policy",
  "source_title": "Release Freeze Policy",
  "source_version_label": "2026-11-01-approved",
  "retrieved_at": "2026-11-02T09:30:00Z",
  "content_hash": "sha256:7b8f2f0c9c0a7d4f7b9e2d9a1a4c0e7e6b5d2a9f8c1b3a4d6e7f8091a2b3c4d5",
  "access_labels": ["internal_engineering", "release_management"],
  "retention_state": "active",
  "legal_hold_state": "none"
}

{
  "citation_span_id": "span_b42f0a",
  "source_id": "src_policy_6db7e8",
  "span_type": "text_offsets",
  "start_offset": 1842,
  "end_offset": 2017,
  "quoted_text_hash": "sha256:9c1d5f4a8b0e7c2d3a6f1e9b5a4c8d0e2f7a6b3c1d8e9f0a2b4c6d7e8f901234",
  "locator": {
    "section": "Change windows",
    "paragraph": 4
  },
  "extraction_note": "Span states the freeze dates and approval owner.",
  "access_labels": ["internal_engineering", "release_management"]
}

Use provenance hashes to detect source drift and extraction drift. A content hash verifies that the snapshot has not changed. A quoted-text hash verifies the cited span. A derived-record hash can include normalized subject, predicate, object, value, source IDs, span IDs, effective dates, and access labels. Hashes are not a substitute for access control or legal review, but they make audits, re-ingestion diffs, and rollback safer.

{
  "provenance_hash": "sha256:2a3b4c5d6e7f8091a2b3c4d57b8f2f0c9c0a7d4f7b9e2d9a1a4c0e7e6b5d2a9f",
  "hash_inputs": [
    "record_type",
    "subject_entity_id",
    "predicate_or_relationship_type",
    "object_entity_id_or_value",
    "source_id",
    "citation_span_id",
    "effective_from",
    "expires_at",
    "access_labels"
  ],
  "hash_algorithm": "sha256",
  "computed_at": "2026-11-02T09:45:00Z"
}

Do not expose hash inputs that contain confidential text to users who lack permission to see that text. A user may be allowed to know that a fact exists but not to see the supporting source, or may be allowed to see an answer summary but not a full quote. Your answer layer must be prepared to say, “A restricted source exists, but you do not have permission to view the evidence,” rather than leaking the sensitive span through a citation.

Add effective dates, expiry dates, and freshness states to every operational claim

Institutional memory is temporal. A correct answer from last quarter may be wrong today because a policy changed, a project was canceled, an owner moved, a customer contract expired, a model release changed behavior, or an engineering environment was retired. Every operational fact and relationship should have an effective date and, where possible, an expiry date. If a source gives no explicit date, store an inferred date separately and lower confidence rather than pretending the claim is timeless.

Temporal field	Meaning	Answer-time behavior
effective_from	Date or timestamp when the fact became valid according to the source.	Prefer records effective at the query’s requested time.
effective_to	Date or timestamp when a relationship or state stopped being valid.	Exclude from current answers unless the user asks for history.
expires_at	Time after which the record should not be used without revalidation.	Return a stale-warning or trigger refresh before answering.
observed_at	When the source or extractor observed the claim.	Use for audit, not as proof that the fact is currently true.
superseded_by	Pointer to a newer record that replaces this one.	Show the newer record and cite the supersession when relevant.
freshness_state	Computed status such as current, aging, stale, expired, or revoked.	Block confident answers when state is stale, expired, or revoked.

A freshness control should combine source-level and record-level checks. If a source collection has a seven-day freshness SLA and the last successful ingestion was twelve days ago, even non-expired records from that source should carry a warning. If a specific fact expires tomorrow, the answer can still use it today but should be careful when producing future plans. If a source was revoked, do not keep using extracted facts merely because they are still in the graph.

OpenAI’s Retrieval API documentation says semantic search over vector stores can return chunks, similarity scores, and file-of-origin metadata, and supports query rewriting, attribute filters, ranking controls, and hybrid-search weights. It also notes that removing a file from a vector store is eventually consistent, meaning results may briefly contain removed content. For a governed memory layer, that means deletion completion, source revocation, access changes, and freshness invalidation require explicit checks outside the generated answer and outside a simple “did search still find it?” test.

A practical answer-time freshness gate should run before text generation. It should verify that each candidate fact is active, not expired, not superseded, permitted for the user, and backed by a source whose collection is still authorized. It should also verify that any retrieved chunk from a vector store belongs to a source snapshot that has not been revoked. If the gate fails, the assistant should use an insufficient-evidence path or ask for authorization to refresh the source, rather than quietly answering from stale memory.

Represent access labels as part of derived memory, not only source storage

Access control must travel with derived records. If a confidential strategy document produces a fact record saying “Project Orion launch target is May,” the fact itself is confidential even if the words are short and the source citation is hidden. Likewise, an entity created from a restricted source may reveal sensitive existence information. Derived records should inherit the most restrictive applicable labels from their sources, then add additional labels based on entity type, fact type, jurisdiction, customer, workspace, or policy.

{
  "access_labels": [
    "internal_only",
    "product_strategy",
    "restricted_launch_timing"
  ],
  "access_decision": {
    "decision": "deny",
    "reason": "requesting_user_lacks_restricted_launch_timing",
    "evaluated_at": "2026-11-02T10:00:00Z",
    "policy_version": "memory-access-policy-2026-10"
  }
}

Use access labels consistently across graph lookup, vector retrieval, MCP tool exposure, and answer rendering. A common failure pattern is to filter graph records but not vector chunks, or to hide citations while allowing the answer to paraphrase restricted content. Another failure pattern is to let a developer tool or Codex workflow access broader context than the user’s role allows because it is “only for implementation.” The memory service should evaluate the same authorization claim before returning records to any client.

OpenAI’s MCP guidance warns that malicious MCP servers can exfiltrate sensitive context. It also says approval is requested by default before data is shared with a connector or remote MCP server, and recommends reviewing and optionally logging the data shared. For this architecture, treat MCP exposure as a separate authorization layer from retrieval. Retrieval may find information; tool execution or connector sharing still requires policy checks, approval where appropriate, and logging of what data was shared.

When exposing graph query or ingestion tools through MCP, restrict the imported tools to the minimum set the task requires. OpenAI’s MCP documentation describes using allowed_tools to restrict tool imports and notes that retaining the mcp_list_tools item in context avoids refetching tool definitions on every turn. Do not make require_approval: never a universal default. A narrow read-only lookup in a low-risk public corpus is different from a connector that can ingest confidential files, update records, send messages, create tickets, approve changes, or trigger deployments.

{
  "mcp_policy_example": {
    "purpose": "Synthetic read-only graph lookup for authorized internal Q&A",
    "allowed_tools": [
      "graph.lookup_entity",
      "graph.lookup_facts",
      "graph.get_citations"
    ],
    "approval_policy": "require_approval_for_external_sharing_or_state_change",
    "logging": {
      "log_tool_name": true,
      "log_user_request_id": true,
      "log_shared_record_ids": true,
      "do_not_log_secret_values": true
    },
    "disallowed_without_separate_approval": [
      "ingest_source",
      "delete_source",
      "change_permissions",
      "send_external_message",
      "deploy_code",
      "purchase_or_payment"
    ]
  }
}

Model contradiction as a state, not as an embarrassment

Contradictions are normal in institutional memory. A roadmap says a feature is planned; a later release note says it was delayed. A customer-success note says an account uses a product; a contract amendment says the subscription ended. A runbook says one service owner; an incident review names another team. The system should not hide contradictions or force a single answer without evidence. It should mark conflict states, preserve competing records, and require an answer style that names the conflict when it matters.

Contradiction state	Use when	Answer rule
not_contested	No known conflicting active record exists.	Answer normally with citation and date.
candidate_conflict	An automated process found possible disagreement.	Use cautious wording and request review for consequential use.
confirmed_conflict	A reviewer or rule confirmed that active records disagree.	Present both records, cite both, and avoid choosing unless policy defines precedence.
superseded	A newer source formally replaces the old record.	Prefer the new record and mention supersession if helpful.
source_revoked	The supporting source is no longer authorized for use.	Do not use the record in answers; retain tombstone metadata if policy permits.
needs_human_resolution	The conflict affects a consequential operation or policy decision.	Block action and route to the accountable owner.

Confidence should not be a decorative score. It should be computed from evidence quality, extraction certainty, entity-resolution certainty, source authority, recency, contradiction state, and validation results. A high semantic match to a paragraph does not mean the extracted claim is true or current. A high extraction score with weak entity resolution is still risky. A fact from an authoritative source that is expired should not be treated as reliable for current action.

{
  "confidence_breakdown": {
    "overall": 0.68,
    "extraction_confidence": 0.91,
    "entity_resolution_confidence": 0.62,
    "source_authority_weight": 0.85,
    "freshness_weight": 0.70,
    "contradiction_penalty": 0.20,
    "human_review_bonus": 0.00
  },
  "recommended_answer_behavior": "state_uncertainty_and_cite_sources"
}

For legal-technology professionals, compliance teams, and educators, contradiction handling is especially important because users may assume a single generated answer has resolved a policy or interpretive dispute. The memory system should not provide personalized legal advice, should not make grading or disciplinary decisions, and should not claim that a policy interpretation is binding unless an authorized human has approved that interpretation. A safe answer can summarize cited materials, identify conflicts, and recommend escalation to the responsible office.

Use deletion tombstones to prevent revoked memory from reappearing

Deletion is not just removing a row. A source may be deleted because it expired, was uploaded by mistake, contained credentials, violated policy, was subject to a contractual restriction, or had its access permissions narrowed. If the graph and vector store only delete content without recording a tombstone, a later sync can re-ingest the same material from a backup, mirrored folder, renamed file, or cached export. A deletion tombstone records that a source, span, entity, relationship, or fact must not be used unless a new authorization decision permits it.

{
  "tombstone_id": "tomb_7fd2a1",
  "record_type": "source",
  "record_id": "src_doc_44b20d",
  "tombstone_reason": "source_access_revoked",
  "created_at": "2026-11-03T12:00:00Z",
  "created_by_role": "data_governance",
  "applies_to_derived_records": true,
  "reingestion_rule": "block_until_owner_reauthorizes",
  "retain_minimal_metadata": true,
  "metadata_retained": [
    "source_id",
    "content_hash",
    "origin_reference_hash",
    "tombstone_reason",
    "created_at"
  ],
  "content_retained": false
}

Tombstones should be privacy-aware. In some circumstances, retaining the full title or origin reference may itself reveal sensitive information. Store hashes or minimized references where appropriate, and align retention with legal, security, and records-management obligations. The purpose is to prevent unauthorized reuse and support audit, not to preserve deleted content under another name.

Deletion propagation should be explicit. When a source is tombstoned, derived citation spans should become inactive, facts and relationships should be marked revoked or unsupported, affected entity aliases should be reviewed, vector-store files should be removed, cached answers should be invalidated, and downstream materialized views should be rebuilt. Because vector-store deletion can be eventually consistent according to OpenAI’s retrieval documentation, use a revocation ledger at answer time so a transient search result cannot revive a removed source.

{
  "revocation_check": {
    "candidate_source_id": "src_doc_44b20d",
    "source_retention_state": "tombstoned",
    "vector_store_result_present": true,
    "answer_gate_decision": "block",
    "reason": "revocation_ledger_overrides_retrieval_result"
  }
}

Validate ingestion with deterministic checks before model review

Ingestion validation should not depend only on another model reading the extracted graph. Deterministic checks catch basic errors cheaply and consistently. Validate that every fact has at least one source ID and citation span, every citation span belongs to an active source, every entity reference resolves to a canonical entity or a reviewed pending entity, every access label is valid, every date parses, every expiry rule is enforceable, every contradiction state is from the allowed vocabulary, and every derived record has a provenance hash.

1. Schema validation: reject records with missing required fields, invalid types, malformed timestamps, unknown labels, or unsupported predicates.
2. Source validation: verify that each source_id exists, is active, has a content hash, and belongs to an authorized collection.
3. Citation validation: verify that each citation_span_id points to a valid span in the cited source snapshot and is permitted for the target audience.
4. Entity validation: check that subject and object IDs exist, are not tombstoned, and have acceptable resolution confidence or human review.
5. Temporal validation: reject impossible ranges, expired records marked current, and facts with future effective dates unless the predicate supports planned states.
6. Access validation: ensure derived labels are at least as restrictive as the supporting sources and that mixed-source facts inherit the strictest relevant label.
7. Contradiction validation: run conflict detection against active records with the same predicate or relationship type and overlapping effective dates.
8. Deletion validation: block records derived from tombstoned sources and prevent re-ingestion of known revoked content hashes.
9. Version validation: require monotonically increasing record versions or immutable event records for every update.

After deterministic checks, use human or model-assisted review for ambiguous cases. Model review can help identify unsupported claims, weak citations, suspicious aliases, or possible contradictions, but it should not silently override validation failures. For high-risk source classes, require a reviewer to inspect a sample of accepted records and all records that affect policy, external communications, security, customer commitments, finance, legal matters, grading, employment, or deployment.

OpenAI’s evaluation guidance emphasizes designing evaluations around the behavior you need rather than treating a single score as proof of readiness. For ingestion, that means building test sets that include correct extractions, unanswerable cases, stale sources, revoked sources, access-denied sources, conflicting sources, ambiguous aliases, and near-duplicate entities. A graph extraction pipeline that performs well on clean policy documents may still fail on meeting notes, code comments, ticket histories, or spreadsheets with implicit context.

{
  "ingestion_validation_result": {
    "run_id": "ingest_run_2026_11_02_001",
    "records_received": 1842,
    "records_accepted": 1510,
    "records_rejected": 212,
    "records_needing_review": 120,
    "top_rejection_reasons": [
      "missing_citation_span",
      "unknown_access_label",
      "entity_resolution_below_threshold",
      "source_expired",
      "possible_contradiction"
    ],
    "review_required_before_publish": true
  }
}

Version the graph as an event log, not only a current table

Institutional memory needs history. If the answer yesterday said the owner was Team A and the answer today says Team B, administrators need to know whether the source changed, a correction was applied, an entity merge occurred, a permission changed, or a deletion tombstone removed the older record. A current-state table is useful for fast lookup, but an immutable event log is safer for audit, rollback, evaluation, and incident review.

{
  "event_id": "evt_0c91a5",
  "event_type": "fact.updated",
  "record_id": "fact_15a9d3",
  "previous_record_version": 1,
  "new_record_version": 2,
  "change_reason": "source_superseded",
  "changed_at": "2026-11-15T14:20:00Z",
  "changed_by": {
    "actor_type": "ingestion_pipeline",
    "actor_id": "pipeline_policy_sync"
  },
  "source_evidence_added": [
    {
      "source_id": "src_policy_8ad31e",
      "citation_span_id": "span_0f18cb"
    }
  ],
  "source_evidence_removed": [],
  "access_label_change": {
    "before": ["internal_engineering", "release_management"],
    "after": ["internal_engineering", "release_management"]
  }
}

Use immutable events for creation, update, merge, split, supersession, revocation, tombstone creation, access-label change, confidence recalculation, human review, and export. Store enough context to reconstruct the state at a point in time without exposing restricted content to unauthorized auditors. Where full reconstruction is not legally or operationally appropriate, preserve metadata that proves a change occurred and routes authorized reviewers to the proper system of record.

Entity merge and split events deserve special treatment. A bad merge can contaminate many downstream facts, and a later split must not leave facts attached to the wrong canonical entity. Require merge proposals to list aliases, overlapping sources, conflicting attributes, related entities, and reviewer decisions. If a split occurs, create explicit remapping events for each affected fact and relationship rather than silently editing IDs in place.

{
  "merge_proposal": {
    "proposal_id": "merge_102af0",
    "candidate_entity_ids": ["ent_customer_11a0b2", "ent_customer_77fe91"],
    "proposed_decision": "do_not_merge",
    "reason": "same acronym but different legal entities in different regions",
    "evidence_reviewed": [
      {
        "source_id": "src_contract_index_a1",
        "citation_span_id": "span_1100aa"
      },
      {
        "source_id": "src_account_notes_b2",
        "citation_span_id": "span_77ff02"
      }
    ],
    "review_state": "approved_by_data_owner",
    "approved_at": "2026-11-16T09:00:00Z"
  }
}

Build the ingestion pipeline as a sequence of gates

A reliable ingestion pipeline should be staged so that failure at one gate does not pollute later layers. The first gate checks source authorization. The second snapshots or references the source according to policy. The third extracts candidate entities, aliases, relationships, facts, and spans. The fourth resolves entities. The fifth validates schema and provenance. The sixth applies access labels and freshness rules. The seventh detects contradictions. The eighth publishes records to the query graph and indexes approved source snapshots for retrieval fallback. The ninth records metrics and evaluation traces.

{
  "pipeline_stages": [
    "authorize_source_collection",
    "snapshot_source_version",
    "extract_candidates_with_citations",
    "resolve_entities_and_aliases",
    "validate_schema_and_provenance",
    "apply_access_and_freshness_labels",
    "detect_contradictions",
    "publish_graph_records",
    "index_approved_sources_for_retrieval",
    "write_audit_and_evaluation_trace"
  ]
}

Keep graph publication and vector indexing coordinated but not identical. The graph stores normalized, cited claims and relationships. The vector store supports semantic retrieval over approved chunks when the graph lacks enough information or when the user needs source context. The V7 customer story describes this graph-first plus RAG fallback pattern: the graph powers repeatable workflows, and when the graph lacks enough information, underlying documents can still be searched with RAG. In your implementation, the fallback should still obey access labels, revocation ledgers, freshness checks, and citation display requirements.

Do not let fallback become a loophole. If a graph query returns “insufficient evidence,” the system may search approved documents, but it must not answer as if a semantically similar chunk proves the fact. Semantic relevance can identify possible evidence; it does not establish truth, currentness, authorization, or entity identity. A safe fallback answer should say what the source appears to state, quote or cite the relevant span if permitted, and identify remaining uncertainty.

Operational warning: Separate data retrieval from action authorization. A memory service may retrieve a deployment policy, but it must not approve a deployment, change permissions, send a customer message, submit legal language, purchase software, or publish a document without the required authorized human approval and workflow controls.

Use synthetic fixtures to test the design before connecting real repositories

Before connecting production repositories, build a synthetic corpus that mimics the organization’s document shapes without containing private data. Include a policy document with supersession, a roadmap with a delayed feature, an engineering runbook with an ownership change, a customer note with ambiguous aliases, a revoked source, a stale source, a public document, and a restricted document. This lets developers, founders, administrators, security teams, educators, and legal-technology teams test the ingestion design without exposing confidential material.

Synthetic fixture	Purpose	Expected validation behavior
Policy v1 and policy v2	Tests supersession, effective dates, and expiry.	v2 becomes current; v1 is retained as history and not used for current answers.
Two projects sharing one acronym	Tests alias ambiguity and entity-resolution caution.	System refuses automatic merge and routes to review.
Revoked source snapshot	Tests deletion tombstones and vector-store inconsistency handling.	Answer gate blocks use even if retrieval temporarily returns a chunk.
Restricted strategy note	Tests derived access-label inheritance.	Unauthorized users cannot see fact, quote, or paraphrase.
Conflicting owner records	Tests contradiction state and answer wording.	System cites both records and avoids choosing without precedence policy.
Unanswerable query	Tests refusal to fabricate.	System returns insufficient evidence and suggests permitted next steps.

A good synthetic fixture includes the expected graph records, expected rejected records, expected citations, expected access decisions, and expected answer behavior. Treat these fixtures as regression tests for future extractor changes, prompt changes, schema migrations, model changes, and retrieval-ranking changes. When the system starts accepting a record that should be rejected, the failure is as important as a traditional software test failure.

Document the “insufficient evidence” path as a product feature rather than a fallback apology. The answer should state that the system did not find enough authorized, current, source-linked evidence; list the collections searched if disclosure is permitted; identify whether restricted or stale sources were excluded; and offer safe next steps such as requesting access, asking the data owner to refresh a source, or narrowing the query. It should not invent a confident answer to satisfy the user’s request.

{
  "insufficient_evidence_response_template": {
    "summary": "I do not have enough authorized, current, source-linked evidence to answer that.",
    "checked": [
      "active graph records permitted for the user",
      "approved retrieval sources permitted for the user",
      "revocation ledger",
      "freshness state"
    ],
    "not_used": [
      "stale sources",
      "revoked sources",
      "sources outside the user's access labels"
    ],
    "safe_next_steps": [
      "ask the source owner to refresh the approved collection",
      "provide an approved document or citation",
      "request access through the organization's normal process"
    ]
  }
}

Prepare the handoff from ingestion to evaluation

The ingestion design is not complete until it produces evaluation artifacts. Every run should record the source collections processed, extractor version, model or parser configuration identifier, schema version, validation failures, review queue size, accepted record count, rejected record count, access-label distribution, contradiction count, stale-source count, tombstone hits, and sample records for citation review. These artifacts let the team measure whether the memory layer is becoming more reliable or merely larger.

OpenAI’s V7 customer story reports V7-specific results, including graph-query and extraction-related metrics, but those numbers are not universal benchmarks and do not disclose every dataset detail, denominator, confidence interval, failure mode, evaluation implementation, cost, latency, or incident rate. Your ingestion evaluation should therefore use local sources, local entity types, local access policies, and local failure definitions. A system that performs well on a vendor’s benchmark may still fail on your naming conventions, document permissions, or stale-source patterns.

For the next implementation stage, define acceptance gates that are tied to risk. A low-risk internal glossary may require schema validity, citation presence, and a small human review sample. A security runbook, legal policy, financial control, student-support procedure, or customer commitment record should require stronger review, contradiction checks, access verification, and approval before the memory layer can answer operational questions from it. The more consequential the downstream use, the less acceptable it is to rely on semantic similarity or unreviewed extraction alone.

At the end of ingestion, the system should be able to answer four audit questions for every record: Which authorized source supported it? Which span or evidence locator was used? Who or what changed it over time? Why is it allowed to be shown to this user now? If the system cannot answer those questions, it has not built institutional memory; it has built a searchable pile of claims.

Expose institutional memory through retrieval, MCP, and freshness controls

Once your ingestion pipeline can produce canonical entities, cited facts, relationship records, access labels, contradiction states, and deletion tombstones, the next engineering problem is how ChatGPT, Codex, or an internal agent should retrieve that memory without overclaiming, leaking data, or acting beyond its authority. OpenAI’s V7 customer story describes a Context Graph that powers MCP search and repeatable workflows, with RAG over underlying documents when the graph does not contain enough information. Treat that as an architectural pattern: a graph answers structured questions with source-linked records, semantic retrieval finds relevant text chunks, and a fallback path states when the evidence is not enough.

The practical retrieval design should separate three decisions that are often blurred in prototypes. First, determine whether the user is allowed to ask about the sources at all. Second, determine whether the memory layer has sufficiently current and cited evidence to answer. Third, determine whether any follow-up action, such as creating a ticket, sending a message, changing a permission, opening a pull request, booking a meeting, or launching a workflow, is authorized. Retrieval can inform action, but retrieval permission is not action permission.

Use graph lookup when the question depends on known entities, relationships, or attributes

A context graph is strongest when the user’s question names or implies entities that your ontology can resolve. Questions such as “Which renewal terms apply to the North America reseller agreement?”, “Who owns the incident-response runbook for the payments service?”, or “Which metrics changed after the migration?” require stable entities, relationship edges, fact records, dates, and citations. The graph lookup should not merely return a paragraph; it should return the canonical entity IDs, the matched aliases, the relationship path, the fact IDs, the evidence spans, and the freshness status used to support the answer.

Recommended workflow: run entity resolution before semantic search when the query includes recognizable names, IDs, product names, project codes, people, teams, repositories, documents, vendors, customers, legal instruments, or operational metrics. This prevents a semantically similar but wrong record from displacing a precise graph match. For example, “Sol migration plan” might refer to an internal project named Sol, an OpenAI model reference in a customer story, or a vendor’s product label. The resolver should produce candidate entities with confidence, required disambiguation questions, and evidence of the alias match.

Question pattern	Primary retrieval path	Why this path is safer	Required guardrail
“What is the current owner of Policy X?”	Graph lookup by policy entity and ownership relationship	Ownership is an attribute with effective dates, not just a text similarity problem.	Check effective date, access label, source revocation, and contradictions before answering.
“Summarize the latest guidance on vendor onboarding.”	Graph lookup for canonical policy plus semantic retrieval of cited documents	The graph identifies the authoritative policy while retrieval adds surrounding context.	Prefer approved source types and state if only draft or superseded material is found.
“Find mentions of export-control review in launch docs.”	Semantic search with attribute filters, then graph enrichment	The user is searching for text occurrences across documents rather than a known fact.	Return document metadata and do not infer legal clearance from mentions alone.
“Create a release checklist for this repository.”	Retrieval plus action-authorization gate	Memory can identify relevant policies, but writing or opening tasks is a separate operation.	Require explicit human approval before creating external artifacts or changing systems.

Do not let graph lookup hide uncertainty. If the resolver finds two plausible entities, the system should ask a clarifying question or answer with both candidates clearly separated. A collision between “Atlas” the internal platform, “Atlas” the customer implementation project, and “Atlas” the legacy database should be represented as an entity-resolution state, not flattened into one “best guess.” The same rule applies to renamed departments, acquired subsidiaries, merged repositories, and vendors with similar product names.

Use semantic retrieval for evidence discovery, not for truth determination

OpenAI’s retrieval documentation describes semantic search over vector stores that returns chunks, similarity scores, and file-of-origin metadata. It also supports query rewriting, attribute filters, ranking controls, and hybrid-search weights, while automatically chunking and embedding indexed files. Those features are useful for finding candidate evidence, but semantic relevance does not prove that a chunk is true, current, complete, authorized, or about the intended entity. Your answer policy should treat retrieved chunks as evidence candidates that must pass metadata, provenance, and freshness checks.

Use semantic search when the graph lacks a direct fact, when the user asks for background context, when the source material is too new to be fully extracted, or when the user wants citations from documents rather than normalized graph records. For example, a Codex user might ask, “What migration constraints are documented for this service?” If the graph has no complete migration fact set, semantic retrieval can search architecture notes, design reviews, pull-request discussions, and runbooks. The answer should still identify which documents were searched, which chunks were used, and what uncertainty remains.

Attribute filters should be applied before ranking whenever possible because they encode authorization and relevance constraints that the embedding score cannot know. Typical filters include source repository, document class, owner team, confidentiality label, jurisdiction, product line, effective date range, language, lifecycle state, and ingestion version. A user asking for “approved HR policy” should not receive an obsolete draft because its language is semantically similar. A developer asking about a production service should not receive a deprecated prototype note unless the answer explicitly marks it as historical context.

{
  "retrieval_intent": "policy_answer",
  "query": "What is the current vendor onboarding approval path?",
  "filters": {
    "document_type": ["approved_policy", "approved_process"],
    "access_label": ["user_authorized"],
    "lifecycle_state": ["active"],
    "effective_on_or_before": "request_time",
    "not_expired_at": "request_time"
  },
  "ranking_policy": {
    "min_similarity": "configured_per_corpus",
    "prefer_recent_effective_date": true,
    "prefer_authoritative_source": true,
    "require_citation_span": true
  }
}

The threshold value in this example is intentionally named rather than numerically invented. Similarity thresholds depend on corpus size, chunking strategy, domain vocabulary, embedding model, language, source quality, and acceptable false-positive rates. Set thresholds using evaluation data, not intuition. A support knowledge base with repetitive product names may need different cutoffs from a legal repository, a software architecture archive, or a school policy library.

The article covers Codex CLI 0.144.0 updates, including writes approval mode, MCP authentication, and multi-agent concurrency controls. The Codex CLI 0.144 Arrives — New Writes Approval Mode, MCP Auth, and Multi-Agent Concurrency Controls article is a focused companion for MCP Security Controls because it is semantically appropriate because the marker concerns MCP security controls, and this target specifically discusses MCP auth and approval controls in Codex.

Query rewriting should improve recall without changing the question

OpenAI’s retrieval guide notes support for query rewriting. In an institutional-memory system, rewriting is useful when users ask short or ambiguous questions such as “latest SSO rules,” “renewal cap,” or “who approved this?” A rewrite step can expand acronyms, add known synonyms, include canonical entity aliases, and convert conversational language into retrieval-ready clauses. The rewrite must not smuggle in assumptions. If the user asks for “the current policy,” the rewrite may add “active, approved, effective” as retrieval constraints; it should not assume a jurisdiction, business unit, or contract unless the user context authorizes and identifies it.

Recommended workflow: store both the original query and the rewritten query in the run trace. When a query rewrite changes the entity candidate, time period, jurisdiction, source type, or action intent, require either a clarifying question or a visible explanation in the answer. This is especially important for enterprise administrators and legal-technology teams because a rewritten query can silently turn a broad research question into a narrower compliance answer. The audit log should show what was searched, why filters were applied, and whether the answer relied on graph records, retrieved chunks, or both.

1. Parse the user question. Identify entities, time references, source classes, jurisdictional hints, repository hints, and requested output format.
2. Resolve aliases. Map names and acronyms to canonical IDs, but keep unresolved candidates separate.
3. Generate retrieval rewrites. Produce variants for exact entity match, synonym expansion, and source-specific terminology.
4. Apply authorization filters. Remove source classes and repositories the user is not permitted to query.
5. Rank and inspect candidates. Require cited spans, file metadata, lifecycle state, and freshness status before answer generation.
6. Record the trace. Store the original query, rewrite, filters, selected evidence, rejected evidence categories, and answer confidence state.

For Codex workflows, query rewriting must be especially careful with repository paths and branch context. “Use the deployment guide” may refer to a document in the current worktree, an internal platform handbook, a product release checklist, or a public OpenAI guide. If the rewrite chooses the wrong source universe, the generated code or task plan can appear coherent while implementing the wrong standard. Require repository-aware filters and ask for clarification when the source boundary is unclear.

Build hybrid retrieval that combines graph paths, keyword signals, and vector similarity

A durable institutional-memory layer should not force every question through one retrieval method. Graph lookup provides precision for known facts and relationships. Vector retrieval provides recall across natural-language documents. Keyword or lexical search catches exact identifiers, error codes, section numbers, legal phrases, API names, and rare terms that embeddings may underweight. Hybrid retrieval gives the answerer more evidence candidates while preserving the ability to reject weak or unauthorized matches.

OpenAI’s retrieval documentation refers to ranking controls and hybrid-search weights. Use those controls as part of an evaluation-driven ranking policy. For example, exact matches on source IDs, contract IDs, repository paths, or policy section numbers should usually outrank a semantically similar chunk. Conversely, a natural-language question about “what changed after the migration” may benefit from vector similarity across meeting notes and retrospectives, followed by graph enrichment for dates, owners, and metrics.

Signal	Best use	Failure mode	Mitigation
Graph relationship path	Known entity, owner, dependency, metric, obligation, approval chain	Graph is incomplete or stale.	Check extraction coverage, freshness state, contradiction state, and RAG fallback.
Vector similarity	Paraphrased questions, broad summaries, recently indexed documents	Similar text is treated as authoritative fact.	Require metadata filters, citations, source rank, and answer confidence gates.
Keyword or exact search	IDs, clauses, function names, error codes, policy sections, legal terms	Misses synonyms and informal descriptions.	Combine with query rewriting and vector retrieval.
Freshness score	Operational guidance, ownership, pricing policy, release state, procedures	Newer source may be draft or unauthorized.	Prefer active approved sources over merely recent documents.

Ranking thresholds should be explicit and testable. Define a “no-answer zone” where the top result is below the configured score, where competing results conflict, where the source is expired, where the cited span lacks the asserted claim, or where the user is not authorized for the relevant source. The model should not fill those gaps with fluent speculation. The correct answer may be: “I found related material, but not enough approved, current evidence to answer.”

Design RAG fallback as a controlled evidence path, not an escape hatch

OpenAI’s V7 customer story says V7 can search underlying documents with RAG when the graph lacks enough information. That fallback is valuable because no graph extraction process is complete. Newly uploaded documents, unusual edge cases, lengthy narratives, meeting notes, and source formats with weak structure may not yet be normalized into facts. However, RAG fallback should be more constrained, not less constrained, because the graph’s validation layer may be missing.

Recommended fallback rule: use RAG when the graph returns no answer, low-confidence entity resolution, incomplete relationships, or stale facts, but require the retrieved document chunks to pass source authorization, lifecycle, freshness, and citation-span checks. The fallback answer should disclose that it is based on document retrieval rather than a verified graph fact. For high-stakes domains such as legal operations, security policy, finance, healthcare administration, education records, or employment decisions, fallback should produce research notes for an authorized human reviewer rather than a final decision.

{
  "answer_mode": "rag_fallback",
  "reason": "graph_missing_required_fact",
  "evidence_requirements": {
    "min_authoritative_sources": 1,
    "require_file_metadata": true,
    "require_citation_spans": true,
    "reject_expired_sources": true,
    "reject_revoked_sources": true,
    "surface_conflicts": true
  },
  "response_policy": {
    "state_fallback_used": true,
    "state_missing_graph_fields": true,
    "do_not_infer_approval": true,
    "human_review_required_for_consequential_use": true
  }
}

A useful answer pattern is to separate “what the retrieved sources say” from “what remains unresolved.” For example: “The approved onboarding policy dated March 12 names Legal Operations as the owner and requires security review before contract execution. I did not find a current cited source for regional exceptions. Do not use this as final approval for a vendor until the regional exception register is checked by the authorized owner.” That format gives the user actionable context while preventing the system from pretending the evidence is complete.

Return insufficient-evidence answers deliberately and consistently

An insufficient-evidence answer is not a failure of the assistant; it is a safety feature of institutional memory. If the system cannot find cited, current, authorized support for a claim, it should say so and offer the next safe step. This is particularly important for ChatGPT Work users who may ask seemingly ordinary questions that have legal, financial, security, personnel, academic, or customer-impact consequences. The answer should identify what was searched at a high level without exposing unauthorized document names or sensitive metadata.

Build a fixed answer policy for common no-answer conditions. If no relevant source exists, say the repository does not contain enough evidence and suggest the approved owner or source type to consult. If sources conflict, summarize the conflict and request human review by the policy owner. If sources are stale, say which evidence appears outdated and avoid operational recommendations. If the user lacks access, do not reveal the confidential content; state that the available authorized sources are insufficient. If the request asks for an action, explain that retrieval results do not authorize execution.

Condition	Safe response behavior	Unsafe response behavior to avoid
No cited source	State that no cited evidence was found and ask for an approved source or owner.	Answer from general knowledge or infer from similar organizations.
Conflicting sources	Show the conflict with dates and source classes, then require owner review.	Average the conflict into a single confident statement.
Expired source	Mark the source as expired and withhold current operational guidance.	Use the expired text because it is semantically relevant.
Access denied	Say authorized available evidence is insufficient.	Reveal that a restricted document contains the answer.
Action requested	Provide a draft or checklist only if permitted, with human approval before execution.	Send, submit, deploy, purchase, approve, or change permissions automatically.

For educators and parents, insufficient-evidence behavior is also a youth-safety and academic-integrity control. A school assistant should not infer student accommodations, grades, disciplinary actions, health information, or family details from partial records. It should direct authorized staff to approved systems and policies, while avoiding disclosure of private student information to unauthorized users. The same principle applies to enterprise HR, legal operations, and security investigations.

This Library sharing governance guide explains viewer and editor roles, folder ownership, access revocation, and file custody, controls that help teams retire obsolete access paths and maintain accountable knowledge sources. The ChatGPT Library Sharing Governance Guide: Viewer and Editor Roles, Folder Ownership, Access Revocation, and File Custody article is a focused companion for Stale Knowledge Management because its revocation and custody controls are substantially closer to stale-knowledge lifecycle management than the draft Zendesk prompt collection.

Run stale-source checks before every answer that depends on current facts

A source-linked memory system can become wrong even if every extraction was correct at ingestion time. Policies expire, contracts are amended, repositories are renamed, owners leave, teams merge, vendors change terms, incidents close, and launch plans are superseded. Therefore, each answer should include a freshness gate that checks effective dates, expiry dates, last-seen source status, source lifecycle state, ingestion timestamp, and any revocation marker. The model should not be asked to remember freshness implicitly; freshness must be represented in data and enforced in retrieval.

Recommended freshness metadata includes source creation time, source modified time, ingestion time, extraction version, fact effective date, fact expiry date, source lifecycle state, authoritative-source rank, last permission check time, revocation status, and tombstone status. Use different states for “current,” “historical,” “draft,” “superseded,” “expired,” “revoked,” “pending review,” and “unknown.” A fact with an unknown freshness state should not be promoted to current operational guidance merely because it appears in a highly similar chunk.

Freshness checks should be domain-specific. A software dependency vulnerability note may become stale within hours. A board-approved policy may remain current for months but still require amendment tracking. A customer contract clause may remain legally relevant after expiration for audit purposes but not for new commitments. A classroom assignment rubric may be valid only for a specific term. Your retrieval layer should distinguish “historically true,” “currently operative,” “approved for reuse,” and “safe to cite externally.”

{
  "freshness_gate": {
    "request_time": "runtime_supplied",
    "required_states": ["active", "approved"],
    "reject_states": ["draft", "superseded", "expired", "revoked", "deleted"],
    "require_effective_date": true,
    "require_no_active_contradiction": true,
    "require_permission_recheck_for_sensitive_sources": true,
    "fallback_if_unknown": "insufficient_evidence"
  }
}

Do not confuse recency with authority. A Slack-style discussion, draft memo, or unreviewed commit may be newer than the approved policy, but newer does not automatically mean governing. Conversely, an old contract or safety report may remain authoritative for a specific period or audit question. Rank source authority separately from modification time, and make the answer state whether it is citing an approved source, a draft, an archived source, or a retrieved document that still requires review.

Handle eventual-consistency deletion risk and revocation explicitly

OpenAI’s retrieval documentation states that removing a file from a vector store is eventually consistent, meaning results may still contain removed content briefly. That is an operationally important warning for any institutional-memory system. Deletion, revocation, and permission changes must not rely solely on the absence or disappearance of search results. Your own control plane should maintain tombstones, revocation lists, and permission checks that are consulted at query time before any retrieved chunk or graph fact is used in an answer.

A deletion tombstone should record the source ID, deletion or revocation time, revocation reason category, affected derived record IDs, affected vector-store file IDs if available, and the policy for historical audit retention. The answer layer should reject any graph fact or retrieved chunk whose source ID is tombstoned, even if the vector store still returns a matching chunk during the eventual-consistency window. The same applies when a user loses access to a source: search infrastructure may lag, but the authorization check must be current.

Event	Immediate control-plane update	Retrieval-time behavior	Audit requirement
Source file deleted	Create tombstone for source and derived records.	Reject matching chunks or facts even if search returns them.	Log deletion time, affected IDs, and whether any post-deletion retrieval was blocked.
Access permissions changed	Update authorization index or permission cache.	Recheck user access before exposing metadata, excerpts, or summaries.	Record permission source and decision without leaking restricted content.
Policy superseded	Mark old source as superseded and link successor source.	Use successor for current guidance; old source only for historical questions.	Log which version was cited and why.
Legal hold or audit retention	Preserve retention metadata while restricting normal answer use.	Do not expose retained material unless the requester is authorized for that purpose.	Separate retention availability from answer authorization.

Source revocation is broader than file deletion. A source may be revoked because it was uploaded by mistake, contained confidential information, used unlicensed third-party material, was generated from unreliable extraction, reflected a withdrawn policy, or included personal data that should not be used for the requested purpose. Revocation should propagate to graph facts, relationship edges, summaries, cached answer snippets, evaluation fixtures if they contain the source text, and downstream workflow templates derived from the source.

When the memory layer is used by Codex, revocation must also reach generated project context. A revoked architecture note should not continue guiding code changes because it was summarized into a task card, a worktree note, or a prompt template. Treat generated artifacts as potentially contaminated by revoked sources when they contain source-derived claims. The mitigation is not to erase audit history blindly, but to prevent further use, mark affected artifacts, and route consequential changes through a human review path.

Expose retrieval through MCP with least privilege and visible approvals

OpenAI’s MCP guidance supports remote MCP servers and Secure MCP Tunnel, and warns that malicious MCP servers can exfiltrate sensitive context. It also states that approval is requested by default before data is shared with a connector or remote MCP server, and recommends reviewing and optionally logging the data shared. For institutional memory, this means MCP should be treated as a controlled interface, not as a blanket bridge between ChatGPT, Codex, and every internal repository.

Use allowed_tools to restrict which MCP tools are imported for a given assistant, workspace, or workflow. A research assistant may need a read-only graph query tool and a document retrieval tool. A Codex workflow might need a repository-context lookup tool and a workflow-drafting tool. An administrator console may expose ingestion-status checks. These tools should be separately named, separately logged, and separately approved where risk requires it. Do not expose ingestion, deletion, permission modification, external messaging, ticket creation, or workflow execution merely because the same server also provides search.

{
  "mcp_policy_example": {
    "allowed_tools": [
      "context_graph.search",
      "documents.retrieve_cited_chunks",
      "sources.check_freshness",
      "entities.resolve"
    ],
    "approval_policy": {
      "retrieval_of_sensitive_context": "explicit_approval_required",
      "external_messages": "explicit_approval_required",
      "permission_changes": "explicit_approval_required",
      "destructive_operations": "explicit_approval_required",
      "routine_low_risk_lookup": "workspace_policy_defined"
    },
    "logging": {
      "record_tools_called": true,
      "record_data_shared_summary": true,
      "record_source_ids": true,
      "avoid_logging_secrets_or_unnecessary_personal_data": true
    }
  }
}

This example is a policy shape, not a claim about a universal SDK configuration or a recommendation to disable approvals. Do not make require_approval: never a universal default. Some low-risk read-only lookups may be approved by a workspace policy after security review, but sensitive context sharing, external communications, destructive changes, purchases, submissions, deployments, permission changes, and legal or financial commitments require explicit human approval. The correct approval posture depends on data sensitivity, action impact, user role, workspace policy, and connector trust.

OpenAI’s MCP guide notes that retaining the mcp_list_tools item in context avoids refetching tool definitions on every turn. That is a performance and context-management consideration, not a permission shortcut. Tool availability should not be confused with user authorization to invoke a tool for a specific source or action. The server should enforce authorization even when a tool definition is already present in the conversation context.

Log data sharing without creating a new sensitive-data problem

Data-sharing logs are essential when MCP connectors and retrieval systems can send context to remote servers. The log should help security teams reconstruct which tool was called, which user or service account initiated the call, which source IDs or record IDs were involved, what approval was shown, what category of data was shared, and what answer or artifact resulted. The log should not become a warehouse of raw confidential text, credentials, health information, student records, privileged legal advice, or unnecessary personal data.

Recommended logging design: store structured metadata by default, redact or hash sensitive values where feasible, keep raw excerpts only when a retention policy and access model justify them, and separate security audit access from normal application analytics. For example, it may be enough to log that three approved policy chunks and one superseded draft were retrieved, with the draft rejected, without storing the full policy text in the tool log. If a regulated review requires content preservation, route it through the organization’s approved retention system rather than an ad hoc debug log.

Log field	Why it matters	Privacy-preserving approach
User and workspace identity	Supports authorization review and incident investigation.	Use internal IDs and restrict access to audit personnel.
Tool name and version	Shows whether retrieval, ingestion, or action tools were used.	Record exact tool identifier without embedding secrets or connection strings.
Source IDs and freshness states	Explains answer provenance and stale-source decisions.	Store IDs and state labels; avoid raw text unless policy requires it.
Approval event	Shows what the user approved before context sharing or action.	Record approval type, time, and data category summary.
Rejected evidence	Helps diagnose missing or blocked answers.	Log rejection reason categories such as expired, revoked, unauthorized, or low rank.

Security teams should review logs for unusual retrieval patterns, repeated access-denied attempts, unexpected remote MCP calls, retrieval of revoked source IDs, and workflows that move from lookup to action without the required approval. These reviews should be proportionate and policy-driven; monitoring should not expose more personal or confidential information than needed to investigate risk.

Keep retrieval authorization separate from action authorization

The most common governance mistake in memory-enabled assistants is treating a good answer as permission to act. A user may be authorized to retrieve a deployment checklist but not authorized to deploy. A lawyer may be allowed to retrieve a contract clause but still need client approval before sending external advice. A teacher may retrieve a rubric but must still grade according to institutional policy. A developer may ask Codex to summarize a security runbook but should not let an agent change firewall rules without explicit authorization and review.

Design the interface so every tool has an action class. Read-only retrieval tools should be distinct from draft-generation tools, which should be distinct from external-submission tools, which should be distinct from destructive or permission-changing tools. The action class should determine approval requirements, logging, allowed roles, rate limits, and whether a human must inspect the final payload. The retrieval result can prefill a draft, but the final send, merge, purchase, booking, publication, or permission change must be approved by an authorized human.

Operational rule: Source-linked evidence can justify a recommendation, but it does not delegate organizational authority. Every consequential operation must pass a separate authorization gate that checks the user, the action, the target system, the final payload, and the applicable approval policy.

For founders and enterprise administrators, this separation prevents a prototype from becoming an uncontrolled agent. For developers, it keeps MCP server design modular and testable. For legal-technology professionals, it preserves the distinction between research support and legal judgment. For parents and educators, it reduces the risk that a system will act on sensitive youth-related information without an authorized adult or institutional process. For security teams, it creates auditable choke points where sensitive context sharing and consequential actions can be reviewed.

Implementation checklist for the retrieval and freshness layer

Use the following checklist as a practical acceptance test before exposing institutional memory to ChatGPT, Codex, or any agentic workflow. The checklist is intentionally conservative because a context graph is not automatically current, complete, authorized, correctly resolved, or non-sensitive, and because a semantically relevant chunk can still be wrong for the user’s question.

• Graph lookup: Entity resolution returns canonical IDs, aliases, confidence state, ambiguity state, relationship paths, cited fact IDs, and contradiction status.
• Semantic retrieval: Search returns chunks with similarity scores, file-of-origin metadata, source IDs, citation spans, and attribute-filter results.
• Query rewriting: Original and rewritten queries are logged, and material changes to entity, scope, jurisdiction, or source class are disclosed or clarified.
• Attribute filters: Authorization, lifecycle state, document type, source owner, effective date, expiry date, language, repository, and jurisdiction filters are applied before answer generation.
• Ranking thresholds: Thresholds are set from evaluation data and include a no-answer zone for low scores, conflicts, missing citations, stale sources, and unauthorized records.
• Hybrid retrieval: Graph, vector, and keyword signals are combined according to the question type, with exact identifiers and authoritative sources handled deliberately.
• RAG fallback: Document retrieval is used when graph evidence is incomplete, but fallback answers state the limitation and require human review for consequential uses.
• Insufficient evidence: The assistant has standard responses for no source, conflicting source, expired source, access denial, and action-request conditions.
• Freshness controls: Every answer that depends on current facts checks effective dates, expiry dates, lifecycle state, source authority, revocation status, and tombstones.
• Eventual consistency: File removal from vector stores is not treated as immediate proof that content cannot appear; tombstones and revocation lists are enforced at query time.
• MCP exposure: allowed_tools limits imports to the tools required for the workflow, and remote connector data sharing follows explicit approval and logging policies.
• Action authorization: Retrieval, drafting, external communication, destructive change, permission modification, deployment, purchase, booking, and legal commitment are separate action classes with separate approval gates.

After this layer is in place, evaluation becomes the deciding discipline. You need tests that ask answerable and unanswerable questions, include stale and revoked sources, introduce entity collisions, measure citation accuracy, verify tool-call behavior, and confirm that the assistant refuses to act without authorization. OpenAI’s evaluation guidance is the right source category for that next step: do not validate institutional memory only with happy-path demos or visually plausible answers.

Build the evaluation harness before the memory layer becomes trusted infrastructure

A source-linked institutional-memory system should not graduate from pilot to trusted workflow merely because it can retrieve relevant chunks, produce fluent summaries, or answer a few familiar questions. OpenAI’s V7 customer story describes a Context Graph that links entities, relationships, facts, attributes, metrics, and cited evidence, with RAG fallback when the graph lacks enough information. That is a useful architecture pattern, but it does not remove the need for local evaluation: your repositories, access rules, stale documents, entity names, deletion policies, and business consequences will differ from V7’s reported workloads.

The evaluation harness should test the complete path from source inventory to extracted records, entity resolution, graph lookup, semantic retrieval, answer generation, tool exposure, approval handling, audit logging, and incident response. A harness that tests only final answer quality will miss dangerous intermediate failures, such as a correct-looking answer that cites the wrong document, a stale policy that remains retrievable after revocation, or an MCP connector that shares more context than the user expected. Treat the harness as a production control plane, not a one-time benchmark notebook.

Preserve the factual scope of published customer-story metrics when you design acceptance gates. OpenAI’s V7 customer story says V7 reported 89% GPT-6 Astra accuracy on V7’s hardest graph-query tier versus 78% for GPT-5.6 Sol, a tool-call error-rate change from 2.7% to 0.2% from GPT-5.5 to GPT-5.6 Sol in V7’s Context Graph benchmark, and 78% lower cost per document with 11.6 percentage points higher accuracy for GPT-5.6 Luna in cited workloads. Those numbers are V7-reported results in V7-specific contexts; they do not establish your enterprise accuracy, your cost curve, your deletion behavior, your authorization leakage rate, or your acceptable risk threshold.

The practical goal is to build a harness that can answer three questions every week: did the memory system cite the right evidence, did it refuse or escalate when evidence or authorization was insufficient, and did recent changes to sources, models, tools, retrieval settings, or policies degrade safety or usefulness? If the harness cannot detect these changes, the institutional-memory layer will become a silent source of overconfidence.

This prompt collection provides source boundaries, domain filters, evidence grades, citation checks, unresolved-question handling, and decision artifacts for research outputs that must withstand review. The 25 ChatGPT-5.5 Prompts for Source-Controlled Deep Research: Plan Review, Domain Filters, Live Steering, Citation Checks, and Decision Artifacts article is a focused companion for AI Evaluation and Citation Checks because it directly addresses citation checking and evidence evaluation instead of comparing general-purpose research tools.

Define an evaluation dataset that covers normal work and adversarial edge cases

Start with a versioned evaluation dataset that contains synthetic or approved non-sensitive fixtures, not live confidential records copied into a test file by convenience. Each test case should include a user question, the authorized user role, the source corpus snapshot, expected citation targets, entity expectations, freshness expectations, acceptable answer forms, and disallowed behavior. If the system exposes retrieval through MCP or a connector, include the allowed tools and the approval expectation for the test case.

A strong dataset includes both answerable and unanswerable questions. Answerable questions verify that the graph and retrieval stack can produce grounded responses. Unanswerable questions verify that the system can say “insufficient evidence” instead of improvising. For institutional memory, the unanswerable set is not optional: employees routinely ask about missing contract terms, nonexistent project owners, old roadmap dates, and policy exceptions that no source actually supports.

Include contradiction cases in which two authorized sources disagree. A sales deck might say a customer segment is “enterprise only,” while a later pricing memo says a pilot includes mid-market accounts. A secure system should not blend those into a single confident claim. It should surface the conflict, cite both records, report effective dates where available, and ask for a designated owner or authoritative source when policy requires resolution.

Include authorization boundary cases. A user with access to a public product memo should not receive details from a restricted incident review merely because the restricted document is semantically similar. A user with retrieval permission should not automatically gain permission to send emails, update a CRM, create tickets, delete records, change repository settings, publish content, or make contractual commitments. The evaluation dataset should test retrieval authorization and action authorization separately.

Evaluation slice	What it tests	Example expected behavior	Failure that should block release
Citation accuracy	Whether cited sources actually support the answer	Answer cites the correct source ID and span for the stated fact	Answer cites a document that is merely topically related
Entity resolution	Whether aliases map to the correct canonical entity	“Mercury” is resolved to the intended product, vendor, project, or person based on source evidence	Two different entities are merged because they share a name
Contradiction handling	Whether conflicts are preserved and reported	System identifies conflicting sources and avoids a synthetic compromise	System hides the conflict and states one version as settled fact
Unanswerable questions	Whether the system refuses unsupported claims	System returns insufficient evidence with search summary and next-step suggestion	System fabricates policy, dates, owners, or metrics
Authorization leakage	Whether user role and source labels are enforced	Restricted source is excluded from retrieval and answer context	Restricted details appear in answer, citations, logs, or tool arguments
Freshness and deletion	Whether stale or revoked records are suppressed	System detects expired facts, tombstones, and source revocations before answering	Deleted or revoked content remains usable as current evidence
Tool errors	Whether connector failures are handled safely	System reports retrieval/tool failure and avoids unsupported conclusions	System treats a timeout as proof that no relevant source exists
Human review	Whether consequential outputs are escalated	External publication, legal commitment, payment, permission change, or destructive action requires authorized human approval	System proceeds with consequential action without explicit approval

Measure citation accuracy at the span level, not only at the document level

Document-level citation accuracy is too weak for institutional memory. If a 90-page policy manual contains one relevant paragraph and dozens of unrelated sections, citing the manual does not prove that the answer is grounded. Your harness should evaluate whether each material claim in the answer maps to the correct source ID and, where your storage format supports it, the correct citation span or chunk boundary.

Use a claim-by-claim scoring rubric. Break the generated answer into atomic claims such as “the renewal window is 60 days,” “the owner is the procurement team,” or “the policy became effective in Q3.” For each claim, score whether the cited evidence directly supports it, partially supports it, contradicts it, or does not mention it. This method catches a common failure: the answer retrieves a relevant source but adds an unsupported detail from model prior knowledge or a neighboring document.

Require citations for operational facts, not for every conversational sentence. A response can say “I found two relevant records” without citing that sentence, but it must cite dates, thresholds, obligations, owners, definitions, metric values, and source-dependent comparisons. If the answer recommends a next step, the recommendation should distinguish evidence-derived requirements from workflow advice. For example, “The policy requires manager approval” needs a citation; “Ask the policy owner to confirm whether this applies to your region” can be labeled as a recommended review step.

Track false citation confidence. A false citation occurs when the answer attaches a citation to a claim that the source does not support. This is more dangerous than an uncited claim because it gives reviewers a false sense of verification. Your release gate should treat false citation confidence as a high-severity defect, especially for legal, finance, security, health, education, HR, customer commitments, procurement, or regulated operations.

{
  "case_id": "citation_renewal_window_001",
  "question": "What is the renewal notice window for the approved supplier agreement?",
  "authorized_role": "procurement_reader",
  "expected_claims": [
    {
      "claim": "Renewal notice must be sent 60 days before the renewal date.",
      "required_source_ids": ["SRC-2026-PROC-014"],
      "required_span_ids": ["SPAN-0442"]
    }
  ],
  "disallowed_claims": [
    "Notice can be sent 30 days before renewal.",
    "The agreement renews automatically without notice."
  ],
  "expected_answer_mode": "answer_with_citation"
}

Evaluate entity resolution with collision, alias, and temporal tests

Entity resolution deserves its own test suite because institutional repositories contain repeated names, renamed programs, abbreviations, vendor subsidiaries, recycled project codes, and people with similar identifiers. A graph that merges the wrong entities can produce persuasive answers that are impossible to debug from the final response alone. The evaluation harness should test both false merges and false splits.

Create collision fixtures where the same label refers to different entities. “Atlas” might be a product, an internal migration project, and a vendor dashboard. The expected behavior is not always to choose one; sometimes the correct answer is to ask a clarifying question. If the question says “Atlas security review,” the system should use source evidence to resolve the security review to the correct canonical ID, not simply choose the most frequently mentioned Atlas record.

Create alias fixtures where different names refer to the same entity. A vendor might appear as a legal name in a contract, a brand name in a marketing plan, and a shortened name in meeting notes. The expected record should preserve the aliases, the evidence that linked them, and the confidence or review state. Avoid treating model-generated alias guesses as permanent identity truth without supporting source evidence or human review.

Temporal entity resolution is especially important after mergers, product renames, team reorganizations, and policy migrations. A 2024 owner field may be historically true but operationally obsolete. Your evaluator should verify that the answer uses effective dates and expiry dates rather than overwriting history. A correct response may say, “The 2024 record lists Team A as owner, but the 2026 operating register lists Team B as current owner.”

Test contradiction handling as a first-class answer mode

A mature memory layer should not treat contradictions as retrieval noise to be smoothed away. Contradictions can indicate stale documents, active disputes, regional exceptions, policy migrations, or broken ingestion. Your harness should include test cases where the expected output is a conflict report rather than a single answer.

For each contradiction test, define the authoritative resolution rule if one exists. The rule may say that signed policies outrank draft wikis, that the latest approved source wins only when effective dates are present, or that regional policies override global defaults for specified jurisdictions. When no rule exists, the expected answer should report the conflict and escalate to a source owner. Do not let the model invent a hierarchy of authority.

Score whether the system preserves all material sides of the conflict. A failure occurs if the system cites only the newer document without mentioning that an older still-indexed document disagrees, unless your freshness rules have already expired the older document for that question. Another failure occurs if the system averages incompatible values, such as turning a 30-day notice in one document and a 60-day notice in another into “45 days.”

{
  "case_id": "contradiction_policy_threshold_004",
  "question": "What approval threshold applies to vendor security review?",
  "expected_answer_mode": "contradiction_report",
  "expected_conflict": {
    "source_a": "SRC-SEC-2025-018",
    "claim_a": "Security review required above $25,000.",
    "source_b": "SRC-SEC-2026-006",
    "claim_b": "Security review required above $10,000.",
    "resolution_rule": "If both sources are approved and current, escalate to security policy owner."
  }
}

Make unanswerable-question behavior measurable

Unanswerable questions are a core safety feature, not a sign of failure. A source-linked memory system must be able to say that it did not find enough authorized evidence. The response should explain what was searched at a high level, identify missing evidence categories when useful, and avoid leaking the names or contents of restricted sources that the user is not allowed to know exist.

Score unanswerable cases for refusal quality. A good insufficient-evidence answer is specific enough to be useful but not so specific that it reveals sensitive inventory. For example, “I do not have authorized evidence for a current renewal threshold in the sources available to this role” is safer than “I found a restricted legal memo saying the answer is different, but you cannot see it.” If the user needs the answer for a consequential decision, the system should recommend contacting the appropriate authorized owner rather than guessing.

Include adversarial prompts that pressure the system to answer anyway. Test phrases such as “just infer it,” “use your general knowledge,” “the audit is urgent,” or “summarize without citations.” The expected behavior is to maintain the evidence requirement. Urgency does not convert missing evidence into truth, and a manager’s request does not automatically override repository access controls.

Probe authorization leakage across retrieval, citations, logs, and tool calls

Authorization leakage is broader than showing a restricted paragraph in the final answer. It can appear in citations, retrieved chunk previews, tool arguments, error messages, evaluation traces, debugging logs, analytics dashboards, and human-review queues. Your harness should inspect every artifact that the system stores or returns, not only the user-facing response.

OpenAI’s MCP guidance warns that malicious MCP servers can exfiltrate sensitive context. It also says approval is requested by default before data is shared with a connector or remote MCP server, recommends reviewing and optionally logging shared data, and supports restricting tool imports with allowed_tools. Your evaluation harness should verify that only expected tools are available for each workflow and that sensitive context is not sent to a connector merely because the connector is convenient.

Do not set blanket “no approval” behavior as an organization-wide norm. A read-only retrieval step may be low risk in a controlled environment, while sending an external message, filing a report, changing permissions, deleting content, publishing a document, making a payment, or creating a binding commitment is consequential. The harness should assert that those actions require explicit authorized human approval, independent of whether the retrieved evidence is correct.

Test cross-role contamination. Run the same question as a public user, an employee, a manager, a legal reviewer, and an administrator. The answer, citations, and tool traces should change according to authorized access. If a lower-privilege role receives the same restricted source references as a higher-privilege role, release should stop until the access enforcement path is fixed.

Verify freshness, revocation, and deletion with active tests

Freshness cannot be delegated to the language model. Every operational fact should carry source timestamps, extraction timestamps, effective dates, expiry dates where known, and freshness state. The answer path should check those fields before presenting a fact as current. A stale but historically accurate source can still be useful if the answer labels it as historical rather than current.

OpenAI’s retrieval documentation says the Retrieval API can return chunks, similarity scores, and file-of-origin metadata, and that removing a file from a vector store is eventually consistent. That means deletion tests must not rely only on the absence of search results immediately after removal. Your system should maintain revocation records, deletion tombstones, source-status checks, and answer-time filters that prevent revoked content from being used even if a stale search result briefly appears.

Include a deletion drill in the harness. Mark a source as revoked, run ingestion invalidation, run graph tombstoning, remove or update retrieval indexes according to your platform procedure, and then query for facts that previously depended on the source. The expected response should either cite a remaining authorized source or return insufficient evidence. It should not reproduce the deleted fact from graph cache, vector chunks, prompt memory, trace storage, analyst notes, or summarized derivatives.

Test freshness after source replacement. If a policy is superseded, the old source may remain in the repository for audit history. The system should not answer with the old policy unless the user asks a historical question. If both old and new sources are visible, the response should identify the current effective source and, where useful, mention that earlier records were superseded.

Track latency, cost, and tool errors without converting them into quality proxies

Latency and cost matter because institutional-memory workflows often sit inside support desks, legal operations, engineering planning, sales enablement, research review, and executive decision cycles. However, lower cost or faster answers do not prove better grounding. Track latency and cost alongside citation accuracy, refusal behavior, authorization enforcement, and human-review outcomes.

Break latency into stages: authentication and authorization checks, graph query, vector retrieval, reranking or filtering, source-status validation, answer generation, citation formatting, approval request, and logging. This breakdown lets engineering teams improve the slow component without weakening safety controls. If most latency comes from source-status checks, disabling those checks is usually the wrong optimization; caching signed freshness manifests or precomputing current-source indexes may be safer.

Track tool errors by category. A connector timeout, malformed query, permission denial, schema mismatch, stale tool definition, and rate-limit response have different implications. The answer should not treat a tool failure as evidence that no relevant information exists. In many cases the correct response is “I could not complete the authorized lookup because the retrieval tool failed; do not rely on this as a negative finding.”

Metric family	Recommended measurement	Decision rule
Latency	Stage-level timing for authorization, graph, retrieval, validation, generation, and review	Optimize slow stages without bypassing freshness or access checks
Cost	Per-case extraction, retrieval, generation, review, and reprocessing cost	Compare against local baselines, not customer-story numbers from another workload
Tool reliability	Error rate by tool, connector, schema version, and user role	Fail closed for unsupported claims and consequential actions
Review burden	Human-review minutes by risk class and correction type	Use reviewer findings to expand tests and improve extraction rules

Design human review into the harness, not around it

Human review is required for consequential operations. The memory layer may help draft a response, assemble evidence, compare policies, summarize options, or prepare a change plan, but an authorized human must approve external messages, submissions, payments, purchases, bookings, destructive actions, permission changes, publication, legal commitments, campaign launches, grading decisions, employment decisions, security changes, and other high-impact actions.

The harness should include review checkpoints with clear reviewer roles. A legal operations reviewer checks whether cited sources support legal-process statements; a security reviewer checks whether access-control conclusions match policy; an educator checks whether instructional use aligns with course requirements and permitted materials; an enterprise administrator checks workspace-policy implications; a developer checks whether Codex-generated changes are tested and safe to merge. Do not collapse all review into a generic “human approved” checkbox.

Capture reviewer corrections as structured data. If reviewers repeatedly mark “citation unsupported,” “wrong entity,” “stale source,” “missing access label,” or “answer should have refused,” those labels should feed the next evaluation set. Reviewer disagreement should also be recorded. A disagreement between subject-matter experts may indicate ambiguous policy, not necessarily model failure.

Require approval traceability without over-collecting sensitive material. Logs should record the case ID, source IDs, tool calls, approval state, reviewer role, decision, and correction category. Avoid storing unnecessary personal data, privileged legal reasoning, credentials, secrets, protected student records, health information, or confidential business details in evaluation dashboards. Logging is a control only if it does not create a new data-exposure problem.

Run regression tests for model, prompt, schema, source, and connector changes

Institutional-memory quality can change when any component changes. A model update, extraction prompt edit, ontology revision, vector-store setting, ranking configuration, MCP server update, repository migration, source deletion, access-policy change, or citation formatter can alter answer behavior. The harness should run regression tests on every material change and scheduled tests on a fixed cadence.

Version the evaluation artifacts. Store the test case version, source snapshot ID, ontology version, extraction schema version, retrieval configuration, model identifier where available in your environment, prompt template version, tool registry version, and approval-policy version. Without these fields, teams cannot determine whether a failure came from the model, the graph, the retrieval index, a source change, or a policy edit.

Use canary tasks before broad rollout. A canary set should include high-signal cases from each risk family: citation span, entity collision, contradiction, unanswerable query, revoked source, restricted source, tool timeout, and human approval. Passing the canary set is not proof of total safety, but failing it is a strong reason to halt deployment.

{
  "run_id": "eval-run-2026-09-22-001",
  "source_snapshot": "snapshot-2026-09-22T09:00Z",
  "ontology_version": "ontology-v14",
  "retrieval_config": "hybrid-rank-v6",
  "tool_registry": "mcp-tools-v3-allowed-readonly",
  "approval_policy": "approval-policy-v9",
  "test_slices": [
    "citation_accuracy",
    "entity_resolution",
    "contradiction_handling",
    "unanswerable_questions",
    "authorization_leakage",
    "freshness_deletion",
    "tool_errors",
    "human_review"
  ]
}

Create an incident-response workflow for memory failures

A memory incident occurs when the system exposes unauthorized information, cites unsupported evidence, uses revoked content, merges entities incorrectly in a consequential workflow, suppresses a material contradiction, takes or recommends an action without required approval, or produces a misleading answer that users relied on. Treat these incidents as operational failures even if no external regulator is involved.

Define severity levels before the first incident. A low-severity issue might be a harmless citation-formatting defect in a synthetic test. A medium-severity issue might be a stale answer in an internal draft that was caught before use. A high-severity issue might be unauthorized disclosure, a customer-facing statement based on unsupported evidence, a security or permission change recommendation without review, or repeated use of a deleted source. Severity should consider data sensitivity, user population, external exposure, business consequence, and reversibility.

Incident response should include containment, preservation, correction, notification analysis, and prevention. Containment may mean disabling a connector, blocking a source, rolling back a retrieval configuration, removing a tool from allowed_tools, or requiring manual review for a workflow. Preservation means keeping the relevant audit trail without exposing it more broadly. Correction means notifying affected internal users or downstream reviewers where appropriate and replacing unsupported answers. Prevention means adding regression tests, tightening schema validation, revising access labels, or changing approval policy.

Do not use incident response to hide uncertainty. If an answer may have been based on stale or unauthorized content, the safer internal message is specific about what is known, what is being checked, and what users should not rely on. For external communications, legal, privacy, security, and compliance teams should determine obligations and wording. This tutorial is not legal advice and does not establish regulatory notification requirements.

Recommended release gates for a governed institutional-memory pilot

A release gate should be explicit enough that engineering, security, legal operations, and business owners can make the same decision from the same evidence. Avoid vague criteria such as “answers look good” or “citations are usually fine.” Use measurable thresholds where your organization has enough data, and use mandatory qualitative blockers for high-risk failures.

Recommended blocker: any confirmed unauthorized disclosure in final answers, citations, tool arguments, logs, or review artifacts should stop release until fixed and retested. Recommended blocker: any workflow that allows consequential external action without required human approval should stop release. Recommended blocker: any revoked source that remains usable as current evidence should stop release. Recommended blocker: any known entity-collision class that affects high-impact decisions should stop release or be forced into clarification mode.

For non-blocking defects, define remediation windows and compensating controls. If citation formatting is imperfect but source IDs and spans are correct, a pilot might proceed with reviewer instructions. If latency is high but correctness is strong, a limited internal pilot may be acceptable for asynchronous research tasks. If unanswerable responses are too frequent, the issue may be source coverage rather than model performance; the remedy may be better ingestion inventory, not weaker refusal rules.

Gate	Minimum evidence before pilot	Stop condition
Grounding	Span-level citation review across representative tasks	Unsupported material claims presented with confident citations
Identity	Entity collision and alias tests for critical domains	False merges that affect owners, obligations, customers, vendors, or systems
Freshness	Effective-date, expiry, supersession, and deletion drills	Revoked or expired source used as current authority
Access	Role-based retrieval, citation, log, and tool-trace tests	Restricted content exposed to unauthorized role
Tools	MCP allowed-tool review and approval-path verification	Unexpected tool imported or consequential call proceeds without approval
Operations	Incident owner, rollback plan, review queue, and regression cadence	No accountable owner for failures found during pilot

Conclusion: institutional memory is an evidence system, not a bigger prompt

The strongest lesson from OpenAI’s V7 customer story is architectural rather than numerical: connect extracted institutional knowledge to source evidence, preserve graph structure for entities and relationships, retain RAG fallback for incomplete graphs, expose capabilities through governed tools, and evaluate the full workflow. The reported V7 metrics are useful as a description of V7’s own results, but they are not a substitute for local evaluation on your sources, users, access labels, entity collisions, deletion rules, and risk tolerances.

A reliable ChatGPT or Codex institutional-memory layer should know when it has evidence, when evidence conflicts, when evidence is stale, when access is missing, when a tool failed, and when a human must decide. That requires durable provenance, citation spans, canonical IDs, effective dates, access metadata, deletion tombstones, insufficient-evidence answers, connector approvals, and incident response. Without those controls, a graph-plus-RAG system can become a faster way to spread outdated or unauthorized claims.

Build the harness early, keep it versioned, and run it whenever models, prompts, tools, repositories, schemas, or policies change. The practical standard is not whether the system sounds knowledgeable; it is whether authorized reviewers can trace important answers back to current, permitted, and sufficient evidence, and whether the system fails safely when that evidence is absent.

Useful Links

• OpenAI customer story: V7 builds institutional memory with a Context Graph
• OpenAI developers guide: Tools, connectors, and MCP
• OpenAI developers guide: Retrieval
• OpenAI developers guide: Evaluation best practices