Claude in Chrome Compliance API for Pharma GxP

On September 18, 2026, Anthropic added Claude in Chrome transcripts to the local-session endpoints of its Compliance API (^[1]). The capability remains beta, is available only to Claude Enterprise organizations, and uses an existing Compliance Access Key with the read:compliance_user_data scope (^[2]) (^[3]). This is a meaningful evidence-export change for pharmaceutical and biotechnology organizations. It is not a declaration that browser workflows are compliant with Good Practice requirements, commonly called GxP, or with 21 CFR Part 11.

The transcript can establish what the user asked Claude, what Claude returned, and which tool calls and results reached the Claude application. It cannot establish everything that happened in Chrome or on the endpoint. Anthropic states that a local transcript reflects the conversation, not device activity (^[4]). Raw file bytes are not returned, host and device metadata are absent, and returned text or tool data may be truncated. The correct interpretation is therefore conversation evidence, not a complete browser audit trail.

The product also has material eligibility and retention boundaries. Organizations with HIPAA readiness enabled receive no local-session data (^[5]). Captured local content defaults to six years, unless a finite custom conversation-retention period applies (^[6]). Privacy, legal-hold, and regulated-record schedules must be reconciled before enablement.

The recommended architecture separates after-the-fact evidence from inline prevention. Export transcripts and activity metadata to a security information and event management system, preserve an immutable evidence copy, hash exported objects, and record export manifests. Put data loss prevention, endpoint policy, and browser controls before or around user action. Use inference hooks where their current prompt-side allow or deny behavior fits, but do not treat them as response-side controls. Finally, classify each proposed browser workflow against its predicate rule. FDA guidance says Part 11 scope should be interpreted narrowly and that organizations should determine and document which specific records are Part 11 records (^[7]) (^[8]).

The Claude in Chrome Compliance API decision is not mainly an application programming interface question. For a regulated enterprise, it is a data-flow question: which browser interactions become retained evidence, which controls can act before disclosure or action, and which records must be managed under a validated process. The September 2026 release makes a previously opaque application surface more observable, but the resulting record is bounded by what reached Anthropic's service.

That distinction matters in pharmaceutical work. A browser session might summarize public research, draft an internal memo, copy text from a controlled document, populate a web form, or influence a GxP decision. Those activities have different record status and risk. FDA's current Part 11 rule applies to electronic records created, modified, maintained, archived, retrieved, or transmitted under agency record requirements (^[9]). A transcript does not enter that scope merely because it is electronic. It may enter scope when it is itself a required record, replaces a required paper record, or becomes necessary context for a regulated decision.

This report therefore treats the transcript as one evidence source inside a larger architecture. It maps the transcript's contents and omissions, explains audit logging, data loss prevention (DLP), security information and event management (SIEM), eDiscovery, privacy, and retention responsibilities, and supplies a GxP record-assessment method. It also distinguishes product limits from planning arithmetic.

IntuitionLabs is an adjacent life-sciences advisor, not a competing browser-agent or compliance software vendor. Its published operating model emphasizes governed workflows and scaling from observed evidence (^[10]) and describes an information layer built around identity, permissions, retrieval, citations, evaluation, and accountable operation (^[11]). That perspective supports a control-design analysis without placing the consultancy in a product comparison.

Launch status, eligibility, and access

The release extends the Compliance API's local-session endpoint family to Claude in Chrome. The capability is documented as beta for Claude Enterprise organizations (^[2]). The access conditions are narrow:

• Organization tier: Claude Enterprise is required.
• Release stage: The Chrome transcript capability is beta at publication.
• Key type: A Compliance Access Key is required.
• Scope: read:compliance_user_data grants access to session metadata and transcripts (^[12]).
• Key design: Separate read-only export keys should be provisioned for separate consumers.

This is important operationally because capture is not retroactive. The Activity Feed starts recording when the API is enabled, and prior activity is not backfilled (^[13]). An approval date without a synchronized enablement, policy deployment, and verification step can create an evidence gap at the start of a pilot.

Browser-session data flow and endpoint family

Claude in Chrome runs on the user's machine. The local-session family exposes operations to list sessions, retrieve session metadata, and retrieve messages. Those endpoints are read-only. They do not provide a mechanism to edit a session or prevent an action.

The logical data flow is:

