Lexicons

A lexicon is a collection of types and semantic lint rules for an operational area. The core system is lexicon-agnostic — it discovers files, collects exports, resolves dependencies, and runs semantic lint rules. Each lexicon plugs into this pipeline with its own types and rules.

Available Lexicons

Lexicon	Package	Resources	Reference
AWS CloudFormation	@intentius/chant-lexicon-aws	1500+	Reference
Azure ARM	@intentius/chant-lexicon-azure	200+	Reference
GCP Config Connector	@intentius/chant-lexicon-gcp	150+	Reference
Kubernetes	@intentius/chant-lexicon-k8s	50+ resources, 35+ properties	Reference
Helm	@intentius/chant-lexicon-helm	10+ resources	Reference
GitHub Actions	@intentius/chant-lexicon-github	2 resources, 13 composites	Reference
GitLab CI/CD	@intentius/chant-lexicon-gitlab	3 resources, 16 properties	Reference — also ships GitHub Actions migration
Docker	@intentius/chant-lexicon-docker	6 resources (Compose + Dockerfile)	Reference
Temporal	@intentius/chant-lexicon-temporal	4 resources + Op workflow engine	Reference

Runtime observation coverage

Lexicons opt into the chant lifecycle diff <env> --live pipeline by implementing one of two plugin methods: describeResources() (entity-keyed — for 1:1 cloud resources) or listArtifacts() (context-keyed — for runtime concepts created by tooling outside chant’s entity model). See Drift Detection — Resources and artifacts for the conceptual distinction, and Implementing Observation for the author-side walkthrough.

Lexicon	describeResources()	listArtifacts()	Ownership	Notes
AWS	✅		Tags	aws cloudformation describe-stack-resources; --owned available on live export (not on describe — tags absent there)
Azure	✅		Tags	az resource show per declared entity; resource-group is the env name. --owned available on live export (az group export carries tags; not on describe)
GCP (Config Connector)	✅		Labels	kubectl get <gvk> against the GKE management cluster
Kubernetes	✅		Labels	kubectl get <kind> per declared entity; ~20 common types
Temporal	✅		—	Temporal client — namespaces, search attributes, schedules
Helm		✅	—	helm list -A -o json — releases as artifacts
Docker		✅	—	docker ps, docker image ls, docker network ls (NDJSON)
GitHub Actions			—	N/A — workflow definitions are git-tracked; drift is git diff (rationale)
GitLab CI/CD			—	N/A — same rationale (README)

Lexicons that implement neither are warn-skipped — --live doesn’t fail the whole command for them.

The Ownership column shows the marker channel a lexicon queries for the --owned filter (ownership marking). — means the --owned query isn’t available for that lexicon — it has no durable marker channel. Where a lexicon is asked for owned resources but can’t read a marker on a given path — e.g. AWS and Azure describeResources, which the filter degrades to detect-only — it logs that ownership is unavailable and returns everything rather than silently filtering. The --owned filter is honored on live export, where the full config (with tags) is available.

Cross-lexicon migration

The GitLab lexicon ships a chant migrate source for from: github — translates .github/workflows/*.yml into .gitlab-ci.yml (or typed chant TypeScript), with provenance recorded as SARIF and a curated mapping table for the top 33 marketplace actions. See GitLab → Migration for the full surface, or the chant migrate CLI reference.

Future lexicons can opt into the same machinery by implementing migrationSource(from: string) on their plugin.

What a Lexicon Provides

Types

TypeScript definition files that describe available resource classes, their properties, and intrinsic functions. These types power editor autocompletion, inline documentation, and compile-time checks.

Rules

Lint rules specific to the target ecosystem. These integrate with chant lint to catch provider-specific mistakes like invalid resource configurations or naming convention violations.

Serialization

Each lexicon implements the Serializer interface to convert evaluated resources into the target platform’s output format.

interface Serializer {
  name: string;
  rulePrefix: string;
  serialize(entities: Map<string, Declarable>, outputs?: LexiconOutput[]): string | SerializerResult;
}

Bundles

A bundle is the distributable form of a lexicon — a dist/ directory containing everything chant needs at build time:

Artifact	Description
manifest.json	Lexicon metadata (name, version, intrinsics, pseudo-parameters)
meta.json	Resource registry mapping type names to definitions
types/index.d.ts	TypeScript declarations for all resource and property types
integrity.json	Per-artifact xxhash64 checksums
rules/	Lint rule implementations
skills/	AI assistant skill definitions

When you install a lexicon package (e.g. @intentius/chant-lexicon-aws), the bundle is what ships inside it. Lexicon authors produce bundles with chant dev publish.

Why Lexicons Exist

chant is provider-agnostic by design. The core handles parsing, module resolution, evaluation, and serialization — but knows nothing about specific infrastructure platforms.

Lexicons bridge this gap:

• The core stays lean — no bundled provider SDKs or type catalogs
• Providers update independently — new resource types ship as lexicon updates
• Custom targets are first-class — organizations can author internal lexicons
• Projects declare exactly what they need — explicit, reproducible dependencies

Next Steps

• Managing Lexicons — add, remove, and update lexicons
• Lexicon Authoring — create and publish your own lexicons