- Arc XP Learning Center
- Products
- Ask the News
- Ask the News FAQ
Ask the News FAQ
Data Retention & Query Logging
Do you retain user query content (i.e. the search or input queries submitted by users)?
Yes. Each answered query is persisted so privileged users can review their history and so follow-up questions in the same conversation can be served coherently. Answer History is a core feature of Ask The News. For the end user, the chat history is removed when the browser session is over. They can not view their history.
What specific query data is stored?
Each stored record contains:·
The user's question and the generated answer
Identifiers used for threading (so follow-ups can be linked to the original question)
A pseudonymous user identifier provided by client (see "Anonymization" below)
Metadata about the sources cited in the answer (article identifiers, headline, URL)
Optional end-user feedback (thumbs up/down and optional free-text)
Organization, site, and creation timestamp
A trace identifier used for operational troubleshooting
What is the purpose for retaining this data?
Purpose | Why we retain it |
|---|---|
Conversation continuity | Follow-up turns need the prior question, answer, and rolling summary |
Answer history | UI Privileged users can view prior questions and feedback |
Operational/quality view | Admins can review answered vs. blocked vs. unanswered queries |
Feedback loop | Captured thumbs/comments inform answer-quality improvements |
Tracing & troubleshooting | The trace ID links a stored record to its observability trail when investigating issues |
What is the defined retention period for query data?
90 days, enforced automatically by the underlying database's native time-to-live mechanism. Each record is written with an expiry timestamp 90 days after creation, and the database deletes expired records automatically (typically within ~48 hours of expiry).
How do you ensure that only data which is adequate, relevant, and limited to what is necessary is retained (in line with data minimization principles)?
Only minimal source metadata is stored on the history record (article identifiers, URL, headline, and short description). Full article bodies are not copied into the history record.
Strict schemas at the API boundary reject unknown fields, preventing accidental capture of additional client-supplied data.·
No collection of email, name, IP, device, or session identifiers.
We do not currently redact PII from the question string itself before storage. Customers who need PII suppression can configure query-blocking rules (including pii-category patterns such as SSNs, emails, and phone numbers) that prevent matching queries from being answered. Customers can also include user-facing disclosures notifying users that PII should not be input into Ask the News.
How can retention be configured, reduced, or disabled by the customer?
The 90-day retention period is a platform default and applies uniformly across organizations.
Anonymization & Use of System Data
Where system-level data is derived from user queries, what anonymization or pseudonymization methodologies are applied?
The user identifier stored alongside each query is a pseudonymous identifier: an opaque value supplied by the customer, with no embedded personal data (no name, no email, no IP). There is base level detection for rejecting PII in user_id, but it is ultimately the client’s responsibility.
Customers control what value is sent as the user identifier. Our explicit guidance to customers is to send a pseudonymous, non-reversible identifier (for example, a hashed account ID).
We advise against sending email addresses, full names, or any directly identifying value, and use a best-effort approach to block any detected PII values when sent in the user_id field of a request to /query.
Other identifiers stored on the record (query ID, thread ID) are randomly generated UUIDs with no embedded user information. Application logs reference only opaque identifiers and never contain query text.
How do you ensure that aggregated or anonymized datasets cannot be re-identified or still constitute personal data?
The history dataset is not a "released" or shared dataset. It is operational data accessible only via authenticated APIs subject to role-based access control. Re-identification risk is mitigated through containment rather than statistical transformation:
Strict tenant isolation. Every read and write is scoped by organization and site identifiers. Data cannot be queried across tenants.
Per-thread ownership checks. A request made to /query can only append follow-ups to their own conversation thread, which requires knowing the root_query_id AND the user_id sent with the original request. A request to /query without a matching pair of root_query_id and user_id will be rejected.
Role-based access for admin views. Answer History access is gated behind a permission in the ArcPermissions service, configurable by the org admin.
Bounded retention. The 90-day TTL caps the dataset's age.
No external data sharing. The history dataset is not exported, sold, or used to train third-party models.
We treat stored records as potentially-personal data, because the question text is free-form and may contain identifying input from the user.
What safeguards are in place to prevent linkage of anonymized data back to individuals?
The safeguards are layered:
Layer | Safeguard |
|---|---|
Identifier | Customer-controlled pseudonymous ID; we recommend hashed/opaque values |
Storage | Per-tenant partitioning; no cross-tenant query path. |
API surface | Authenticated, role-gated; thread-level ownership enforcement |
Field discipline | Strict schemas reject unknown fields; only minimal source metadata stored |
Lifecycle | 90-day TTL |
Logging | No query content in application logs; opaque trace IDs only |
Data flow | No export, no third-party model training, no cross-customer aggregation |
Because the question text itself is free-form input from the end-user, it is possible for a user to type self-identifying information into a question. Customers can mitigate this with PII-category query-blocking rules, which reject queries matching configured patterns.
This risk is also mitigated through ArcXP’s usage of Datadog’s Sensitive Data Scanning on user requests to mask PII in questions that make it past these Org-wide rules.
How do you assess and validate that your anonymization approach meets applicable data protection standards (e.g. UK GDPR)?
Ask The News operates as a component of the Arc XP platform and inherits Arc XP's contractual data-protection framework, including the Arc XP Data Processing Addendum, sub-processor disclosures, and tenant-isolation guarantees. The service-level controls relevant to UK GDPR are:
Purpose limitation. Data is used only for the operational purposes listed above.
Storage limitation. Fixed 90-day retention, automatically enforced.
Data minimization. Minimal fields stored; PII fields (email, name, IP) are not collected by the service.
Integrity & access control. Tenant isolation, authenticated APIs, role-based access.
Pseudonymization. Customer-controlled pseudonymous user identifiers
For specific contractual commitments (DPA scope, sub-processor list, regional data residency, breach notification SLAs), the Arc XP master agreement governs and we can provide the relevant addenda on request.