1. User and browser: The signed-in employee invokes Claude in Chrome.
2. Claude service: Prompts, assistant responses, and supported tool exchanges reach the service.
3. Compliance API: An authorized collector enumerates sessions, metadata, and paginated message content.
4. Normalization: The collector creates canonical event envelopes, provenance fields, and hashes.
5. Destinations: A SIEM receives searchable events, while an evidence store holds complete exports and manifests.
6. Governance: Privacy, legal, quality, and records teams apply access, review, hold, and disposal rules.

Collectors should checkpoint the last successful cursor and time window, retry safely, and avoid treating an empty response as proof that no browser activity occurred when an exclusion condition may apply. NIST recommends enterprise log-management infrastructure and robust log-management processes (^[14]).

What the transcript proves, and what it omits

Table 1 summarizes the evidentiary boundary. “Captured” means documented as available through the applicable transcript or feed, not independently verified as complete for every browser action.

Evidence element	Available source	What it can support	Material limitation
User prompts and assistant responses	Local-session messages	Conversation reconstruction and content review	Returned text blocks are subject to server limits; the transcript is not a screen recording.
Tool calls and results	tool_use and tool_result blocks	Which supported tools Claude invoked and what results reached the service	Tool input and result strings default to 10,000 bytes ([15]); truncated tool input may cease to be valid JSON.
Session identity and timing	Local-session metadata	Correlation to an Enterprise user and a collection window	Host, terminal, workspace, and device context are not supplied.
Resource events	Activity Feed	Administrative and resource-event chronology	The Activity Feed does not contain prompt text or model responses ([16]).
Files	Extracted or referenced content where represented in messages	Evidence that file-derived content reached the model	Raw file bytes are never returned through local transcript endpoints ([17]).
Chrome and device actions	Endpoint, browser, DLP, proxy, and application logs	Complementary proof of navigation, upload, download, clipboard, or local file actions	Device actions require separate telemetry and policy evidence.
Cost, tokens, and latency	OpenTelemetry or separate usage sources	Operational monitoring and cost correlation	Session transcripts do not supply these measures.
System prompt	Marker record	Indicates that system context existed	The local transcript exposes a marker, not the underlying system prompt.

The matrix shows why AI browser audit trail is an architectural outcome, not a synonym for one vendor export. The transcript is strongest for semantic conversation history. Endpoint and browser telemetry are stronger for device actions. DLP is stronger for prevention. Evidence confidence rises when a common user identifier, synchronized timestamps, policy version, browser device identifier, export manifest, and content hash connect those sources. NIST cautions that digital files are easy to change and recommends hashing digital objects as an integrity control (^[18]).

Retention, exclusions, and deletion boundaries

Retention configuration is a material architecture decision rather than a universal pharma rule. Changes can affect availability, and later lengthening does not restore transcripts that already expired (^[19]). Privacy, legal, and quality owners should approve changes before they affect retrievability. European Commission guidance describes storage limitation as retaining personal data no longer than necessary (^[20]).

Three boundaries need explicit acceptance tests:

• HIPAA-ready organizations: No local-session data is captured. A team cannot simultaneously assume this exclusion and claim the Compliance API supplies browser transcripts for electronic protected health information.
• Zero data retention: Local sessions subject to zero data retention are absent from list results and are not retrievable through the session endpoints.
• Session deletion: Upstream settings and downstream repositories must be governed together, with deletion authority and preservation holds explicitly assigned.
• Message pagination: The default page holds 100 messages, the maximum is 1,000, and pages can end early when response-size limits are reached (^[21]).
• Cursor lifetime: Message cursors expire 24 hours after a traversal begins, so long-running export jobs require bounded batches and restart logic (^[22]).

Evidence retrieval is not inline prevention

Four control types solve different problems. Table 2 compares them for a regulated browser workflow.

Control plane	Timing and evidence	Best use	What it does not establish
Compliance API	After the fact; rich session content and organizational records	Audit, eDiscovery export, retrospective DLP scanning, investigations, and evidence preservation	It cannot stop the prompt or browser action in real time.
OpenTelemetry	Streams telemetry while activity occurs to customer-operated infrastructure	Tokens, cost, latency, host context, operational correlation	It is not documented as the Chrome transcript source, and telemetry alone is not a complete regulated record.
Inference hooks	Before inference; current event is prompt-side allow or deny	Inline policy decision before a governed request reaches the model	Response-side enforcement is planned rather than currently available ([23]); hooks cannot rewrite or redact prompts.
DLP and endpoint/browser controls	Before and during user action	Classification, warning, blocking uploads, clipboard or browser actions, and device context	A block event does not by itself reconstruct the full Claude conversation.

