Data Handling, Subprocessors & AI Training Disclosures

§1 Overview

Ri Koh ("the Service") is an AI-assisted enterprise knowledge platform built and operated by UltiSim Inc. ("UltiSim", "we"). This page is the canonical source of truth for how customer data is handled by the Service, which third-party subprocessors receive that data, what those subprocessors do with it, how long it is retained, and what compliance attestations each one carries.

This document is updated whenever a subprocessor is added, removed, or changes its policies materially. The effective date is shown at the top.

§2 Sovereignty & Residency Stance

📄 For a print-friendly handout covering the three-way routing and 🔒 sovereign toggle, see the AI Sovereignty 1-pager.

Ri Koh provides a three-tier sovereignty model. Customers pick the tier that matches their risk profile, per query or per tenant.

• Default tier — Anthropic API. Standard commercial use; processed in Anthropic-managed AWS in the United States.
• Sovereignty tier — AWS Bedrock. Customer-pinned AWS region (commercial or GovCloud for FedRAMP-aligned workloads). Same Claude model weights as the default path; the contractual perimeter is the customer's existing AWS account and BAA / DPA.
• Air-gap tier — local model. Runs entirely inside the customer's network on customer-owned hardware; no inference traffic leaves the perimeter.

The full matrix — region pinning, training opt-outs, attestations, recommended use — lives in §9.6. All three tiers receive identical post-retrieval context: switching tier changes which legal entity and infrastructure runs the inference, not what the model is allowed to see. Ri Koh additionally enforces an automatic, non-overridable rule: any retrieved chunk classified as sensitivity_level='restricted' forces the query to the air-gap tier regardless of user choice.

Standard subscription gives every customer access to all three providers. The Sovereignty (Bedrock) and Air-gap (Local) tiers require customer-side configuration (AWS account or on-premise hardware). Enterprise agreement adds UltiSim-managed setup, BAA / DPA / FedRAMP-aligned attestations, and dedicated support — typically required by federal, defense, and healthcare buyers.

§3 Data Flow

Every customer-data path through the Service. Note the classification gate at ingest — every document gets a sensitivity_level + contains_pii flag the moment it enters the index, and that classification follows it into every downstream context retrieval.

§4 Data Categories & Classification

Every document that enters the index is classified along two independent axes — access scope (who is allowed to read it) and sensitivity level (how the data should be handled). Both axes are recorded on the document row at ingest and can be edited by an admin at any time.

Data categories we process

• Identity — email address, display name, profile picture, hashed password (PBKDF2 / 100k iterations), session JWTs.
• Tenant content — uploaded documents (PDF / DOCX / TXT), Google Drive imports, knowledge entries, capability matrix, contacts, proposals, marketing items.
• Conversational — chat queries and assistant responses, conversation history (per session), feedback ratings.
• Telemetry — query intent classification, response time, source citations, audit-log entries for admin actions (db-query, user-create, password-reset, connector-update).
• Personalization — user_memory entries (durable facts derived from conversations), preferences.
• Integration tokens — Google OAuth refresh tokens (encrypted), API keys for connected services.

Access-scope axis (who can read)

• core — visible to every authenticated member of the tenant.
• restricted — visible only to admins or to specific role-grants in the document_roles table.
• personal — visible only to the uploader (and admins).

Sensitivity-level axis (how to handle it)

• public — content already in the public domain (e.g., a posted RFP, a press release). No handling restriction beyond standard care.
• internal — default for new uploads. Routine business information; not for external publication without review.
• confidential — competitively sensitive (pricing, win strategy, customer-specific data). Triggers tighter retention and a stronger audit trail.
• restricted — regulated or privileged (CUI, attorney-client privileged, HIPAA-touching). Should not be sent to a generic AI provider without an enterprise agreement covering it.

PII flag

A separate contains_pii boolean is set per document. The default is false on upload; admins can mark true when a document is known to contain personal information (resumes, contractor lists, customer org charts). Documents flagged contains_pii=true are subject to data-subject deletion requests on a per-document basis.

Classification provenance

Every document also records classification_source (one of auto, manual, inherited) plus classified_by and classified_at so an auditor can reconstruct who set each label and when. Manual reclassification by an admin is logged to admin_audit_log via the admin.connector_update / admin.classification_update action records.

How to classify a document

