From 1af2157e2746a3945be076b46583c40467608f2b Mon Sep 17 00:00:00 2001 From: blocksifrdev Date: Tue, 15 Sep 2026 13:08:25 -0400 Subject: [PATCH] Remove four internal assessments from the public repository gtm-assessment.md scored go-to-market readiness at 7.5/10. ASSESSMENT.md listed the project's weaknesses as an internal maturity review. MVP.md was a 30-day build plan, completed months ago. repo-completeness- assessment.md audited the repo against an internal checklist. All four are internal planning documents written for the team, all dated April 2026, and all sitting in a public repository. Two of them I moved into docs/ earlier today while tidying the root, without reading them closely enough to notice what they were. The honest-limits material worth keeping in public already exists, written deliberately for readers: packages/pctr/README.md documents what blast radius does not measure, that trust must be wired to a real attestation source, that keys are on disk rather than in a KMS, and that pctr serve is plain HTTP. That is a different thing from publishing an internal scorecard. Also drops the now-dangling MVP.md reference from protocol/spec.md. Co-Authored-By: Claude Opus 5 --- BRAIN.md | 16 ++++++ docs/ASSESSMENT.md | 49 ----------------- docs/MVP.md | 62 --------------------- docs/gtm-assessment.md | 82 ---------------------------- docs/repo-completeness-assessment.md | 27 --------- protocol/spec.md | 1 - 6 files changed, 16 insertions(+), 221 deletions(-) create mode 100644 BRAIN.md delete mode 100644 docs/ASSESSMENT.md delete mode 100644 docs/MVP.md delete mode 100644 docs/gtm-assessment.md delete mode 100644 docs/repo-completeness-assessment.md diff --git a/BRAIN.md b/BRAIN.md new file mode 100644 index 0000000..5b5eee1 --- /dev/null +++ b/BRAIN.md @@ -0,0 +1,16 @@ +# TTP PROTOCOL BRAIN + +TTP is the Trust Transfer Protocol. + +Purpose: +- trust expression +- trust portability +- delegation semantics +- trust continuity signaling + +TTP expresses trust. + +Runtime Authority enforces execution. + +TTP is NOT an enforcement engine. + diff --git a/docs/ASSESSMENT.md b/docs/ASSESSMENT.md deleted file mode 100644 index 1f4f977..0000000 --- a/docs/ASSESSMENT.md +++ /dev/null @@ -1,49 +0,0 @@ -# Repository Assessment - -## Current Maturity Level - -TTP is a promising protocol project in draft/MVP stage. After this update, the repo is more credible as an open-source protocol foundation, but it is not yet recommended for production security enforcement. - -## Strengths - -- Original protocol positioning around trust decay, proof-based authority, and trust transfer. -- Clear enterprise relevance for AI agents, non-human identities, CI/CD, service accounts, and API workflows. -- Good fit as a trust expression layer beneath runtime authority systems. -- Initial examples, CLI scaffold, tests, and docs now make the project easier to evaluate. -- Apache 2.0 licensing supports open-source adoption. - -## Gaps - -- Parser is intentionally minimal and not a complete grammar implementation. -- Proof model is `cleartext-dev`; signed and ZKP modes are future work. -- Delegation syntax exists, but delegation evaluation is not complete. -- Issuer registry and signed claim validation are not implemented. -- Runtime enforcement requires RAP, Execution Exchange, gateway, or CI integrations. -- Conformance tests need expansion before independent implementations can rely on the spec. - -## Risks - -- Overclaiming could damage enterprise credibility if production readiness is implied too early. -- Trust scores can be misunderstood as universal rather than scoped and time-bound. -- Weak issuer validation would undermine the protocol in production deployments. -- Runtime bypass remains the central integration risk. -- Clock and replay protections need careful design before production use. - -## Next Milestones - -1. Complete grammar parser and AST conformance fixtures. -2. Implement signed trust claims and issuer registry prototype. -3. Add delegation evaluator with scope, expiration, and max-score enforcement. -4. Define RAP and SCIM-RE mapping fixtures. -5. Publish security review checklist and failure-mode tests. - -## Scores - -| Area | Score | Notes | -| --- | ---: | --- | -| Protocol originality | 9/10 | Strong differentiated thesis around live, decaying trust. | -| Enterprise relevance | 8/10 | Clear fit for NHI, agent, workflow, and runtime authority problems. | -| Implementation maturity | 4/10 | MVP scaffold exists, but production semantics are incomplete. | -| Security documentation | 6/10 | Threat model and security policy now exist; hardening remains. | -| Open-source readiness | 7/10 | Better README, governance, examples, CI, and contribution path. | -| Overall enterprise readiness | 5/10 | Credible for review and prototyping, not enforcement production. | diff --git a/docs/MVP.md b/docs/MVP.md deleted file mode 100644 index fd94c67..0000000 --- a/docs/MVP.md +++ /dev/null @@ -1,62 +0,0 @@ -# TTP MVP - -The first usable TTP implementation should be small, testable, and buildable in 30 days. It should prove the core protocol loop without claiming production security. - -## MVP Includes - -- Parse `.ttp` files. -- Validate core syntax. -- Build an AST/object model. -- Evaluate static trust score. -- Evaluate trust decay over time. -- Evaluate threshold condition. -- Output JSON evaluation result. -- Support `cleartext-dev` proof mode. -- Include at least three examples. -- Include CLI commands. - -## MVP Excludes - -- Production ZKP. -- Distributed trust network. -- Blockchain anchoring. -- Full policy marketplace. -- Complete FrontDesk integration. -- Cross-enterprise trust routing. -- Production issuer registry. -- Production runtime enforcement. - -## CLI Commands - -```bash -npm run ttp -- check examples/01-basic-agent.ttp -npm run ttp -- eval examples/02-trust-decay.ttp --subject agent:invoice_reviewer --at now -npm run ttp -- version -``` - -## Acceptance Criteria - -- `ttp check examples/01-basic-agent.ttp` succeeds. -- `ttp eval examples/02-trust-decay.ttp --subject agent:invoice_reviewer --at now` returns JSON. -- Tests pass in CI. -- Invalid syntax returns useful errors. -- Expired trust returns failed evaluation. -- Decayed trust below threshold returns failed evaluation. -- Threshold met returns valid evaluation. - -## Initial Examples - -- `examples/01-basic-agent.ttp` -- `examples/02-trust-decay.ttp` -- `examples/03-threshold-proof.ttp` -- `examples/04-delegated-trust.ttp` -- `examples/05-frontdesk-authority-context.ttp` - -## Buildable 30-Day Plan - -| Week | Work | -| --- | --- | -| 1 | Parser, AST, syntax errors, examples. | -| 2 | Trust decay evaluator and threshold evaluator. | -| 3 | CLI, JSON output, fixture tests, CI. | -| 4 | Spec cleanup, security review, contributor docs, conformance fixtures. | diff --git a/docs/gtm-assessment.md b/docs/gtm-assessment.md deleted file mode 100644 index d33e99e..0000000 --- a/docs/gtm-assessment.md +++ /dev/null @@ -1,82 +0,0 @@ -# Go-to-Market (GTM) Assessment - -## Purpose - -This document summarizes how ready this repository is for go-to-market execution and what should be improved next. - -Assessment date: **2026-04-29**. - -## Executive summary - -**Overall GTM readiness: 7.5 / 10.** - -The project is technically strong and credible for developer adoption now. The main gaps are commercial clarity: clearly defined buyer segments, measurable business outcomes, and packaging/enablement materials for enterprise purchasing. - -## Assessment areas and scores - -| Area | Score | Summary | -|---|---:|---| -| Narrative clarity | 8.5 | Strong technical story around runtime authorization and trust-before-execution. | -| ICP and personas | 6.5 | Good role-based docs, but top buyer segments and purchase triggers are not explicit. | -| Adoption readiness | 8.5 | Specs, SDKs, reference implementations, and examples are in good shape. | -| Proof and trust signals | 7.0 | Security and governance docs are strong; external proof points are limited. | -| Commercial packaging | 6.0 | Open-source vs commercial boundary is clear, but edition and procurement guidance is limited. | -| Distribution and partnerships | 7.0 | Integration paths exist, but partner playbooks and co-sell assets are not documented. | -| Launch operations | 8.0 | Roadmap and readiness docs are solid; launch KPI instrumentation is not yet explicit. | - -## What is working well - -- Clear positioning for runtime governance in agent, CI/CD, and API environments. -- Practical path to implementation using contracts, SDKs, and reference services. -- Strong enterprise confidence signals via security, governance, and threat-model documentation. -- Clear explanation of what is open-source versus commercial. - -## Key GTM gaps - -1. **ICP definition is not explicit enough** - - The repo does not clearly prioritize the top 2–3 buyer segments. - - Segment-specific pain-to-value messaging is limited. - -2. **Business value proof is underdeveloped** - - Limited quantified outcome framing (e.g., risk reduction, policy coverage improvement, faster incident response). - - No public benchmark or case-study style proof in repo-facing materials. - -3. **Commercial packaging needs to be clearer** - - No explicit edition matrix showing OSS baseline vs managed/enterprise offerings. - - Limited procurement-friendly collateral. - -4. **Partner and sales enablement are light** - - Technical integration guidance is present, but partner activation material is limited. - -5. **Launch metrics are not codified** - - No single KPI definition document for launch health and funnel progression. - -## Recommended 30/60/90 plan - -### 0–30 days -- 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 baseline performance results using `docs/ops/performance-methodology.md`. -- Use `docs/gtm/partner-integration-playbook.md` for first partner integration conversations. - -### 61–90 days -- 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 - -- Quickstart activation rate -- Successful non-demo `/re/authorize` adoption rate -- Time from first touch to first staged governed workflow -- Protected-action policy coverage growth -- External integration contributions per quarter - -## Bottom line - -The repository is ready for technical adoption and pilot deployments. To improve commercial conversion and enterprise scaling, prioritize clearer ICP messaging, quantified value proof, and stronger packaging/enablement assets. diff --git a/docs/repo-completeness-assessment.md b/docs/repo-completeness-assessment.md deleted file mode 100644 index c633635..0000000 --- a/docs/repo-completeness-assessment.md +++ /dev/null @@ -1,27 +0,0 @@ -# Repository Completeness Assessment - -## Scope assessed -- Core protocol specs -- API contract completeness -- SDK usability -- Reference implementation behavior -- User/Admin documentation -- CI and governance workflows - -## Current status (as of 2026-04-25) - -| Area | Status | Notes | -|---|---|---| -| Runtime authority decision model | Complete baseline | 4 outcomes + mode semantics implemented. | -| Receipt model | Complete baseline | Structured receipt sections + integrity hash/chain + signature fields. | -| API contract artifacts | Complete baseline | OpenAPI + JSON Schemas + examples included in `specs/`. | -| Contract validation | Complete baseline | `test:contracts` validates contract artifact integrity. | -| Receipt signing + verification | Complete baseline | HMAC default + optional RS256 + verification utility. | -| Durable receipt storage abstraction | Complete baseline | `memory` and `file` backends supported. | -| CI smoke matrix coverage | Complete baseline | Smoke checks assert PERMIT/STEP_UP/ESCALATE/DENY + reauthorize flow. | - -## Remaining production hardening recommendations -1. Add managed DB/object-store adapter (in addition to local file mode). -2. Add caller authentication middleware profile (OIDC/JWT validation) for production deployment. -3. Add formal SLO dashboards and synthetic probes for production legacy FrontDesk deployments. -4. Publish automated key rotation runbook/scripts for RS256 mode. diff --git a/protocol/spec.md b/protocol/spec.md index 98dcb35..1d80680 100644 --- a/protocol/spec.md +++ b/protocol/spec.md @@ -15,5 +15,4 @@ For the current scope and grammar, see: - [`../README.md`](../README.md) - [`../SPECIFICATION.md`](../SPECIFICATION.md) -- [`../docs/MVP.md`](../docs/MVP.md) - [`../THREAT_MODEL.md`](../THREAT_MODEL.md)