Data Classification

rag-sample has one class of data today. This page exists to make that explicit, and to fix the rule that governs adding a second.

Classes

Class	Description	Examples in rag-sample	Handling
Public	Openly licensed third-party content with no expectation of confidentiality.	The neural-bridge/rag-dataset-12000 corpus (Apache-2.0): documents, embeddings, chunk metadata, and any derived index. The question text submitted to /query and the generated answer (both treated as public because the endpoint is public).	Stored in Aurora with default encryption. No access control beyond IAM on the cluster. Logged into CloudWatch (30-day retention, RAG008).

No other class exists today. Personal data, credentials, customer content, and internal documents are out of scope.

Operational data (not corpus)

The following are not corpus data but are produced by the system and warrant a note so they are not confused with “public”:

Data	Class	Handling
DB credentials	Secret	AWS Secrets Manager, KMS-encrypted, IAM-scoped to one Lambda role (RAG001 infrastructure). Never logged.
CloudWatch logs (request/response, X-Ray traces)	Operational	30-day retention (RAG008). Contains the user’s question and the generated answer. Treated as public because the inputs are public; this assumption breaks the moment auth or PII enters scope.
Bedrock prompts and completions	Operational	Subject to AWS Bedrock’s own data-handling terms; not used for model training under default Bedrock settings.
Terraform state	Operational	S3 backend with S3-native state locking per environment (RAG001). May contain ARNs and resource IDs; no plaintext secrets.

The classification rule

A change in data class is a re-architecture event, not a configuration change.

• The corpus class is fixed at “public” by the architecture, not by policy. The endpoint is gated only by an operator-issued bearer token with a per-key lifetime request quota (RAG009); self-service issuance of a public demo key is planned under Story #280, logs retain content for 30 days, no per-tenant isolation exists. Pointing ingestion at non-public data without changing those properties first is a data-handling incident.
• Adding any non-public class to the corpus requires, before ingestion runs:
  1. A new data-classification entry on this page identifying the class and its handling rules.
  2. A re-run of the threat model (T3 is the trigger).
  3. A re-scope of compliance.
  4. Authentication on /query (or removal of public access).
  5. A retention/deletion policy on the relevant CloudWatch log groups and Aurora data.
  6. A KMS review: customer-managed keys instead of AWS-managed, with explicit key policy.
  7. An ADR documenting the decision and the controls.
• No automated control prevents bypassing this rule today. It is a process gate, owned by the operator, enforced at code-review time on any change to the ingestion configuration or the corpus reference in pyproject.toml / Terraform.

This is the link to T3 in the threat model: the architecture cannot tell one corpus from another. The rule above is what stops a corpus swap from silently changing the product’s data-handling posture.

What is not classified here

• Question text and answer text in the public-/query model are treated as public by virtue of the endpoint. This is a property of the deployment, not the content. Anyone planning to remove public access should reclassify both before doing so.
• The list of operators and reviewers (CODEOWNERS, etc.) is metadata in the planning repo; outside the corpus classification.