• At upload — the system applies sensitivity_level='internal', contains_pii=0, classification_source='auto' by default. The uploader's tenant role is recorded as owner_team.
• After upload (admin or owner) — open the document in /documents, click the row to expand the detail panel, and use the 🔒 Classification (SOC2) editor to change sensitivity, toggle the PII flag, or set the owner team. Saving flips classification_source to manual and stamps your identity + timestamp.
• Programmatically — PATCH /api/documents/:id/classification with { sensitivity_level, contains_pii, owner_team } in the body. Same audit treatment as the UI path.
• Tenant-wide stats — GET /api/documents/classification-stats returns by_sensitivity counts, PII total, and by classification_source breakdown.

What is and isn't auto-indexed into the searchable knowledge base

Specifically, content becomes searchable (i.e., goes into chunks + Vectorize and is returned by RAG retrieval) only via these explicit user actions:

• File upload — the user uploads a PDF / Word / TXT / etc. via /documents or via the chat composer's 📎 button.
• Google Drive folder sync — an admin connected a specific Drive folder via the Drive connector. Files in that folder are indexed on a schedule.
• Slack channel sync — an admin enabled syncing for a specific Slack channel. Messages are indexed.
• Promote to Source of Truth (planned) — an opt-in button on any artifact or chat response that converts that one item into an indexed document. Disabled by default; explicit user action required.

Content that never auto-indexes:

• Chat queries you type into Ri Koh or Marvin
• AI responses generated by either persona
• Artifacts generated via the artifact pipeline (white papers, briefings, slide decks, study guides, etc.) — they live in their own artifacts table and do not leak into RAG search
• Marvin "Action Plan" deliverables
• Generated images (saved or unsaved)
• Conversation history

Each indexed item carries source provenance (upload, gdrive, slack, eventually artifact-promoted or chat-promoted) so an auditor can trace exactly how every searchable record entered the corpus.

§5 Encryption

§6 Retention

• Tenant content (D1, R2, Vectorize) — retained for the duration of the customer's active subscription. On termination, deleted within 30 days unless the customer requests export first.
• Chat queries and responses (D1 query_log) — retained for the customer's active subscription; powers Query Insights.
• User_memory entries — retained for the active session of the user; deletable on request.
• Audit log (admin_audit_log) — retained 13 months for SOC 2 evidence purposes.
• Anthropic API inputs / outputs — retained up to 30 days by Anthropic for trust & safety abuse detection, then deleted (Anthropic Commercial Terms). Zero Data Retention available on enterprise agreement.
• Anthropic prompt cache — 5 minutes default, 1 hour maximum. Auto-purged. Used to reduce inference cost on repeated non-customer prompt prefixes (persona instructions, brand voice, style guidance). Customer data — retrieved RAG chunks, conversation history, user queries — is never placed inside the cache boundary. Same Anthropic Commercial Terms apply: cached content is not used to train models. Bedrock cache layer follows the same posture in the customer-pinned region.
• Cloudflare logs — request metadata retained per Cloudflare's standard policy (typically 7 days for non-enterprise plans).
• Google OAuth tokens — refresh tokens stored until the user disconnects Google or is deactivated.

§7 Access Controls

• Authentication — JWT cookie or Bearer token, validated on every API request via unifiedAuthMiddleware. Revocation via KV denylist (jti) on logout and password change.
• Authorization — per-tenant DB/R2/Vectorize bindings; non-admin users post-filtered against document scopes (core / restricted / personal) and document_roles.
• Multi-tenant isolation — each tenant has its own D1 database, R2 bucket, and Vectorize index; routing is enforced by tenantMiddleware before any handler runs.
• Rate limiting — 5/min on login endpoints, 3/hour on registration and password reset (Cloudflare ratelimit bindings).
• Registration gate — limited to @ultisim.com email domain or one-time invite code; open self-registration is disabled.
• Admin audit log — admin user-create, user-update, password-reset, db-query actions are logged with user identity, IP, and full payload to admin_audit_log.

§8 AI Training Opt-Outs

§9 Subprocessor List

We engage the following subprocessors to provide the Service. Each processes customer data only as needed to deliver its function and is bound by a written agreement that includes confidentiality, security, and use-restriction obligations.

§9.5 Internal Data Connectors

