Philosophy

Infrastructure tools give you syntax — YAML schemas, HCL blocks, SDK constructors. What they don’t give you is semantics: whether what you declared actually makes sense in context. That’s the gap chant closes.

chant's three conceptual layers

Two Ideas

Lexicons are collections of types and semantic lint rules for an operational area. A lexicon knows what resources exist in its domain and can validate whether your declarations are coherent — not just structurally correct, but semantically meaningful.

Synthesis takes typed TypeScript declarations in and produces validated artifacts out. You write TypeScript objects, chant resolves dependencies, and serializes to the target format.

A Synthesis Compiler

chant is a compiler. TypeScript in, spec-native output out. This isn’t a new idea — it’s an approach that was always available. Nobody built it because the industry was racing to own the full lifecycle: state management, deployment, drift detection, rollback. chant does one thing and stops at the boundary where operational tooling begins.

TypeScript as Data

Most IaC tools that use general-purpose languages — CDK, Pulumi, Terraform’s CDK — work by executing your code. Your program runs, makes API calls, and the tool captures the result.

chant runs synthesis only. It imports your .ts files, reads the resource objects they export, and emits output. It never calls a cloud API, reads or writes state, or deploys. Your TypeScript declares intent. The build turns that intent into an artifact and stops.

Synthesis does run your code. It runs only a constrained slice of it. The evaluability lint rules (EVL) reject anything that would make a resource depend on more than literals, constants, and cross-resource references. No function calls in props. No control flow around resources. With those rules satisfied, running the file is equivalent to reading static data. That constraint is the point. Because synthesis is side-effect-free and deterministic for conforming source:

• Evaluation is deterministic for code that passes the evaluability rules. Same source, same output. No API calls during synthesis.
• Analysis is a single pass over the imported modules. Type-checking and linting are separate commands.
• Output is auditable — every value traces to a literal, a const binding, or a cross-resource reference.
• IDEs work fully — types drive the API surface, so autocompletion, inline errors, and go-to-definition come for free.

The static evaluation constraint also makes chant a natural complement to agentic workflows. Agents handle the dynamic, operational layer — deploying, monitoring, remediating. chant handles the part that should be deterministic and auditable. The two layers don’t compete; they compose.

Spec-True, Not Cloud-Abstract

Each lexicon is faithful to its target spec. The AWS lexicon generates from the CloudFormation resource specification. The GitLab lexicon maps to .gitlab-ci.yml schema. Chant doesn’t invent an abstraction layer across specs — it gives you the real API surface, typed and linted.

This means walk-away cost is zero. The output is standard CloudFormation, standard GitLab CI, standard whatever-the-lexicon-targets. If you stop using chant, the artifacts keep working. There’s nothing chant-specific in the output.

What chant Doesn’t Do

chant build produces artifacts — it doesn’t deploy them, call cloud APIs, or manage state. Synthesis is pure and deterministic: same source in, same output out, zero side effects. This is a deliberate scope boundary, not a limitation. A pure core also owns less machinery — no provider SDKs, state backend, or network at build time — which means a smaller surface to audit; see Owning less.

The deployment and operational layer is increasingly handled by agents, CI pipelines, and platform tooling. chant’s job is to make the synthesis step typed, linted, and deterministic — then hand off a native artifact that any deployment mechanism can consume.

Anything with a schema is a potential lexicon target. chant doesn’t replace your cloud tooling. It’s a semantic layer on top of it. You can import existing templates, give them types, and lint them alongside everything else.

Operational Assistance

chant’s architecture is concentric: a pure synthesis core surrounded by opt-in operational extensions. The core never changes — chant build is deterministic and side-effect-free. Extensions add operational context without touching the build pipeline.

The design supports declarative deployment workflows (Op — phased Temporal workflows declared in *.op.ts files, run via chant run), continuous lifecycle observation (WatchOp — periodic snapshot+diff scheduled via Temporal), observational lifecycle (chant lifecycle — non-authoritative snapshots; see Drift Detection for the model), and agentic skills for import and drift detection. These extensions share a principle: chant provides context and structure, agents and operators do the operational work.

Opt-in is implicit. If you never use operational extensions, chant is a pure synthesis compiler and nothing more.