Part I: The Product Vision📋

A 300-line scanner proved the concept. A Diem instance makes it a product.

What V1 Proved📋

The typed specifications series was an experiment on a real website. Not a toy. Not a proof-of-concept repo with two files. A production site with 20 features, 112 acceptance criteria, and 644+ tests across six layers.

The core idea worked:

• Features as abstract classes. Each feature is a type. Each acceptance criterion is an abstract method. The type system is the specification language.
• @Implements decorators with keyof T. Tests link to features at compile time. Typos fail the build. The compiler catches drift before humans notice it.
• A 300-line compliance scanner. It reads feature definitions, scans test files for decorator references, cross-references the two, produces a coverage matrix, and fails the build if the chain breaks.
• A quality gate. The scanner runs in CI. If a feature has an untested acceptance criterion, the pipeline fails.

The compiler enforces the chain. The scanner quantifies completeness. The quality gate blocks regressions. On a single TypeScript project, with a single developer, it works.

But "works for one developer on one project" is not a product.

What the Versus Series Revealed📋

The comparison against eight alternatives was supposed to validate the approach. It did — but it also found 42 specific gaps where the current system falls short of what enterprise teams need.

Those gaps organize into seven categories:

Six of those gaps are "nice to have." The other 36 are table stakes for any team with more than five developers.

The Jira comparison was the most telling. Jira has terrible traceability — string-based, manual, no compiler checks — but it has workflows, dashboards, sprint planning, assignments, and cross-team visibility. Typed specifications have none of those. The architecture is right. The scope is not.

The full gap-closure matrix is in the series overview.

The Product Thesis📋

What if the type system were the source of truth for project management?

Not as a thought experiment. As a product. One that ships to enterprise teams and solves a problem they are currently solving badly with Xray, Zephyr, and spreadsheets.

The thesis is specific: tspec is not Jira. tspec is the compiler-enforced traceability layer that makes Jira's data trustworthy — or replaces the traceability layer entirely. Jira does workflow. tspec does verification. They sync bidirectionally, and neither drifts because the compiler is the authority.

The architecture has three layers:

Language backends live on developer machines. Each one understands its language's type system: Roslyn for C#, decorators for TypeScript, annotations for Java, proc macros for Rust. All of them produce the same JSON format. The Diem instance does not care which language produced the scan.

The Diem instance is the central server. It stores scan results, runs workflows, serves the dashboard, exposes the API. It is built on Diem CMF — roughly 200 lines of content model with Diem attributes. Diem generates the REST API, the Blazor admin dashboard, the workflow engine, search, pagination — everything. tspec writes the content model. Diem writes the infrastructure.

Integrations connect to the tools teams already use. Jira sync is bidirectional: features can be imported from Jira tickets, and coverage data flows back. Slack notifications, CI/CD webhooks, and Grafana metrics round out the ecosystem.

Before and After📋

The contrast between V1 and the product tells the story.

Before: a developer runs a scanner and reads console output. Maybe.

After: the scan is one step in a pipeline that ends with dashboards, approvals, and audit trails.

The scanner does not change. The architecture around it does. V1 proved that the compiler can enforce traceability. The product makes that enforcement visible, auditable, and actionable across an organization.

Why Enterprise B2B📋

Consider a large industrial CAC40 company. 1000+ developers. 500+ microservices. Dozens of teams across .NET, React, and Java stacks. Three time zones. Regulatory requirements for traceability. Annual audits.

They use Jira for workflow — and they should. Jira is good at workflow. They use Xray or Zephyr for test traceability — and they shouldn't, because those tools are string-based and manual. A developer writes a test. A QA engineer opens Xray. They create a link. They type the test name. They type the requirement ID. There is no compiler. There is no verification that the link is correct. There is no build failure when the link drifts.

Six months later, the audit reveals that 40% of the traceability links are stale. The test was renamed. The requirement was reorganized. Nobody updated the link because Xray does not know the link is wrong. It is a string in a database.

tspec replaces that layer. Not Jira — the traceability layer sitting on top of Jira. The developer writes @Implements<LoginFeature>('mfaRequired'). The compiler verifies that mfaRequired is a real acceptance criterion on LoginFeature. The scanner verifies that every acceptance criterion has at least one implementation. The quality gate fails the build if coverage drops. The Diem instance stores the results, shows the dashboard, runs the workflow, and syncs the status back to Jira.

The competitive positioning is narrow and deliberate:

• Xray/Zephyr do string-based traceability. tspec does compiler-enforced traceability.
• Jira does workflow and project management. tspec does verification and compliance.
• Together, the combination gives enterprise teams what neither tool can provide alone: trustworthy data in a managed workflow.

The first real Diem deployment will be tspec itself, tracking its own requirements with its own system. If the product breaks, its own compliance drops, its own quality gate fails. The product refuses to ship a broken version of itself. That is the proof that the framework works at scale — and the story that sells it to the next team.

Previous: Overview and Gap-Closure Matrix | Next: Part II: The Meta-Metamodel