In addition to subprocessors (which receive data from us), Ri Koh pulls data from several customer-controlled sources to feed the index. Each pull-based source is registered in the data_connectors table with an explicit name, type, scope, credential reference, and classification default. This gives an auditor a single query to answer "every external source that feeds your index, the credential that pulls from it, and the classification its items inherit."

Connector types currently supported:

• gdrive — Google Drive folder sync. Credential: per-user OAuth refresh token (gdrive_oauth_token_user_<id>). Scope: a specific folder path. Read-only access at the OAuth-scope level.
• slack — Slack channel sync. Credential: workspace bot token (slack_bot_token). Scope: a single channel name. Read-only at the bot-scope level (channels:history, channels:read).
• sbir-grants-gov / sam-gov / dod-sbir / nasa-sbir-portal — public-data scanners feeding the proposal pipeline. No credential required (public APIs); scope is the search-keyword set.

Items pulled by a connector inherit the connector's classification_default (typically internal for Drive/Slack, public for the proposal scanners). Admins can override per-document via the classification edit endpoint.

Connector creation, updates, and deactivation are logged to admin_audit_log as admin.connector_update entries.

§9.6 AI Provider Sovereignty Matrix

Ri Koh routes Claude inference through one of three providers selectable per-query from the chat composer. The default is Anthropic's commercial API; customers with regional residency, FedRAMP, or air-gap requirements can override to AWS Bedrock or to a local model. All three paths run the same Anthropic Claude model weights; what differs is the contractual and infrastructural envelope that surrounds them.

How a provider is selected

The provider for a given query is chosen by precedence (highest wins):

1. Sensitivity override (non-overridable security control) — if any retrieved RAG chunk carries sensitivity_level='restricted', the query is automatically routed to the local provider. The user cannot bypass this; the response is tagged with a SOVEREIGNTY FORCED badge for audit visibility.
2. Per-query manual override — the chat composer exposes a provider dropdown and a 🔒 toggle. The dropdown selects Anthropic / Bedrock / Local for that single query; the 🔒 toggle pins all subsequent queries to local until cleared.
3. Tenant default — each tenant has a default provider field; absent that,
4. Worker default — the DEFAULT_AI_PROVIDER environment variable (currently anthropic).

What gets sent to each provider

Identical request shape across all three: the assembled system prompt, the retrieved RAG context, the user query, and the recent conversation history (max 10 turns). No identity tokens, no JWTs, no cross-tenant data — the post-retrieval context is already filtered to the requesting user's access scope before the provider is invoked. The provider that answered each query, the model ID, and the sovereignty-forced flag are surfaced on every response and recorded in query_log for auditability.

§10 DPAs & Customer Agreements

UltiSim will execute a Data Processing Agreement (DPA) with any customer that requests one. Our standard DPA covers:

• Roles & responsibilities of UltiSim as Processor and customer as Controller (GDPR Article 28 framework).
• Subprocessor list (this document) and 30-day notification of changes.
• Security measures: TLS, AES-256, access controls, multi-tenant isolation, incident response.
• Standard Contractual Clauses (EU-to-US transfers) where applicable.
• Data subject request handling (access, rectification, deletion, portability, restriction, objection).
• Breach notification within 72 hours of UltiSim becoming aware.
• Audit rights (subject to confidentiality).

Email linda.bernard@ultisim.com with "Request DPA" in the subject line to receive a copy. Custom redlines accepted.

§11 User Rights

• Access & export — users can export their tenant's data (documents, knowledge entries, proposals, contacts) on request. Format: structured JSON + original file binaries.
• Rectification — users can edit any of their content directly via the app; admins can correct any tenant-wide content.
• Deletion — account and tenant deletion handled within 30 days of written request; cascade deletes propagate to D1, R2, Vectorize, and revoke JWTs via the denylist. Anthropic-side retention follows §6.
• Portability — exports are in open formats (JSON, original PDF/DOCX) with no proprietary lock-in.
• Objection / restriction — request to linda.bernard@ultisim.com.

§12 Incident Response

• UltiSim monitors Cloudflare and Anthropic security advisories continuously.
• Suspected security incidents are triaged within 4 hours of detection.
• If a confirmed incident affects customer data, UltiSim will notify the affected customer's designated security contact within 72 hours of becoming aware, including: nature of the incident, data categories impacted, mitigation taken, and recommended customer actions.
• Post-incident: written root-cause analysis shared with the affected customer.

§13 Contact