20 features, one developer? A CLI is enough. 2,000 features, 50 teams, 500 microservices? You need enterprise infrastructure.

The previous parts built the foundation: a typed specification language, a scanner, a dashboard, workflows, multi-language backends. All of that works beautifully for a single team. But a CAC40 company is not a single team. It is dozens of business units, hundreds of repositories, thousands of developers spread across time zones, and regulators who want audit trails for everything. This part covers the infrastructure that makes tspec viable at that scale.

SSO: One Identity, Every Dashboard📋

Enterprise identity is non-negotiable. Nobody is creating yet another set of credentials for a coverage dashboard. tspec's Diem-backed dashboard supports three federation protocols out of the box:

• SAML 2.0 — for organizations already running Azure AD or ADFS
• OpenID Connect — for Okta, Auth0, Google Workspace, Keycloak
• LDAP — for legacy on-premise directory services

Configuration is a single block in the Diem tenant settings. Once SSO is active, every dashboard user authenticates through the corporate identity provider. No local passwords. No separate user database. Session tokens follow the organization's expiry policy.

The CLI authenticates via device code flow (tspec login), so developers working in terminals get the same SSO experience without a browser redirect dance.

RBAC: Six Roles, Per-Project Granularity📋

Authentication answers "who are you?" Authorization answers "what can you do?" tspec defines six roles that map cleanly to how large organizations actually work:

Roles are assigned per project. A developer can be a ProjectOwner on the payments service and a Viewer on the compliance module. Group mappings from the identity provider feed directly into role assignment — if Azure AD says you are in the payments-team group, Diem assigns the Developer role on the payments project automatically.

Audit Trails: Every Action, Every Detail📋

In regulated industries, "who changed what and when" is not a nice-to-have. It is a legal requirement. tspec logs every mutation as an immutable audit entry:

{
  "id": "audit-2026-03-28T14:32:01.447Z-a3f1",
  "timestamp": "2026-03-28T14:32:01.447Z",
  "actor": "s.erard@acme.com",
  "action": "WorkflowTransition",
  "target": "FEATURE-NAV-001",
  "before": { "state": "InProgress", "coverage": 0.72 },
  "after": { "state": "Review", "coverage": 0.95 },
  "ip": "10.0.12.34",
  "userAgent": "tspec-cli/1.4.0"
}

Every entry captures the actor, the action, the before/after state, the client IP, and the tool version. Entries are append-only — no updates, no deletes. This design satisfies the requirements of ISO 27001 (information security management), SOC 2 Type II (service organization controls), and FDA 21 CFR Part 11 (electronic records for healthcare and pharma).

Audit logs are exportable as JSON, CSV, or PDF for compliance reviews. The dashboard includes a filterable audit viewer with date ranges, actor search, and action type filters.

Multi-Repo Federation📋

Large organizations do not have one repository. They have dozens, sometimes hundreds. Each repo runs its own scanner and pushes results independently:

# In repo payments-api (C#)
tspec scan --push

# In repo storefront-app (TypeScript)
tspec scan --push

# In repo inventory-service (Java)
tspec scan --push

All three pushes land in the same Diem instance. The dashboard aggregates across all repositories, providing:

• Org-wide coverage view — a single number across every repo, every language
• Team-level filtering — show only the repos owned by the payments team
• Cross-repo feature tracking — a feature defined in the backend can have ACs validated by tests in the frontend
• Dependency awareness — when a shared library changes, see which downstream repos are affected

One Diem instance. Many repos. One source of truth.

Multi-Language Backends📋

A CAC40 company rarely uses a single language. The .NET backend team, the React frontend team, and the Java integration team all need to participate. tspec supports this natively because every language backend produces the same JSON protocol:

• C# — tspec-cs scans .NET assemblies via Roslyn
• TypeScript — tspec-ts scans decorators and JSDoc
• Java — tspec-java scans annotations
• Groovy — tspec-groovy scans AST transforms
• Python — tspec-py scans decorators
• Go — tspec-go scans struct tags and comments
• Rust — tspec-rs scans derive macros

All seven backends feed the same Diem instance. The dashboard does not care which language produced the data. A feature is a feature. An AC is an AC. Coverage is coverage.

Multi-Tenancy: Three Deployment Models📋

A tenant in tspec is an organization — one CAC40 company equals one tenant. Diem handles tenant-scoped content natively, so data isolation is built into the content model, not bolted on as an afterthought.

Three deployment models serve different enterprise needs:

Shared SaaS — Multiple tenants share a single Diem instance. Data is isolated via tenant ID at the query layer. Cost-effective for mid-size organizations that do not have strict data residency requirements.

Dedicated SaaS — One Diem instance per tenant, managed by the tspec team. Full infrastructure isolation. The tenant gets their own database, their own compute, their own backup schedule. For organizations that need isolation but do not want to manage infrastructure.

On-Premise — The tenant runs their own Diem instance behind their firewall. Delivered as Docker images or Helm charts for Kubernetes. Air-gapped deployment supported. For defense contractors, financial institutions, and anyone whose data cannot leave the building.

Each tenant configures their own M2 flavor (safe, full, or custom), their own workflows, their own support levels, their own RBAC mappings, and their own Jira integration settings. Provisioning is a single command:

tspec tenant create --name="ACME" --flavor=safe --admin=cto@acme.com

Cross-tenant analytics are available on an opt-in basis: anonymized benchmarks that let a tenant see how their coverage compares to industry averages without revealing any proprietary data.

Data Residency📋

GDPR, data sovereignty laws, and internal compliance policies often require that data stays within a specific geographic region. tspec supports three regions:

• EU (Frankfurt) — for European data residency requirements
• US (Virginia) — for North American deployments
• APAC (Singapore) — for Asia-Pacific operations

Tenant data never leaves its designated region. Backups, replicas, and CDN edges all respect the residency boundary. For on-premise deployments, data residency is inherently satisfied — the data lives wherever the customer puts it.

Before and After📋

What changes when you go from a solo developer to an enterprise deployment?

That was fine for prototyping. At enterprise scale:

Same typed specifications. Same scanner protocol. Same JSON format. The only difference is the infrastructure behind the API endpoint — and enterprise organizations get SSO, RBAC, audit trails, multi-repo federation, multi-tenancy, and data residency on top.

What Comes Next📋

Enterprise infrastructure makes tspec viable for large organizations. But viable is not valuable until tspec connects to the tools those organizations already use. Part XII covers bidirectional integrations — Jira, Azure DevOps, Linear, Slack, CI/CD pipelines, OpenAPI, and Grafana.

Previous: Part X — Multi-Language Backends | Next: Part XII — Integrations