The table supports a layered pattern. Microsoft documents that DLP can monitor data at rest, in use, and in motion (^[24]) and that endpoint controls can warn or block sensitive sharing to third-party generative AI sites (^[25]). DLP-monitored activities can also be recorded in the Microsoft 365 Audit log (^[26]). Those are control capabilities, not proof that a particular Claude workflow is validated or Part 11 compliant.

SIEM, archive, and eDiscovery ingestion blueprint

A production collector should separate searchable monitoring data from the authoritative evidence package. The following blueprint is vendor-neutral:

• Poll: Enumerate sessions and messages in fixed time windows, with a one-minute safety lag for the Activity Feed because new events are documented as queryable within one minute.
• Checkpoint: Persist cursor, request window, endpoint, organization identifier, page count, and collector version after each complete page.
• Normalize: Map user ID, session ID, product surface, content-block type, event time, ingestion time, and policy version into a stable schema.
• Preserve: Store the untouched response, request metadata, and a cryptographic hash in a versioned evidence repository.
• Index: Send a minimized derivative to the SIEM, excluding sensitive text fields that are not necessary for detection.
• Attest: Record exported object count, first and last timestamps, gaps, retries, and hash manifest.
• Reconcile: Compare session metadata, message counts, activity records, and collector failures against an independently generated export manifest.
• Route: Apply legal hold and regulated-retention classifications independently of the SIEM's default retention.

OpenTelemetry can complement this flow by correlating logs with other signals and by transforming telemetry before it reaches downstream systems (^[27]) (^[28]). Any transformation must be versioned, tested, and reversible through the preserved source export.

Several common platforms can receive the resulting records. Microsoft Sentinel accepts custom-format logs through its Logs Ingestion API and can transform data before storage (^[29]) (^[30]). Splunk's HTTP Event Collector accepts text or JSON payloads (^[31]). Elastic's custom HTTP JSON input supports transformation, rate limiting, pagination, response splitting, and collection state from prior events (^[32]) (^[33]). Cribl Stream can pull from REST API endpoints and supports secret-backed API-key headers (^[34]) (^[35]).

For preservation, an object store should prevent silent overwrite and support holds. Amazon S3 Object Lock can prevent deletion or overwrite and requires versioning (^[36]) (^[37]). Retention periods and legal holds are distinct mechanisms (^[38]). The archive design should preserve original exports plus normalized derivatives, because search indexes may truncate or transform content.

Least privilege, privacy, and key custody

The collector reads highly sensitive content. Treating it like an ordinary analytics integration is inappropriate. NIST defines least privilege as restricting access to the minimum needed for assigned tasks (^[39]). Its zero-trust guidance rejects implicit trust based solely on network location and focuses protection on resources (^[40]) (^[41]). Apply those principles to the source key, runtime identity, destination index, evidence bucket, decryption key, and analyst role.

Minimum controls include:

• Dedicated key: Create a read-only Compliance Access Key for collection, without delete scopes.
• Secret manager: Store it outside code and deployment files, encrypt at rest, audit access, and rotate through a controlled replacement process.
• Network boundary: Restrict collector egress and destination endpoints.
• Separation of duties: Separate collection administration, content review, key management, and legal-hold authority.
• Field minimization: Send only detection-relevant fields to the SIEM; keep full transcript text in the more restricted evidence store.
• Access logging: Monitor both source calls and destination reads, and reconcile administrative activity with evidence access.
• Privacy schedule: Define purpose, lawful basis, review date, deletion authority, and hold overrides before capture begins.

Where electronic protected health information is in scope, HIPAA requires access controls that allow only authorized persons and audit controls that record and examine system activity (^[42]) (^[43]). A cloud service that maintains electronic protected health information on behalf of a regulated entity requires a HIPAA-compliant business associate agreement (^[44]). HIPAA security documentation generally carries a six-year retention rule measured from creation or last effective date (^[45]). That is a documentation clock, not proof that Claude local-session capture exists in a HIPAA-ready tenant.

