The ultimate proof of a compliance system is not a demo. It is not a case study. It is the product tracking itself. If tspec cannot enforce its own quality, why should anyone trust it to enforce theirs?

The Product Tracks Itself📋

tspec's own Diem instance runs the Requirements DSL against tspec's own codebase. The scanner scans tspec. The dashboard shows tspec's coverage. The quality gate blocks tspec's releases. This is not a future plan — it starts in Phase 1, before any customer sees the product.

Every feature described in this blog series exists as a typed spec in tspec's own source tree. Every acceptance criterion has an abstract method. Every abstract method is tested. The scanner verifies it. The dashboard displays it. The quality gate enforces it.

If tspec breaks, its own compliance drops. If its own compliance drops, its own quality gate fails. If its own quality gate fails, tspec cannot ship.

tspec's Own Requirements📋

The product defines three Epics, each containing Features with concrete acceptance criteria.

Epic: Core Platform📋

The foundation. Scanner, workflow engine, dashboard rendering.

@Epic({ id: 'EPIC-CORE', name: 'Core Platform' })
abstract class CorePlatformEpic extends EpicSpec {

  @Feature({ id: 'FEAT-SCANNER', name: 'Scanner' })
  abstract scanner: ScannerFeature;

  @Feature({ id: 'FEAT-WORKFLOW', name: 'Workflow Engine' })
  abstract workflow: WorkflowFeature;

  @Feature({ id: 'FEAT-DASHBOARD', name: 'Dashboard' })
  abstract dashboard: DashboardFeature;
}

Epic: Enterprise Features📋

Multi-tenancy, Jira sync, SAML, audit logging.

@Epic({ id: 'EPIC-ENTERPRISE', name: 'Enterprise Features' })
abstract class EnterpriseFeaturesEpic extends EpicSpec {

  @Feature({ id: 'FEAT-JIRA', name: 'Jira Sync' })
  abstract jiraSync: JiraSyncFeature;

  @Feature({ id: 'FEAT-MULTITENANT', name: 'Multi-Tenant' })
  abstract multiTenant: MultiTenantFeature;
}

Epic: Integration📋

CLI tooling, CI/CD plugins, API surface.

@Epic({ id: 'EPIC-INTEGRATION', name: 'Integration' })
abstract class IntegrationEpic extends EpicSpec {

  @Feature({ id: 'FEAT-CLI', name: 'CLI Tooling' })
  abstract cli: CliFeature;

  @Feature({ id: 'FEAT-CICD', name: 'CI/CD Plugins' })
  abstract cicd: CiCdFeature;
}

The Scanner Feature — tspec Tracking Itself📋

Here is the Scanner feature — the component that scans codebases for typed specs — defined as a typed spec that the scanner itself scans:

@Feature({
  id: 'FEAT-SCANNER',
  name: 'Scanner',
  priority: Priority.Critical
})
abstract class ScannerFeature extends FeatureSpec {

  /** Scanner discovers all abstract spec classes in the target project. */
  abstract discoversAbstractSpecs(): ACResult;

  /** Scanner extracts JSDoc comments from abstract methods. */
  abstract extractsJSDoc(): ACResult;

  /** Scanner resolves test-to-AC mappings via naming conventions. */
  abstract resolvesTestMappings(): ACResult;

  /** Scanner detects coverage changes between two snapshots. */
  abstract detectsCoverageChanges(): ACResult;

  /** Scanner produces structured JSON output compatible with Diem API. */
  abstract producesStructuredOutput(): ACResult;

  /** Scanner completes full project scan in under 10 seconds for 500-file projects. */
  abstract performanceUnder10Seconds(): ACResult;

  /** Scanner reports clear errors when spec classes contain syntax errors. */
  abstract reportsSyntaxErrors(): ACResult;

  /** Scanner supports incremental mode, scanning only changed files. */
  abstract supportsIncrementalScan(): ACResult;
}

Eight acceptance criteria. Each one has a test. The scanner runs against this file, finds these eight abstract methods, checks for corresponding test implementations, and reports coverage. The same scanner that does this for customer codebases does it for its own codebase.

The Self-Referential Loop📋

This pattern was introduced in Part VI: Compliance as REQ-TRACK — a feature with 7 ACs that tracked the tracking system itself. That was a proof of concept. This is the production-scale version.

