A Visitor Kiosk Thread Should Not Become a Curator’s Working Memory
A museum runs an internal caption-review assistant on a desktop and a tablet. Curators want to resume a draft discussion when moving between devices, while the public kiosk must never inherit the same conversation. OpenAI’s Conversations API provides a durable conversation object with an identifier that can be passed into Responses requests. The identifier offers continuity, not automatic user isolation. The application’s authenticated account and authorization rules determine which person may reopen which thread. A kiosk session, a conservation case and a private donor inquiry therefore need separate conversation IDs. If two people reuse one ID, the model may see context that was never intended for the second person, even when the visible user interface looks like a fresh chat.
Distinguish a Durable Conversation From a Response Chain
The Conversations API stores an ordered collection of items, including messages and relevant tool interactions, and can be used across sessions and devices. The alternate Responses approach, previous_response_id, links one response to another rather than creating the same explicitly managed durable object. OpenAI also supports manually supplying prior items. These are different state-management decisions, not interchangeable privacy controls. OpenAI documents that conversation objects and their items are not subject to the default 30-day TTL for ordinary stored response objects. That durability makes the API convenient for longer projects but raises retention questions. A curator must know which project a thread belongs to and how it can be retired when the work or its authorization changes.
Assign IDs on a Trusted Server, Not in a Browser Shortcut
Create a conversation only after the application’s server verifies the account, collection and role. Store the returned ID in a database row keyed to an internal case identifier and access policy. When a curator opens the tablet, the server looks up the ID after another authorization check. Do not accept an arbitrary conversation ID from a public URL and then pass it to Responses. An opaque ID is still a reference to persistent data, not proof that a caller is allowed to read it. Treat the device as replaceable; keep the mapping and permission decision on the server. Separate staging IDs from production IDs, and never reuse a thread just because the same prompt template appears in two projects.
Attach New Responses and Keep the Source Record Independent
In the supported Responses workflow, pass the selected conversation into the new request so its accumulated items can provide context. Keep the approved museum catalog row, source scans and legal consent separately in systems with their own access controls. Context is helpful for drafting; it is not an immutable evidence ledger. An assistant may remember a preliminary attribution that a researcher later overturns. The application should send the current verified record or ask the researcher to review it again instead of trusting an old message. Attach the source record’s revision and any review decision to your local audit log. If the model proposes a revised caption, retain it as an editable candidate until an authorized reviewer approves the exact text.
Compare Three Session Designs Before Choosing One
Consider three invented scenarios. A shared kiosk conversation receives visitor questions all day: that creates obvious cross-person leakage and should be avoided. A curator opens a long-lived private thread, but the app fails to recheck permissions when they change departments: the persistent ID becomes an authorization risk. In the preferred design, each case has a dedicated thread, and the server verifies the account’s current role every time it retrieves or updates that mapping. These are architectural examples, not actual OpenAI API test results. A sensible UI also shows which collection and case are active so an editor does not accidentally paste sensitive evidence into the wrong thread.
Review Retention Before Capturing Sensitive Material
OpenAI states that conversation objects and their items do not follow the default 30-day TTL for response objects. Do not assume a Responses store:false setting gives a durable conversation a short retention period. Define a specific local retention policy for case completion, staff departure and sensitive-subject withdrawal. Consult the organization’s privacy and records officers about what kinds of personal information may enter a thread at all. Prefer accession references, redacted quotations and approved summaries over raw contact details. Review the supported conversation and item deletion operations, then document what your application deletes, what is retained elsewhere and what staff must do to request a deletion. An application-side hiding flag is not an API deletion operation.
List Items for a Reviewable Timeline, Not a Fake Transcript
The Conversations items endpoint supports listing items with pagination and ordering. When building an editor’s history panel, handle pagination rather than showing only the first page as though it were complete. Display item type and status appropriately; tool calls and outputs are not just ordinary chat sentences. Do not infer that a returned item is factually correct because it is persistent. A local audit entry should include the authorized actor, collection revision, timestamp and specific change approved or rejected. If the list is incomplete, the UI should say so. This is especially important when an editor cites a prior assistant response in a provenance discussion or an accessibility review.
Test Permission Changes and Cross-Device Hand-offs
Use fictional collection IDs and synthetic catalog records for a staging exercise. Create two curator accounts, two project threads and a separate kiosk thread. Confirm that a request for someone else’s ID is denied by the application before making an API call. Switch the same authorized curator from desktop to tablet and check that the correct active project resumes. Then revoke their access and verify that the stored ID no longer grants entry. Test a deleted case, a missing conversation, a paginated item list and a draft that cites an obsolete catalog revision. These are proposed acceptance tests, not tests we executed against a live OpenAI account.
Put an Explicit Approval Gate Between Context and Publication
A conversation may help editors remember objections, compare wording and recover work, but it should not publish a museum description automatically. Keep a source-revision identifier next to each draft, require a separate reviewer decision and show the exact approved text. A returning curator should be able to tell an unfinished suggestion from a published catalog entry. When a long conversation becomes stale, start a new case thread or deliberately summarize only verified facts rather than carrying every assumption forward. Success means correct session isolation, controlled retention and traceable editorial decisions—not simply that the assistant remembers what was said last week.
How We Research
For this guide, we reviewed the official product documentation on November 8, 2026: OpenAI conversation state guide, OpenAI Conversations API reference, OpenAI Conversation items listing, OpenAI API data controls. We checked the named setting or feature against its published behavior, mapped the documented constraints to the specific hypothetical scenario, and reviewed whether the topic duplicated titles in the supplied LabFin WordPress inventory or prior B0267–B0277 ZIPs. No authenticated vendor service was run; we did not perform a benchmark, observe real customer data, verify third-party rights or claim operational outcomes. All illustrated records and comparisons are teaching examples. Confirm product documentation and security requirements again before implementing a workflow in a real organization.
Frequently Asked Questions
No. A Conversation is an explicitly managed durable item container; previous_response_id links responses in a chain. Both need application-level access control.
OpenAI says conversation objects and their items are not subject to the default 30-day stored-response TTL. Plan a separate retention and deletion process.
Do not. That would mix context and could expose prior user information. Assign threads by authorized project and session.
No. An ID identifies a conversation. Your own backend must authenticate the caller and authorize that particular conversation.
No. Store source records and human approval independently; earlier model messages may be stale or incorrect.