OCI Generative AI memory needs a project-level retention and deletion test

Choose the project boundary from the workload's data purpose

The direct answer is to create or approve a project only after the CIO can state which workload it serves, whose information may enter it, which business records are authoritative, what context may persist, and who may administer or call it. A project is a useful technical boundary, but the organization still decides whether one project may contain several teams, customers, jurisdictions, data classes, or decision purposes. Long-term memory that improves continuity for one service may create inappropriate cross-session context for another. Files and conversations that are acceptable for research may not be acceptable for employment, legal, financial, clinical, or customer decisions. Project isolation should follow those distinctions rather than convenience alone.

Test memory and compaction as transformations

Long-term memory extracts information for later recall, while short-term compaction summarizes earlier conversation history. The CIO should treat both as governed transformations rather than invisible performance features. Representative tests should show what is selected, omitted, generalized, corrected, or carried into a later interaction; whether source and time context remain recoverable; and how a user can challenge a stale or inappropriate memory. Test contradictory updates, revoked preferences, sensitive details, mistaken identities, changed permissions, and facts whose meaning depends on a full prior exchange. A smaller context window or smoother conversation is not acceptable if compaction removes a qualification that a human needs to make the right decision.

Reconcile retention, access, and deletion across artifacts

OCI documents separate retention for responses and conversations and states that project deletion removes associated artifacts. The implementation review should identify the configured duration for every artifact class, the event that starts the clock, backups or replicas, exports, logs, connected stores, evaluation copies, and any records retained outside the project. It should also distinguish permission to use a project from permission to create, delete, or administer one. Run a dated deletion test with a representative response, conversation, file, container, and memory-derived fact; then verify what disappears from user, API, administrative, observability, and downstream views. A successful project deletion claim cannot establish the fate of copies the buyer created elsewhere.

Release only with an owner for lifecycle exceptions

Production approval should name owners for data purpose, IAM, memory policy, retention, records obligations, user correction, incident response, and service recovery. The release record should preserve the project identifier, settings, model and API versions, connected systems, evaluation population, known gaps, deletion evidence, and conditions that require reapproval. Those conditions include a new user population, data class, region, integration, memory mode, retention value, compaction behavior, model, or downstream use. Oracle's documentation can support the architecture question, but configured behavior and observed evidence decide whether the project actually functions as the intended lifecycle and compliance boundary. If ownership or deletion cannot be demonstrated, memory should remain off or the workload should remain outside production.

Turn this source into a reviewable decision

For AI for CIOs, use this briefing as a dated decision record rather than a substitute for the source. Preserve Projects | OCI Generative AI, the exact URL, the August 22, 2026 review date, the supported facts above, the editorial interpretation, the limitations, and any buyer-specific evidence. Link that record to the decisions most directly affected: Enterprise AI platform architecture; Enterprise knowledge retrieval; Identity and agent access; Operations and incident intelligence. State whether the source changes the scope, evidence requirement, control, sequence, or only the language used to describe the decision.

Before action, name the accountable owner, affected population and workflow, exact offering or configuration, source data and rights, human decision point, exception and appeal path, complete cost, expected benefit, failure and stop conditions, retained evidence, and next review date. Keep official facts, provider statements, buyer observations, representative tests, measured outcomes, editorial inferences, and unknowns visibly separate. Reopen the record when the source, offer, model, integration, data, policy, population, responsible person, or measured result changes.

Limitations and unknowns

Oracle is the provider source. Its current OCI Generative AI documentation describes projects, project isolation, responses, conversations, files, containers, separate response and conversation retention, long-term memory, short-term memory compaction, project identifiers, permissions, and project deletion. It does not independently establish a buyer's tenancy, service entitlement, data purpose, information classification, configured retention, extracted memory, compaction fidelity, IAM enforcement, cross-region processing, backups, logs, downstream copies, deletion completion, legal applicability, service reliability, cost, or business outcome. Current contracts, architecture and data maps, project and IAM configuration, representative memory and deletion tests, records requirements, service evidence, and qualified architecture, data, security, privacy, records, business, procurement, and legal review control.