tspec defines a SelfTrackingFeature with an acceptance criterion that verifies the loop is unbroken:

@Feature({
  id: 'FEAT-SELFTRACK',
  name: 'Self-Tracking',
  priority: Priority.Critical
})
abstract class SelfTrackingFeature extends FeatureSpec {

  /** tspec's own Diem dashboard shows tspec's feature coverage. */
  abstract tspecDashboardShowsTspecCoverage(): ACResult;

  /** tspec's quality gate evaluates tspec's own compliance before release. */
  abstract qualityGateEvaluatesSelf(): ACResult;

  /** tspec's own compliance report is publicly accessible. */
  abstract complianceReportIsPublic(): ACResult;

  /** All tspec features maintain 100% AC coverage in CI. */
  abstract allFeaturesAt100Percent(): ACResult;
}

The test for tspecDashboardShowsTspecCoverage queries tspec's own Diem API, fetches the scan results for the tspec project, and asserts that the dashboard correctly renders coverage data for all tspec features. If the dashboard rendering breaks, this AC fails, which causes tspec's own coverage to drop below 100%, which triggers the quality gate, which blocks the release.

The test for allFeaturesAt100Percent is the tightest loop: it queries the scan results and asserts that every tspec feature — including SelfTrackingFeature itself — is at 100% coverage. If any AC anywhere in tspec loses its test, this assertion fails. The product cannot ship with known gaps.

This is a fixed point. The system is stable only when it fully tracks itself. Any perturbation — a deleted test, a new AC without a test, a broken scanner — propagates through the loop and surfaces as a blocked release.

Why This Matters for Enterprise Sales📋

Enterprise buyers evaluate tools differently than individual developers. A developer asks "does it work?" An enterprise buyer asks "do you trust it enough to use it yourself?"

Dog-fooding answers that question definitively. tspec does not merely claim to provide compiler-enforced traceability. It uses compiler-enforced traceability on itself. The proof is not a slide deck — it is a live dashboard.

The trust chain works like this:

1. A prospect asks "how do you ensure quality?"
2. We point them to tspec's own Diem dashboard — public, live, updated on every commit
3. They see every Epic, Feature, and AC in tspec's own product
4. They see 100% coverage, verified by the same scanner they would be buying
5. They see the quality gate configuration — the same gate that would protect their codebase
6. They see the compliance report — generated by the same generator that would produce their reports

The prospect is not evaluating a demo. They are evaluating the actual product running on itself. Every feature they inspect in the dashboard is a feature they could use. Every AC they read is enforced by the system they are considering.

This is an asymmetric advantage. Competitors who sell compliance tools but track their own work in Jira cannot make this claim. Their product says "enforce traceability" while their process says "update the ticket when you remember."

Phase 1 Commitment📋

Dog-fooding does not start in Phase 3 when the product is mature. It starts in Phase 1 — Foundation.

The very first features built (scanner, basic workflow, initial dashboard) are defined as typed specs in tspec's own source tree. The scanner scans itself from the first week. The quality gate evaluates itself from the first passing build. Coverage starts at whatever it starts at — maybe 40% in week one — and the team watches it climb.

This serves two purposes. First, it catches bootstrap bugs early. If the scanner cannot handle its own codebase structure, it certainly cannot handle a customer's. Second, it creates an internal forcing function. The team experiences the same workflow they are building for customers. Friction in the approval process, confusing dashboard layouts, slow scan times — the team feels it first.

By the time Phase 2 begins and early customers onboard, the tspec team has months of experience using their own product. They have refined the UX through daily use. They have fixed the pain points that only emerge after weeks of real usage. The product is not theoretically good — it is practically proven.

The Pattern Generalizes📋

Dog-fooding is not unique to tspec. But self-referential dog-fooding — where the product's own tracking system uses the product — is rare. A project management tool can track its own tasks, but the tasks do not enforce the tool's correctness. tspec's self-tracking is structural. The enforcement is automatic. The loop is closed by the compiler and the scanner, not by human discipline.

Any team adopting tspec can apply the same pattern. Define your product's features as typed specs. Scan your own codebase. Gate your own releases. Your compliance dashboard becomes both a development tool and a sales asset.

The product that tracks itself is the product that can be trusted to track anything.

Previous: Part IX: The Stakeholder View | Next: Part XI: Roadmap and Phases