European Commission guidance says organizations should collect only personal data necessary for the stated purpose and retain it no longer than necessary (^[46]) (^[47]). Access should be limited to people with a need to know (^[48]). NIST Privacy Framework profiles can express requirements to external service providers and describe how those requirements will be verified and validated (^[49]) (^[50]). NIST also advises avoiding unneeded sensitive data in logs and restricting user access to most log files (^[51]) (^[51]).

Secret custody should be independently auditable. AWS Secrets Manager encrypts stored secrets with customer-owned keys and supports automatic rotation as often as every four hours (^[52]) (^[53]). A platform-specific rotation feature does not override Anthropic key-scope constraints, so replacement and cutover must be tested.

Why the API does not confer Part 11 compliance

Part 11 is a system and process control framework applied within the scope of FDA predicate rules. For closed systems, it calls for validation supporting accuracy, reliability, consistent intended performance, and detection of invalid or altered records (^[54]). It also requires accurate and complete human-readable and electronic copies, ready retrieval through the retention period, access restriction, and secure time-stamped audit trails (^[55]) (^[56]).

A Claude transcript can contribute to several controls, especially reconstruction and review. It does not by itself demonstrate validated intended use, electronic-signature linkage, complete device activity, authoritative source-data preservation, approved change control, or review execution. FDA recommends a justified, documented risk assessment to determine validation extent (^[57]). The assessment must cover the whole workflow, including the browser, identity provider, controlled source, Claude, collector, transformations, archive, review process, and final system of record.

Part 11 record-assessment worksheet

Table 3 is a decision worksheet. A “yes” answer does not automatically prohibit the workflow. It means the evidence and control burden rises.

Decision question	If yes	Required evidence or action
Does a predicate rule require the output or the underlying decision record?	Treat record classification as a quality decision.	Cite the rule, record owner, system of record, and retention clock. FDA recommends determining record status from predicate rules ([8]).
Does the electronic artifact replace a required paper record?	Part 11 scope is likely relevant.	Define the authoritative record and preserve content, meaning, and required metadata.
Does Claude create, modify, calculate, summarize, or transmit data used in a GxP decision?	Assess intended use and data criticality.	Validate the workflow proportionate to risk, not merely the API connector.
Is the transcript needed to reconstruct the decision?	Classify it as supporting metadata or a record component.	Preserve session, source references, reviewer disposition, policy version, and hashes.
Does the action occur only on the device or target website?	The transcript is incomplete evidence.	Add endpoint, browser, proxy, and target-application logs.
Is approval or authorship represented?	Signature requirements may apply.	Use an approved signature service with signer identity, time, meaning, and record linkage. Part 11 requires signatures to be linked to their records ([58]).
Could a prompt contain personal, health, confidential, or privileged information?	Apply privacy, confidentiality, and legal review before capture.	Minimize data, restrict access, define holds, and test exclusions.
Can the source or destination retain the record for the required period?	Reconcile vendor and predicate-rule clocks.	Export before expiry and verify retrieval, readability, completeness, and disposal controls.

The worksheet should produce a signed classification record, not merely a meeting note. It should identify the authoritative record, whether the Claude transcript is primary evidence, supporting metadata, or non-record telemetry, and which system owns retention. The National Archives describes trustworthy records as preserving content, context, and sometimes structure (^[59]), protecting them against unauthorized alteration (^[60]), and maintaining links across records that document an activity sequence (^[61]). For an AI interaction, context includes user, time, model surface, policy, source references, tool exchanges, review state, and collection provenance.

Pilot acceptance tests and go or no-go criteria

Before browser use enters a sensitive workflow, run a controlled pilot with synthetic data. Acceptance testing should cover:

