diff --git a/docs/gtm/icp-and-personas.md b/docs/gtm/icp-and-personas.md
deleted file mode 100644
index 7858f31..0000000
--- a/docs/gtm/icp-and-personas.md
+++ /dev/null
@@ -1,35 +0,0 @@
-# ICP and Personas
-
-This document defines the first go-to-market audience for TTP. It is intentionally narrow: TTP should lead with teams that already feel pain from autonomous execution, non-human identity sprawl, and privileged automation.
-
-## Priority Segments
-
-| Priority | Segment | Trigger | Why TTP fits |
-| --- | --- | --- | --- |
-| 1 | AI platform and agent infrastructure teams | Agents are moving from experiments to workflows that write, deploy, approve, or change customer-impacting systems. | TTP adds current trust, proof, and receipts before action execution without replacing identity or policy infrastructure. |
-| 2 | Security engineering and identity governance teams | Static service account permissions, CI tokens, or agent credentials are too broad for runtime risk. | TTP gives a portable way to evaluate freshness, delegation, route validity, and threshold proof at the boundary. |
-| 3 | DevOps and platform teams governing CI/CD | Production deploy, environment mutation, or privileged workflow steps require stronger pre-execution checks. | TTP can gate protected actions with `PERMIT`, `DENY`, `STEP_UP`, `THROTTLE`, or `CONSTRAIN` and emit receipts for review. |
-
-## Primary Personas
-
-| Persona | Jobs to be done | Adoption ask | Success signal |
-| --- | --- | --- | --- |
-| Platform security lead | Reduce risk from autonomous or semi-autonomous execution. | Pilot one governed workflow with receipt capture. | A protected action is denied or stepped up based on trust state rather than static identity alone. |
-| Agent platform engineer | Add trust-aware execution to agent runtime or tool calls. | Integrate SDK token request and pass tokens to a protected service. | Agent actions carry scoped, short-lived trust context. |
-| API/service owner | Protect a sensitive write path without replacing IAM. | Add verifier middleware or manual token verification. | Service rejects stale, insufficient, or domain-mismatched trust. |
-| Compliance/security reviewer | Understand why an action was allowed or blocked. | Review execution receipts and policy rationale. | A receipt explains actor, action, threshold, trust route, and decision. |
-
-## Buying Triggers
-
-- AI agents are being granted write access to production systems.
-- CI/CD workflows rely on long-lived credentials or broad service accounts.
-- A security review asks how agent actions are authorized after identity is established.
-- A customer requires evidence for why an automated action was permitted.
-- Existing policy engines lack fresh behavioral trust, decay, or route proof semantics.
-
-## Non-ICP For Now
-
-- Teams looking for a hosted governance dashboard as the first deliverable.
-- Teams that only need static identity authentication.
-- Teams that require production-grade cryptographic enforcement before a pilot.
-- Teams that cannot identify one concrete protected action to gate.
diff --git a/docs/gtm/launch-kpis.md b/docs/gtm/launch-kpis.md
deleted file mode 100644
index ff6459c..0000000
--- a/docs/gtm/launch-kpis.md
+++ /dev/null
@@ -1,27 +0,0 @@
-# Launch KPIs
-
-These metrics define launch health for the open protocol repo and early adoption motion.
-
-| KPI | Definition | Why it matters |
-| --- | --- | --- |
-| Quickstart activation rate | Percentage of new evaluators who run `npm run demo` or the equivalent first trust gate. | Measures whether the first value moment is reachable. |
-| Time to first gated workflow | Time from repo checkout to a non-demo protected action using TTP. | Measures adoption friction. |
-| Protected action coverage | Number of real action boundaries gated by TTP in pilots. | Measures movement from evaluation to operational value. |
-| Receipt completeness rate | Percentage of decisions producing reviewable receipts with actor, action, resource, score, threshold, reason, and chain hash. | Measures auditability. |
-| SDK integration starts | Number of agent, API, or CI integrations using a TTP SDK or verifier path. | Measures developer adoption. |
-| External contribution rate | Issues, PRs, examples, or integration notes from outside maintainers. | Measures ecosystem pull. |
-| Step-up usefulness | Number of workflows where `STEP_UP` or `CONSTRAIN` replaces unconditional permit or hard deny. | Measures practical governance nuance. |
-
-## Launch Targets
-
-Initial public launch targets should be conservative:
-
-- 5 technical evaluators complete the local demo.
-- 2 pilots gate a real protected action.
-- 1 partner or internal integration publishes a receipt sample.
-- 1 anonymized case study or implementation note is ready for public review.
-- CI, packaging, and security status are green for the tagged pre-release.
-
-## Reporting Cadence
-
-Review these metrics weekly during launch and after every tagged pre-release. Keep the public repo focused on protocol adoption and interoperability; track commercial funnel metrics separately.
diff --git a/docs/gtm/pilot-proof-template.md b/docs/gtm/pilot-proof-template.md
deleted file mode 100644
index ec13659..0000000
--- a/docs/gtm/pilot-proof-template.md
+++ /dev/null
@@ -1,62 +0,0 @@
-# Pilot Proof Template
-
-Use this template to turn a pilot into a reusable proof point without exposing sensitive implementation details.
-
-## Summary
-
-- Organization type:
-- Protected action:
-- Runtime boundary:
-- TTP components used:
-- Pilot duration:
-
-## Before TTP
-
-- How was identity established?
-- How was action authority decided?
-- What evidence existed after execution?
-- What failure or audit gap motivated the pilot?
-
-## TTP Integration
-
-- Subject:
-- Action:
-- Resource:
-- Domain:
-- Minimum score:
-- Issuers:
-- Verification location:
-- Receipt destination:
-
-## Results
-
-| Result | Evidence |
-| --- | --- |
-| First gated workflow completed | |
-| `PERMIT` path validated | |
-| `DENY` path validated | |
-| `STEP_UP` or `CONSTRAIN` path validated | |
-| Receipt captured and reviewed | |
-| Stale or insufficient trust behavior tested | |
-
-## Metrics
-
-- Time to first gated workflow:
-- Decision count:
-- Decision mix:
-- Receipt completeness rate:
-- Stale trust rejection count:
-- Issues found:
-- Follow-up integrations:
-
-## Reusable Quote
-
-Write a one-sentence outcome that does not require naming the customer:
-
-> A platform team used TTP to gate [protected action] with current trust and receipt proof before execution.
-
-## Redaction Checklist
-
-- Remove tenant names, hostnames, customer data, secrets, and internal incident details.
-- Replace actor identifiers with role-based examples.
-- Preserve architecture shape, decision outcomes, and measured adoption friction.
diff --git a/docs/gtm/value-hypotheses.md b/docs/gtm/value-hypotheses.md
deleted file mode 100644
index 36a27e3..0000000
--- a/docs/gtm/value-hypotheses.md
+++ /dev/null
@@ -1,39 +0,0 @@
-# Value Hypotheses
-
-TTP should be measured by whether it improves execution governance at concrete boundaries. These hypotheses are written for pilot planning and should be converted into customer-specific success criteria.
-
-## Hypotheses
-
-| Hypothesis | Measurement | Expected pilot evidence |
-| --- | --- | --- |
-| Runtime trust gates reduce over-permissioned execution. | Count protected actions moved from static allow/deny to trust-aware decisions. | At least one sensitive action uses current trust, scope, and freshness checks. |
-| Receipts reduce investigation time. | Compare time to reconstruct why a protected action executed before and after receipt capture. | Receipts show actor, action, resource, threshold, route, decision, and chain hash. |
-| Step-up decisions reduce binary blocking. | Count actions that move from hard deny or unconditional permit to `STEP_UP` or `CONSTRAIN`. | Production-like workflows can require human review or added proof when trust is marginal. |
-| Trust decay catches stale authority. | Count decisions affected by freshness, expiration, or decay. | A token or claim that was once valid fails after trust state ages out. |
-| Protocol-level semantics improve portability. | Count integrations using the same trust concepts across agent, API, and CI boundaries. | The same subject/action/resource/threshold model applies to more than one system. |
-
-## Pilot Outcome Statements
-
-Use these statements when scoping a pilot:
-
-- "We can prove why this agent action was permitted, denied, or stepped up."
-- "We can reject stale or insufficient trust even when identity authentication succeeds."
-- "We can add a trust gate to one protected boundary without replacing IAM, CI, API gateway, or policy tooling."
-- "We can capture execution receipts that support audit and incident review."
-
-## Metrics To Capture
-
-| Metric | Definition |
-| --- | --- |
-| Protected action coverage | Number of sensitive actions evaluated through TTP. |
-| Decision mix | Percentage of `PERMIT`, `DENY`, `STEP_UP`, `THROTTLE`, and `CONSTRAIN` results. |
-| Stale trust rejection rate | Decisions denied or stepped up due to expiration, decay, or freshness failure. |
-| Receipt completeness | Percentage of decisions with actor, action, resource, score, threshold, reason, and chain hash. |
-| Time to first gated workflow | Time from repo checkout to first non-demo protected action. |
-
-## Proof Required Before Broad Launch
-
-- One public pilot narrative or anonymized implementation story.
-- One repeatable performance baseline for parser, verifier, resolver, and receipt paths.
-- One documented integration with a CI system, API gateway, or agent runtime.
-- One security review pass focused on unsafe defaults and production disclaimers.