# ToolHost — Data-Handling Statement (E-COM-2)

*Anchor: project-docs/03-engineering-design/07-observability-evidence.md §7 (DN-ARCH-1);
06-flows/09-sec-full-flow.md §5 Beat 1/2 (retention honesty).*

> **Legal sign-off on the posture below is deferred to pre-launch (DN-ARCH-1, CEO decision
> 2026-07-06).** The schema and mechanism described here are built and dual-posture-capable
> today; the default *operating* posture until legal signs off is stated plainly in the "what
> happens on deletion today" section. This is not a future promise rendered as a present fact.

## What is stored

Decision metadata for every governed call: pipeline stage outcomes, taxonomy-coded reasons,
timings, tool and backend names. This tier is stored in plaintext because mandatory-retention
obligations (accountability, audit) apply to it independent of any single tenant's deletion
request.

## What is stored, encrypted per-org

Tenant-identifying payload — principal external subjects, captured request/response bodies (only
if capture is enabled for that view), client metadata beyond protocol era — is encrypted under a
per-org data-encryption key (DEK). This classification (which column is which tier) is fixed at
the schema level, not a runtime toggle.

## What is never stored

Nothing beyond what's captured on a call the evidence pipeline processes. If capture is off for a
view, tool call results are not stored, full stop — the demo you'd see live in the console
confirms this directly rather than asking you to trust it.

## Retention knobs

`evidence` is partitioned by time; each org's configured `retention_policy` drives scheduled
partition-drop for expired data. Capture rows carry an independently shorter TTL. The evidence
list's own footer states the retention horizon in effect — never an implied infinite archive.

## Per-tenant deletion procedure — designed, dual-posture, legal-gated

Deleting an org's DEK is designed to render that org's encrypted (PII-tier) rows permanently
unrecoverable while decision metadata survives for retention obligations. Deletion is itself
evidenced before the target rows go, in a platform-attributed record stored outside the deleted
org's own partitions.

**What happens on deletion today:** until legal sign-off clears (DN-ARCH-1, pre-launch), the
default posture is **retain-everything within the org's `retention_policy`** — the crypto-shred
mechanism is implemented and tested, but the DEK-deletion step of the offboarding runbook is
marked LEGAL-GATED and is not executed as a matter of course. If your evaluation requires a
deletion attestation ahead of that sign-off, say so explicitly — this is the honest current state,
not the final one.