• Eligibility: Confirm Enterprise status, beta acceptance, key type, scope, and enabled state.
• Identity: Verify every test session maps to the expected stable user ID and organization.
• Managed deployment: Verify that the extension policy applied on user devices, as Google recommends for managed Chrome deployments (^[62]). Force-installed extensions cannot be disabled or removed by users (^[63]).
• Coverage: Compare prompts, responses, tool calls, files, tabs, uploads, downloads, and target-site changes against every telemetry source. For endpoint DLP, verify both user and device are in policy scope (^[64]).
• Negative coverage: Demonstrate which local or network actions are absent from the transcript.
• Exclusions: Test HIPAA-ready and zero-data-retention behavior in the actual tenant configuration.
• Truncation: Send payloads around the documented default and server-maximum tool-block limits.
• Pagination: Exercise multi-page and maximum-page-size scenarios, early page termination, cursor restart, and duplicate suppression.
• Timing: Measure source-event to archive and SIEM availability under normal and peak pilot load.
• Completeness: Produce manifests, object counts, first and last timestamps, gap reports, and hashes.
• Immutability: Prove that retained evidence cannot be silently overwritten or deleted by the collector role.
• Review: Demonstrate content triage, quality review, privacy access, escalation, and disposition.
• Recovery: Rebuild state after a collector interruption without losing or duplicating evidence.
• Retention: Verify expiration, hold, restoration boundaries, and downstream deletion across all stores.
• Change control: Define requalification triggers for schema, API, extension, model surface, DLP policy, and collector changes.
• Human control: Confirm that regulated approvals occur in the designated validated system, not implicitly in the browser transcript.
• Access boundary: Exercise both allowed and blocked destinations. Chrome Enterprise can prevent access to a configured list of URLs (^[65]).

A go decision requires known coverage, acceptable residual risk, working preventive controls, verified exports, documented record classification, and accountable owners. A conditional go restricts browser use to named low-risk workflows and data classes. A no-go is appropriate when the workflow requires evidence the transcript cannot supply, when the tenant exclusion removes capture, when preventive controls cannot operate, or when required retention and deletion obligations cannot be reconciled.

The published numeric limits support capacity planning, but not an Anthropic performance benchmark. All Compliance API endpoints share 600 requests per minute per parent organization across keys and endpoint families (^[66]). The local transcript page permits up to 1,000 messages, although response size can end a page early. Therefore, request demand should be modeled from observed pages, not assumed message density.

Use this planning equation:

Required minutes = total transcript pages ÷ usable requests per minute

For a batch containing S sessions with a measured mean of P pages per session, the idealized request demand for message pages is S × P. At the full shared ceiling, idealized collection time is (S × P) ÷ 600 minutes. (Hypothetical Example): If a pilot observes 12,000 sessions and 2.5 pages per session, the message-page work is 30,000 requests, or 50 idealized minutes. That is arithmetic, not a service-level prediction. Production sizing must reserve capacity for session listing, metadata reads, competing Compliance API clients, retries, rate-limit backoff, response-size variability, network latency, and reconciliation.

Storage should likewise use measured pilot data. Microsoft Sentinel supports analytics retention up to two years and total data-lake retention up to 12 years, illustrating why the destination schedule must be configured rather than assumed (^[67]) (^[68]).

Archive bytes = sessions per day × mean exported bytes per session × retention days × replica factor

Add index overhead, hash manifests, encryption metadata, and hold growth separately. NIST's log-planning guidance says architects should determine storage needs at sources and centralized infrastructure, estimate transfer bandwidth, and define how long each event class must be preserved (^[69]) (^[69]). No public mean transcript size or sustained export benchmark was found, so a pharma organization should size storage from measured pilot exports rather than field limits.

Destination limits can introduce secondary truncation. Datadog accepts HTTP log ingestion, limits an uncompressed payload to 5 MB, and limits a single ingested log to 1 MB (^[70]) (^[71]). Its documented Audit Trail retention is 90 days when enabled (^[72]). This makes the untouched archive essential when a SIEM derivative splits, trims, omits, or expires content.

Retention comparisons also require care. Anthropic's six-year default is longer than some operational-log defaults but may be shorter or longer than a specific regulated, privacy, contractual, or litigation schedule. For example, certain drug batch records must be retained at least one year after batch expiration (^[73]), while some nonclinical-study records may require five years after submission to FDA (^[74]). The correct clock follows the record class and predicate rule, not the software default.

The September release shifts Claude in Chrome from an evidence blind spot toward an observable enterprise surface. The remaining design challenge is evidence composition. A defensible record will often combine transcript, activity event, endpoint event, DLP decision, target-application log, source document identity, and human review. NIST notes that the meaning of a log entry often depends on surrounding context (^[51]); that principle is especially relevant to agentic browser activity.

Three future changes would materially affect architecture:

