Improve GTM readiness packaging and CI

.github/workflows/ci.yml

@@ -17,9 +17,6 @@ jobs:
         with:
           node-version: '20'
 
-      - name: Run test suite
-        run: npm test
-
       - name: Documentation smoke check
         shell: bash
         run: |
@@ -33,10 +30,11 @@ jobs:
       - name: Compile Python SDK
         run: python -m py_compile sdk/python/client.py
 
-      - name: SDK + gate smoke matrix
-        shell: bash
-        run: |
-          set -euo pipefail
+      - name: Build TypeScript SDK
+        run: npm run build:sdk
+
+      - name: Build Trust Authority reference
+        run: npm run build:trust-authority
 
       - name: Show CLI version
         run: npm run ttp -- version

.gitignore

@@ -1,5 +1,7 @@
 node_modules/
 **/node_modules/
+dist/
+**/dist/
 .runtime-authority-receipts.json
 *.log
 .DS_Store

README.md

@@ -218,3 +218,16 @@ Expected JSON shape:
 | Receipt proof | Proof consumed by RAP / SCIM-RE | `specs/execution-receipt.md` |
 
 See `spec/`, `profiles/`, and `examples/` for normative docs, profile mappings, and test vectors.
+
+## Adoption Paths
+
+Choose the path that matches the first protected boundary you own:
+
+| Audience | Start here | Outcome |
+| --- | --- | --- |
+| Agent builders | [`docs/getting-started.md`](docs/getting-started.md) and [`sdk/typescript/`](sdk/typescript/) | Request and pass short-lived trust tokens from an agent runtime. |
+| Service/API owners | [`docs/integration-guide.md`](docs/integration-guide.md) and [`sdk/node/`](sdk/node/) | Verify trust before sensitive API or workflow actions execute. |
+| Platform/security operators | [`docs/operator-guide.md`](docs/operator-guide.md) and [`reference-implementations/trust-authority/`](reference-implementations/trust-authority/) | Run a pilot Trust Authority, issuer registry, and receipt review loop. |
+| Partners/integrators | [`docs/ecosystem-integrations.md`](docs/ecosystem-integrations.md) and [`docs/gtm/partner-integration-playbook.md`](docs/gtm/partner-integration-playbook.md) | Map TTP into existing gateways, CI systems, identity providers, and agent platforms. |
+
+For commercial positioning, see the [edition matrix](docs/gtm/edition-matrix.md), [ICP and personas](docs/gtm/icp-and-personas.md), and [value hypotheses](docs/gtm/value-hypotheses.md).

SECURITY.md

@@ -7,8 +7,10 @@ TTP is security-sensitive protocol work. The current repository contains a draft
 | Version / Branch | Security Support |
 | --- | --- |
 | `main` | Best-effort security review during active development |
-| Released packages | Not yet available |
-| Pre-MVP examples | Documentation and test fixture support only |
+| `@blocksifrdev/ttp-protocol@0.1.x` | Best-effort security review for pre-release protocol primitives |
+| `@blocksifrdev/ttp-sdk@0.1.x` | Best-effort security review for pre-release SDK interfaces |
+| `@blocksifrdev/ttp-trust-authority@0.1.x` | Best-effort security review for reference implementation pilots |
+| Examples and demos | Documentation and test fixture support only |
 
 ## Reporting Vulnerabilities
 

docs/gtm-assessment.md

@@ -54,19 +54,19 @@ The project is technically strong and credible for developer adoption now. The m
 ## Recommended 30/60/90 plan
 
 ### 0–30 days
-- Add `docs/gtm/icp-and-personas.md` with prioritized segments and buying triggers.
-- Add `docs/gtm/value-hypotheses.md` with measurable value statements.
-- Add `docs/gtm/edition-matrix.md` for OSS vs managed positioning.
-- Add a role-based CTA section in `README.md` for faster onboarding.
+- Keep `docs/gtm/icp-and-personas.md` current as pilot feedback identifies sharper buying triggers.
+- Use `docs/gtm/value-hypotheses.md` to turn each pilot into measurable success criteria.
+- Use `docs/gtm/edition-matrix.md` for OSS vs managed positioning in buyer conversations.
+- Keep the role-based CTA section in `README.md` aligned with current adoption paths.
 
 ### 31–60 days
 - Add `docs/gtm/reference-architectures-by-vertical.md` for key industries.
-- Publish a baseline performance/testing methodology in `docs/ops/`.
-- Add `docs/gtm/partner-integration-playbook.md`.
+- Publish baseline performance results using `docs/ops/performance-methodology.md`.
+- Use `docs/gtm/partner-integration-playbook.md` for first partner integration conversations.
 
 ### 61–90 days
-- Add `docs/gtm/launch-kpis.md` with target metrics and definitions.
-- Add a case study template and one initial implementation story.
+- Report launch health against `docs/gtm/launch-kpis.md`.
+- Fill out `docs/gtm/pilot-proof-template.md` for one initial implementation story.
 - Add a launch checklist tied to release milestones.
 
 ## Suggested GTM KPIs

docs/gtm/edition-matrix.md

