Standards API
Written by Tyler La Fronz on May 18, 2026

The Problem

Engineering teams accumulate standards and best practices over time — security rules, reliability patterns, observability requirements — but those standards are often scattered across wikis, Confluence pages, or word-of-mouth. When AI-powered code review tools enter the picture, there is no structured, machine-readable source of truth they can query to enforce those rules consistently.

The Solution

Standards API is an AI-generated proof of concept exploring what a production-grade standards management service could look like. The entire project — from the data model and service layer to the HTTP routes and Kubernetes manifests — was scaffolded by AI to demonstrate how quickly a well-structured API can be produced. It stores versioned engineering standards in PostgreSQL and exposes them to AI code review tooling and developer workflows. Each standard is a structured rule with a stable rule_key, a lifecycle (draft → active → deprecated), severity and category classifications, applicability metadata, and concrete good/bad code examples.

The /api/v1/standards/applicable endpoint is the core feature: given a repository, team, language, framework, or list of changed file paths, it returns only the rules that apply to the current context — making it straightforward for a code review agent to pull exactly the right standards before evaluating a pull request.

Architecture

  • Runtime: Node.js 22 with TypeScript
  • Framework: Fastify with @fastify/sensible for structured error responses
  • Database: PostgreSQL via Prisma ORM
  • Validation: Zod schemas at the HTTP boundary, with a clean separation between transport and domain types
  • Auth: Optional X-API-Key header for write operations; always enforced in production
  • Docs: Auto-generated OpenAPI spec served at /openapi.json with a Redoc UI at /docs
  • Deployments: Docker Compose for local dev; Kubernetes manifests included for production

Versioning Model

The versioning model is a first-class concern. Each database row represents one version of a rule identified by a stable rule_key. Draft rules are updated in place; updating an active or deprecated rule creates a new version automatically. When a new active version is created, the previous active version is atomically marked deprecated and a deprecated_at timestamp is set — preserving history while keeping the latest view clean.

A partial unique index on (rule_key, status) enforces that only one active version can exist per rule key at any time.

Key Endpoints

  • GET /api/v1/standards/latest — all active rules, versioned payload for caching
  • GET /api/v1/standards/applicable — context-filtered rules by repo, team, language, framework, file path globs
  • GET /api/v1/standards/:ruleKey — latest version of a specific rule
  • POST /api/v1/standards — create a new rule (write key required)
  • PUT /api/v1/standards/:ruleKey — update or version a rule (write key required)
  • GET /openapi.json + GET /docs — machine-readable and human-readable API documentation

More Information