• Release maturity: Beta-to-general-availability changes may alter schemas, eligibility, support commitments, or requalification obligations.
• Coverage expansion: More device or browser context could improve reconstruction, but would also increase privacy and retention exposure.
• Inline control maturity: Response-side hooks, richer DLP integration, or browser-native policy signals could narrow the gap between evidence and enforcement.
• Deletion and hold controls: More granular transcript deletion or preservation APIs would affect privacy and discovery design.
• Standard schemas: OpenTelemetry semantic conventions provide common names across logs, traces, metrics, profiles, and resources (^[75]). A stable AI-session schema could simplify cross-source correlation.

Governance teams should monitor release notes and schema changes, but avoid equating more telemetry with lower risk. Greater capture creates a more sensitive repository. NIST states that documentation can improve transparency, human review, and accountability (^[76]). Its AI Risk Management Framework says legal and regulatory requirements involving AI should be understood, managed, and documented (^[77]). It also calls for third-party AI controls to be identified and documented and for knowledge limits and human oversight to be recorded (^[78]) (^[79]). Each expansion should therefore trigger a joint security, privacy, legal, quality, and records assessment.

Does the Compliance API make Claude in Chrome Part 11 compliant?

No. It provides evidence that can support a controlled process. Part 11 applicability depends on predicate-rule scope and the intended use of the electronic record. System validation, access control, copies, retention, audit trails, signatures where applicable, procedures, and training remain organizational responsibilities.

Can the API be used for DLP?

It can support retrospective DLP scanning and investigation. It is read-only and retrieves records after the fact. Inline prevention belongs in browser, endpoint, network, or prompt-side controls. Anthropic's inference hook can deny a governed prompt before it reaches the model (^[80]), but it does not currently rewrite prompts or enforce on responses.

Are Claude in Chrome transcripts available in HIPAA-ready organizations?

No, according to the current local-session documentation. That exclusion means organizations handling electronic protected health information should not design a monitoring control that assumes these transcripts exist. HHS requires reasonable and appropriate administrative, physical, and technical safeguards for electronic protected health information (^[81]).

Does the transcript show every action Claude took in Chrome?

No. It shows supported conversation and tool content that reached the API. It does not show all endpoint, file, network, navigation, clipboard, upload, download, or target-application activity. Chrome Enterprise policy can separately block, allow, or automatically install an extension (^[82]), but extension deployment is not transcript completeness.

How should eDiscovery exports be preserved?

Keep the untouched API response, request and collection metadata, normalized derivative, cryptographic hash, transfer history, and export manifest. Apply legal hold in the evidence store, separate from ordinary retention. NIST defines chain of custody through documentation of each person who handled evidence (^[83]) and requires handlers to prevent compromise, contamination, or degradation (^[84]). Microsoft similarly distinguishes long-term retention from limited-duration eDiscovery preservation and gives holds precedence over ordinary retention settings (^[85]).

What should a pilot measure before production approval?

Measure actual bytes per session, pages per session, event-to-archive latency, missing-action categories, truncation frequency, retry rates, duplicate rates, reconciliation gaps, SIEM index growth, reviewer effort, and false-positive rates for preventive policies. Document which metrics are direct observations and which are derived planning estimates.

The Claude in Chrome Compliance API for pharma is best understood as a new evidence source with clear boundaries. It makes prompts, responses, and supported tool exchanges available to authorized Enterprise collectors, while leaving important device, browser, file, network, and target-application activity outside the transcript. Beta status, tenant eligibility, HIPAA-ready and zero-data-retention exclusions, truncation, pagination, six-year default retention, and non-deletable session records all affect control design.

The practical architecture is layered. The Compliance API supports retrospective audit and export. SIEM tools support correlation and investigation. Immutable storage, hashes, manifests, and holds protect evidentiary value. DLP, endpoint policy, browser governance, and prompt-side hooks provide prevention. Quality and records processes determine whether a transcript is a regulated record, supporting metadata, or ordinary telemetry.

For GxP use, the decisive question is not whether a transcript exists. It is whether the organization can define intended use, prove coverage and omissions, preserve the authoritative record and its context, apply the correct retention clock, validate the end-to-end workflow in proportion to risk, and keep regulated approvals in an appropriate system. Until those controls pass documented acceptance tests, Claude in Chrome should remain limited to named workflows and approved data classes. That is the difference between retained conversation content and reliable evidence.