Kiro took a working TypeScript governance library — 136 passing tests, 6 core components — and generated a complete multi-tenant SaaS productization: Fastify API server, PostgreSQL + Redis multi-tenant data isolation, Git-webhook-triggered policy hot-reload with zero downtime, blue-green index swapping, encrypted credential store, and a hybrid client SDK with automatic agent/library fallback. The same governance intelligence, now monetizable.
The governance engine started as a TypeScript library imported directly into projects. Kiro drove two successive productization jumps — each adding a new deployment tier without breaking the tier below.
GovernanceIndexer, ComplianceValidator, ArtifactGenerator, ContextManager. Imported directly into each project. Reads local ./governance/ markdown files. 136 tests. 0 infra.
Fastify server exposing the library over REST. GitSyncManager polls/pulls governance repos on webhook push. WebhookHandler verifies GitHub/GitLab HMAC signatures. PolicyUpdateOrchestrator hot-reloads the index.
TenantManager adds full database + cache + filesystem isolation per tenant. API key auth. Encrypted credential storage. Audit trail. Blue-green indexing. Rollback. Client SDK with hybrid fallback.
Kiro's spec for this transformation was precise: take a working library with 100% test coverage and produce a production-grade SaaS service without breaking the library API. The design called for 13 sequential tasks — each shipping a testable milestone — with checkpoints at Tasks 5, 8, and 12 that verified zero TypeScript errors, zero lint errors, and all tests passing before the next task began. The final deliverable at Task 13 was the Client SDK: a three-mode abstraction (agent, library, auto) that lets any consumer choose their deployment tier at configuration time, with automatic fallback to library mode if the agent is unreachable. Zero breaking changes to existing library consumers.
TypeScript strict mode project. Jest + fast-check PBT. ESLint + Prettier. PostgreSQL schema with migrations. Redis with tenant namespace helpers. Docker Compose for all local infra.
Fastify server with middleware stack: API key auth, request logging, error handling, rate limiting, CORS, security headers. Health check endpoint. Service info route. Full error boundary.
Clone + pull governance repos. Change detection (added/modified/deleted). Branch/tag management. Encrypted credential storage. SSH key + PAT support. Retry with exponential backoff.
GitHub HMAC-SHA256 verification. GitLab token verification. 5-minute replay attack prevention window. Per-tenant rate limiting (10/min). Branch-specific change tracking for targeted re-indexing.
Zero-downtime blue-green index swap: new index built in background, validated, then atomically swapped into live. Keeps last 5 successful indexes. Rollback to any commit. Distributed lock prevents concurrent updates for the same tenant.
Full tenant lifecycle: create, read, update, deactivate, reactivate. Tenant isolation enforcement across DB, cache, and filesystem. Configuration validation. Usage statistics. Encrypted credential storage. 5-minute TTL cache.
Multi-tenant validation endpoint. Code artifact submission with language + filepath context. Development stage support. Strict mode, warning toggles, evidence collection options. Violation severity levels + remediation guidance per runbook reference.
Three endpoints: Model Card (with confidence scoring), DPIA (with missing field identification), Risk Assessment (with actionable suggestions). Markdown output. Tenant validation. All artifacts reference the specific governance runbook sections that drove them.
npm package @gov-process/agent-client. Three modes: agent (API only), library (embedded, offline), auto (hybrid with fallback). Lazy loading of library components. Retry + exponential backoff. Mode switching at runtime. Axios HTTP client.
The @gov-process/agent-client SDK abstracts the deployment tier from the consumer.
A team can start in library mode (offline, zero infra), graduate to agent mode (shared service),
and switch via a single config change — no code changes in calling code.
Uses the local TypeScript library with no network calls. Reads from ./governance/ markdown files. Works without any running service. Ideal for offline development and air-gapped environments.
Tries the agent API first. If the agent is unreachable (network failure, cold start, maintenance), automatically falls back to library mode. Tracks fallback count in status. Mode-switchable at runtime via switchMode().
Only uses the remote agent API. Throws if the agent is unavailable. Always gets the latest policy version from the central server. Correct for CI/CD pipelines that must validate against the canonical governance index.
The SaaS productization wrapped these components but never modified them. The test count is the guarantee that the wrapping didn't break anything.
| Component | Responsibility | Tests | Notable |
|---|---|---|---|
| MarkdownParser | Parses governance runbooks — extracts sections, procedures, checklists, frontmatter | 15 unit + 11 PBT | Hierarchical section structure |
| RequirementExtractor | Identifies EARS patterns (ubiquitous, event-driven, state-driven), infers applicability rules, builds requirement relationship graphs | 29 unit | SHALL/MUST detection |
| GovernanceIndexer | Scans directory for runbooks, builds inverted keyword index, caches parsed results | 13 unit | Fast keyword search |
| ProjectClassifier | Classifies into 6 project types (enterprise-ai, high-risk-ai, regulatory-compliance, poc-pilot, customer-facing-ai, generative-ai), custom rules | 17 unit | Priority-ordered rule evaluation |
| ContextManager | Tracks 6 development stages with validated transitions, maintains compliance status, orchestrates governance gates with stage-specific artifacts | 28 unit | Gate status tracking |
| ComplianceValidator | Extensible rule engine, built-in rules for privacy/audit/error handling/docs, violation severity + remediation guidance | 23 unit (AST analysis pending) | Custom rule registration |
A governance service has an unusual constraint: policy updates must not interrupt in-flight validation requests. If a team's CI/CD pipeline is mid-validation when a policy push triggers a re-index, the validation must complete against a consistent index — not a partially-rebuilt one. Blue-green indexing solves this: the new index is built completely in a background slot, validated for correctness, then atomically swapped as the live index. Any requests that started against the old index complete against it; new requests immediately see the updated policy. The last 5 successful indexes are retained, making rollback to any specific commit a single atomic operation.
Schema-per-tenant (one PostgreSQL schema per customer) is operationally expensive at scale — 100 tenants means 100 schema migration runs. Instead, the design uses row-level isolation: every table has a tenant_id column and every query is forced through the TenantManager which injects the tenant filter. Redis uses per-tenant key namespacing ({tenantId}:governance: prefix) for cache and distributed locks. The filesystem isolation gives each tenant a separate directory for cloned governance repositories — their policies never touch another tenant's index. This approach scales to thousands of tenants with a single database schema migration.
A SaaS agent that CI/CD pipelines depend on is a hard dependency — if the agent goes down, builds break. The hybrid SDK eliminates this: auto mode tries the agent first for the latest centrally-managed policies, but falls back to the embedded library if the agent is unreachable. The library uses the governance files checked into the consuming project's repo — slightly stale relative to the central server, but unblocking. This also gives teams a zero-infrastructure path to adopt the governance engine (library mode) and a migration path to the full SaaS offering (agent mode) with no code changes required at the adoption boundary. The SDK tracks fallback count so operators can see if library mode is being invoked unexpectedly.
EARS (Easy Approach to Requirements Syntax) is a structured natural language pattern for requirements that makes them machine-parseable without a formal specification language. The patterns — ubiquitous (The system shall…), event-driven (When X, the system shall…), state-driven (While Y, the system shall…) — appear naturally in governance runbooks written by compliance teams who have no knowledge of formal methods. The RequirementExtractor maps these patterns to structured objects with applicability rules, allowing the GovernanceIndexer to answer "which requirements apply to a Python ML model in the development stage?" without the compliance author having to tag anything explicitly.
Fastify has native TypeScript support, a built-in JSON schema validation layer (via Ajv), and ships with OpenAPI/Swagger plugin support without additional middleware. For a governance API where every request body shape needs to be validated and documented, Fastify's route-level schema declaration produces both runtime validation and Swagger documentation from a single source of truth. Fastify is also ~2× faster than Express in benchmarks — relevant for a validation service that may be called synchronously in developer workflows. The plugin architecture (authentication, rate limiting, CORS) integrates cleanly without the middleware ordering fragility common in Express applications.
auto mode so developers get inline governance feedback while writing code