@@ -0,0 +1,31 @@
+# Edition Matrix
+
+This matrix explains what belongs in the open protocol repository and what may become managed or enterprise packaging. It is positioning guidance, not a product price sheet.
+
+| Capability | Open protocol repo | Managed / enterprise option |
+| --- | --- | --- |
+| Protocol specification | Included | Included with support and implementation guidance |
+| Schemas and test vectors | Included | Included with compatibility review |
+| Local CLI and examples | Included | Included with onboarding support |
+| TypeScript/Python/Node SDK foundations | Included as pre-release interfaces | Hardened SDKs, release management, and support SLAs |
+| Reference Trust Authority | Included for pilots and interoperability | Managed Trust Authority operations and upgrade support |
+| Issuer and verifier patterns | Included | Connector certification and integration support |
+| Execution receipts | Included as schemas and reference behavior | Managed evidence storage, retention, and review workflows |
+| Policy and threshold examples | Included as examples | Policy simulation, assurance, and enterprise workflow mapping |
+| Security documentation | Included | Security review support and deployment guidance |
+| Compliance dashboards | Not included | Optional commercial add-on |
+| SLA-backed operations | Not included | Optional commercial add-on |
+| Premium proprietary connectors | Not included | Optional commercial add-on |
+
+## Procurement-Friendly Summary
+
+TTP is the open trust semantics layer for runtime authority. The open-source package helps teams evaluate, integrate, and interoperate around trust proof, decay, delegation, and receipts.
+
+Commercial offerings should be positioned as operational depth around the protocol: managed reliability, support, deployment assurance, evidence workflows, and enterprise-specific integrations. They should not be required to understand or independently implement the core protocol.
+
+## Packaging Rules
+
+- Keep protocol semantics, schemas, examples, and conformance artifacts portable.
+- Keep managed operations, dashboards, paid support, and premium workflow automation outside the open protocol package.
+- Do not require paid services to verify a core TTP claim.
+- Make production-readiness status explicit for each package and reference implementation.

docs/gtm/icp-and-personas.md

@@ -0,0 +1,35 @@
+# 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.

docs/gtm/launch-kpis.md

@@ -0,0 +1,27 @@
+# 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.

docs/gtm/partner-integration-playbook.md

@@ -0,0 +1,34 @@
+# Partner Integration Playbook
+
+This playbook helps partners decide where TTP belongs in their product or service.
+
+## Partner Types
+
+| Partner | Integration point | First proof |
+| --- | --- | --- |
+| Agent framework | Tool-call boundary or agent runtime token flow | Agent requests trust token and passes it to a verifier before a protected tool call. |
+| API gateway | Request middleware or policy plugin | Gateway checks trust token domain, score, freshness, and issuer count. |
+| CI/CD platform | Protected deployment step | Deployment receives `PERMIT`, `DENY`, or `STEP_UP` before execution. |
+| Identity governance vendor | Non-human identity context enrichment | TTP receipt links identity, action, trust state, and decision rationale. |
+| SIEM/SOAR platform | Receipt ingestion | Receipts become searchable evidence for automated actions. |
+
+## Integration Sequence
+
+1. Pick one protected action with measurable risk.
+2. Define subject, action, resource, domain, and threshold.
+3. Decide where trust is issued and where it is verified.
+4. Add verification at the action boundary.
+5. Capture receipt output in the partner system.
+6. Document failure behavior for stale trust, insufficient score, and unavailable trust authority.
+
+## Partner Deliverables
+
+- Architecture note showing the trust gate location.
+- Minimal runnable example.
+- Receipt sample.
+- Failure semantics table.
+- Version compatibility note for the TTP package or schema version used.
+
+## Co-Sell Message
+
+TTP helps partner products answer a security-critical question: "should this autonomous or non-human actor be allowed to attempt this action now?" The partner keeps its existing product role; TTP adds portable trust semantics and evidence at the execution boundary.

docs/gtm/pilot-proof-template.md

@@ -0,0 +1,62 @@
+# 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.

docs/gtm/value-hypotheses.md

@@ -0,0 +1,39 @@
+# 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.

docs/integration-guide.md

@@ -16,19 +16,19 @@ This guide walks through integrating TTP into your services and agent infrastruc
 
 ### Step 1 — Install the SDK
 
-The TypeScript SDK lives in this repository under `sdk/typescript`. The intended package name is `@ttp/sdk`, but it is not yet published to npm. Until publication, treat this section as the stable integration shape and use the local demo for a runnable first pass.
+The TypeScript SDK lives in this repository under `sdk/typescript`. The intended package name is `@blocksifrdev/ttp-sdk`. Until publication, treat this section as the stable integration shape and use the local demo for a runnable first pass.
 
 ```bash
 # Once published:
-npm install @ttp/sdk
+npm install @blocksifrdev/ttp-sdk
 ```
 
 The examples below use the intended stable import path.
 
 ### Step 2 — Initialize the Client
 
 ```typescript
-import { TTPClient } from "@ttp/sdk"
+import { TTPClient } from "@blocksifrdev/ttp-sdk"
 
 const ttp = new TTPClient({
   agentId: process.env.TTP_AGENT_ID,
@@ -98,7 +98,7 @@ Token lifecycle:
 
 ```typescript
 import express from "express"
-import { createTTPMiddleware } from "@ttp/sdk"
+import { createTTPMiddleware } from "@blocksifrdev/ttp-sdk"
 
 const app = express()
 
@@ -134,7 +134,7 @@ app.post("/api/issue-discount", async (req, res) => {
 If you prefer to verify without the middleware:
 
 ```typescript
-import { verifyTTPToken } from "@ttp/sdk"
+import { verifyTTPToken } from "@blocksifrdev/ttp-sdk"
 
 app.post("/api/action", async (req, res) => {
   const token = req.headers["x-ttp-token"]
@@ -205,7 +205,7 @@ An issuer observes agent behavior and submits signed behavioral receipts to the
 ### Minimal Issuer (TypeScript)
 
 ```typescript
-import { TTPIssuer } from "@ttp/sdk"
+import { TTPIssuer } from "@blocksifrdev/ttp-sdk"
 import express from "express"
 
 const issuer = new TTPIssuer({