# Data flows and responsibilities

Version 2.0 — reviewed September 7, 2026

Ordinary intake is metadata-only. Do not put prompts, model responses, credentials, CUI, PHI, payment-card details or customer production content into ordinary governance fields, telemetry, support messages or exports. Metadata can still identify people and must be handled with care. Deliberately uploaded permitted evidence follows separate file checks and access controls; “metadata-only” is not a claim that all stored files contain only hashes.

## Where information goes

| Flow | Information and destination | Boundary |
| --- | --- | --- |
| Person → Briard-AI | Account, organization, AI-tool facts, approvals, policy recipients and permitted evidence; hosted API, tenant database and private evidence storage | Current organization and role checks; privileged access uses MFA. Browser-visible project configuration is not a secret or authorization. |
| Approved source → KAIDAN | Event IDs, times, tool/agent identifiers, source health, findings and bounded operational metadata; tenant/application-scoped intake and evidence journal | SDK/relay validation applies. Source failure, unsupported input and missing evidence remain coverage gaps. Discovery is not monitoring. |
| Briard-AI → KAIDAN | Short-lived signed, scoped access plus original governance policy/version/hash references | The receiving service checks identity and scope. A linked policy is context, not proof of permission or compliance. |
| Case → response control | Exact configured target, action, approver, executor and request identity; authorized worker and supported provider | Current authority and provider preconditions are checked. Proposal, approval, queue, send, reply and checked effect are distinct records. No blanket provider access or automatic restoration is implied. |
| Closed case → policy review | Selected closure, evidence references, original governance version and, when selected, exact response head | A retained review does not replace old policy history. A person decides whether to change a draft; publication remains separate. Availability must be checked against the dated release status. |
| Evidence → verifier | Selected package bytes, manifest, hashes and available custody/timestamp receipts | A matching digest checks bytes, not the truth of a statement. Signer trust needs a separately trusted key; timestamp verification is separate. Missing proof is not success. |
| Ledger → timestamp service | SHA-256 commitment, nonce and request metadata | Document bodies and full ledger contents are not sent for timestamping. |
| Account → billing/email | Billing identifiers to Stripe; requested message and recipient/delivery metadata to configured email service | Card details go directly to Stripe. Email contains only information permitted for that delivery. |

## Separate, optional content paths

KAIDAN Enhanced analysis can run transiently on content in an authorized customer-local process and hand off verified, signed metadata through normal intake. Its source and controlled command-to-relay tests do not establish a customer deployment. Timeouts, unsupported input, failed verification or failed delivery are not “safe” results. The customer controls the machine, content access, signing key, process environment and permitted input. It is not the ordinary hosted telemetry path.

Restricted forensic capture is disabled by default. It requires separate case-specific approval, purpose, duration, content permissions, access and storage/retention controls. Do not use the existence of that feature as permission to send content through ordinary Briard-AI or KAIDAN fields. Normal metadata exports do not silently become raw-content exports.

## Who does what

| Area | Company-hosted service | Customer-controlled deployment or destination |
| --- | --- | --- |
| Hosting, updates, service backup and monitoring | Unfettered Minds LLC operates the platform with the providers in the register; see dated recovery evidence and limits | Customer supplies approved infrastructure, capacity, updates, backups, alerts, recovery keys and tested restore/rollback arrangements within the agreed deployment scope |
| People and access | Platform enforces supported identity, role and scope checks | Customer confirms people, roles, lawful monitoring, notices and authority; removes access when no longer needed |
| Source and response permissions | Platform uses explicitly configured integrations and targets | Customer authorizes least-privilege source/provider access and pays its selected provider fees; a permission label alone proves no remote right |
| Data location and retention | Documented defaults and configured provider locations; no contractual residency promise | Customer chooses and documents permitted regions, retention, legal holds, encryption and export access for its resources; locked retention cannot simply be shortened |
| Incidents and recovery | Platform records supported observations and checked outcomes; product support follows published business-hour targets | Customer makes its incident/reporting decisions and controls recovery: use a new credential, reviewed minimum grant or clean source where needed; never blindly restore compromised material |

Do not infer a self-hosting license from this responsibility table. Non-standard commercial deployment rights need an applicable agreement. [Subprocessors](./subprocessors.md) lists providers and components separately. [Lifecycle](./data-lifecycle.md) distinguishes active records, immutable evidence, backups and external copies.