Phase 1 ships the OSS core. Phase 4 targets enterprise contracts at CAC40 scale.
Everything described in this series — the typed hierarchy, the scanner protocol, the dashboard, the workflows, the multi-language backends, the enterprise infrastructure, the integrations — is a lot of software. Shipping it all at once is how products die. This part lays out a phased roadmap that delivers value at every stage, a pricing model that aligns incentives, and a concrete scenario showing what tspec looks like inside a large industrial organization.
Phase 1: Foundation (Months 1-3)
The first phase delivers the core that everything else depends on.
M3 metamodel and flavors. The hierarchy redesign from Part III lands first. Epics, Features, ACs, and the safe/full/custom flavor system. This is the foundation — get it wrong and everything built on top is wrong.
CLI packaging. Four npm packages ship as the public interface:
@tspec/core— the hierarchy types, JSON protocol, and validation logic@tspec/scanner-ts— TypeScript/JavaScript scanner@tspec/scanner-cs— C# scanner (via Roslyn)@tspec/cli— the command-line tool that orchestrates everything
JSON protocol specification. The wire format between scanners and consumers is versioned and documented. Third-party scanners can target this protocol without depending on tspec internals.
OSS release. The CLI and all language backends ship under the MIT license. The community can use, fork, and extend without restrictions. Enterprise value comes from the cloud layer, not from locking down the scanner.
Dog-fooding from day one. tspec tracks its own features using tspec. Every feature in the roadmap is a typed specification in the repository. Every AC has a test. The coverage dashboard for tspec itself is public. If the tool cannot track its own development, it cannot track anyone else's.
Phase 2: Persistence (Months 4-6)
Phase 1 produces JSON files. Phase 2 gives those files a home.
Diem content model. A Diem instance is configured with the tspec content types: Epics, Features, ACs, scan results, coverage snapshots. Diem's M2 DSL makes this a configuration exercise, not a development project.
tspec push command. The CLI gains the ability to push scan results to a Diem instance. One command after every CI build sends coverage data to the server.
Basic dashboard. The first dashboard delivers two views: the coverage matrix (features vs. ACs, color-coded) and trend charts (coverage over time). No workflow engine yet, no assignments — just visibility.
Historical scan storage. Every push is stored. The dashboard can show coverage at any point in time. "What was our coverage on March 1st?" becomes a query, not a guess.
Multi-tenant foundation. Tenant isolation is built into the data layer from the start. Even if Phase 2 only has one tenant, the architecture supports many. Retrofitting multi-tenancy is painful; designing for it early is cheap.
Phase 3: Collaboration (Months 7-9)
Phase 2 gives visibility. Phase 3 turns visibility into action.
Workflow engine. Custom workflows with coverage-gated transitions. A feature cannot move to "Done" unless coverage exceeds the configured threshold. The eight-state lifecycle from Part VIII ships as the default, with customization available per project.
Assignments and PM view. Features are assignable to team members. The PM view renders specifications in natural language — no code, no decorators, just "the user can filter search results by date range" with a coverage badge next to it.
Jira bidirectional sync. The flagship integration. tspec sync --source=jira pulls structure from Jira. tspec push sends coverage back. PMs stay in Jira; developers stay in the IDE; coverage data flows between them automatically.
Slack integration. Workflow transitions, coverage drops, quality gate failures, and SLA warnings push to configured Slack channels.
DX commands. tspec work FEATURE-123 assigns a feature to the current developer and transitions it to InProgress. tspec done FEATURE-123 transitions it to Review. tspec next shows the highest-priority unassigned feature. These commands turn the workflow engine into something developers actually use, not something they work around.
Phase 4: Enterprise (Months 10-14)
Phase 3 works for a single team. Phase 4 works for an organization.
SSO, RBAC, audit trails. Azure AD, Okta, Google Workspace. Six roles with per-project permissions. Immutable audit logs for compliance. The enterprise infrastructure from Part XI.
Multi-repo federation. Fifty repos pushing to one Diem instance. Org-wide coverage views. Team-level filtering. Cross-repo feature tracking.
Additional language backends. Java, Groovy, Python, Go, and Rust scanners join the existing C# and TypeScript backends. Every backend produces the same JSON protocol.
On-premise deployment. Docker images and Helm charts for Kubernetes. Air-gapped deployment for organizations whose data cannot leave the building.
Compliance certifications. SOC 2 Type II and ISO 27001 certification for the cloud offering. FDA 21 CFR Part 11 compliance documentation for healthcare and pharma customers.
Go-to-Market Strategy
The pricing model follows a pattern proven by tools like GitLab, Sentry, and PostHog: free core, paid cloud, custom enterprise.
OSS core (free, MIT) — The CLI, all language backends, and the JSON protocol are free forever. This builds community, proves the concept, and removes the adoption barrier. A developer can run npx @tspec/cli scan today and get value in five minutes. No signup. No credit card.
Paid cloud ($15/user/month) — The Diem-backed dashboard, trend charts, workflow engine, Jira sync, Slack integration, and team collaboration features. This is where the recurring revenue lives. The free CLI creates the need; the paid dashboard satisfies it.
Enterprise contracts (custom pricing) — On-premise deployment, SSO, RBAC, audit trails, dedicated support, SLA guarantees, and compliance certifications. Priced per organization based on scale and requirements.
| Tier | What You Get | Price |
|---|---|---|
| Free | CLI + all language backends + local scan | $0 |
| Team | Cloud dashboard + trends + workflows + Jira sync | $15/user/month |
| Enterprise | On-premise + SSO + RBAC + audit + SLA + dedicated support | Custom |
The free tier is not a trial. It is the full scanner with no time limit, no feature gating, and no usage caps. The paid tiers add collaboration and infrastructure — things that only matter when more than one person cares about coverage.
CAC40 Use Case: Large Industrial Organization
Consider a large industrial company with 50+ development teams, a mix of .NET backend services, React frontends, and some Java microservices for legacy integration.
Current state. Jira manages the PM workflow. Xray (a Jira plugin) provides test traceability. Xray links are string-based — a test references a Jira ticket ID as a free-text field. Drift is constant. A developer renames a test; the Xray link breaks silently. Nobody notices until the quarterly compliance audit, when the test traceability matrix has gaps that take two weeks of manual work to fill.
After tspec. Jira stays for PM workflow — nobody is migrating 10,000 tickets. tspec replaces Xray. The C# backend teams annotate features with [Feature] and [AC] attributes. The React frontend teams use @Feature and @AC decorators. The Java microservices use @Feature and @AC annotations. All three push to one Diem instance via tspec push in their CI pipelines.
The dashboard shows org-wide coverage across all repositories, all languages, all teams. The PM opens Jira and sees tspec_coverage: 94% on the ticket. The QA lead opens the dashboard and sees which ACs lack test coverage. The CISO opens the audit log and exports a compliance report.
ROI. Xray licenses cost real money per user per year — that cost is eliminated entirely. More importantly, compiler-enforced traceability catches gaps that string-based linking misses. When a developer renames a feature class, the compiler tells them which tests need updating. When an AC is deleted, the build fails until the corresponding test reference is removed. Compliance audit preparation goes from two weeks of manual spreadsheet work to one click: tspec report --format=pdf --scope=org.
The organization does not adopt tspec because it is a better Xray. It adopts tspec because specifications that live in code cannot drift from reality. That is a property string-based tools cannot offer, regardless of how many features they add.
The Full Picture
This series has covered a lot of ground. The typed specification language. The M3 metamodel. The scanner protocol. The coverage matrix. The dashboard. Workflows. Multi-language backends. Enterprise infrastructure. Integrations. And now, the roadmap and business model.
The core insight has not changed since Part I: specifications should be code. Not documentation that describes code. Not tickets that reference code. Code. Typed, compiled, tested code that the compiler can verify, the scanner can analyze, and the dashboard can visualize.
Everything else — the flavors, the workflows, the Jira sync, the enterprise features — is infrastructure that makes that core insight practical at scale.
Previous: Part XII — Integrations | Back to Overview
For the implementation that started it all, see Onboarding Typed Specifications.
For the Diem framework that powers the server, see Building a Content Management Framework.