Sp
Specter
toolchain · the compiler

tsc, but for specifications.

Specter validates specification files the way a type checker validates source code: parse, resolve dependencies, type-check constraints, measure coverage, gate CI.

The toolchain we use to build OpenWatch and Kensa — open to anyone.

MIT licensedv0.4.1Single static Go binaryZero runtime deps
$ brew install hanalyx/tap/specter
Read the docs →View on GitHub ★
$ specter sync
✓parseMalformed YAML52 ok
✓resolveCircular deps, refs0 err
✓checkOrphan constraints0 err
✓coverageTier-1 ≥ 100%100%
◆syncCI gate · mergePASS
✓ all specs in sync — merge unblocked

The pipeline

Five stages, each catching a different class of error

Specter treats .spec.yaml files as first-class artifacts in a dependency graph — authoritative, testable contracts the codebase is derived from.

01ParseMalformed YAML, missing required fields, schema violations~ Syntax errors
02ResolveCircular dependencies, broken references, version mismatches~ Linker errors
03CheckOrphan constraints (no coverage), conflicts, breaking changes~ Type errors
04CoverageAcceptance criteria without tests, tier-based thresholds~ Code coverage
05SyncFull pipeline as a CI gate — pass or fail the merge~ Build gate
Plus:specter watchspecter diffspecter doctorspecter explainspecter reversespecter init

Why it exists

When an auditor asks “how do you know your rules are correct?”

The answer most vendors give is “we have a code review process.” Ours is verifiable:

“Every rule has a spec. Every spec has acceptance criteria. Every criterion has a test. A compiler gates CI to enforce 100% coverage. Here is the tool. Read it yourself.”

Verifiable
Anyone can run specter sync against the Kensa repo and see whether specs, tests, and code are in alignment.
Auditable
The CI pipeline's pass/fail history is a permanent record of specification compliance at every merge.
Machine-enforced
Not a process that depends on human diligence — the build fails if coverage drops below the tier threshold.

Maps to controls auditors evaluate

Process credibility, as a NIST artifact

SA-11
Developer Testing & Evaluation
Coverage enforcement is concrete evidence of systematic testing derived from specifications.
SA-15
Development Process, Standards & Tools
Specter is the tool enforcing the process. Its existence proves the process is real, not aspirational.
CM-3
Configuration Change Control
Spec changes trigger code changes. Specter's diff and sync commands enforce this mechanically.
Specter validates its own specs
5
specifications
33
acceptance criteria
37
tests
100%
coverage, all specs

Specter also validates Kensa's and OpenWatch's specs. Every Hanalyx product's spec compliance is enforced by a tool that is itself spec-compliant. The trust chain is recursive — and auditable.

For AI coding agents

As AI agents write more production code, the question shifts from “can the AI write it?” to “can anyone verify the AI wrote it correctly?” Specter is that verification layer.

The spec is the contract
The agent's input is the spec; its output is the implementation. Specter validates the spec is well-formed before the agent starts.
Coverage catches gaps
If the agent skips edge-case tests, the coverage stage fails the build. Missing tests must be added before the merge gate opens.
Drift is mechanical
If code and spec diverge, sync flags it. "Divergence is a bug" is enforced by a compiler, not human memory.
Part of the Hanalyx family
OW
OpenWatch
The compliance OS. Fleet eye, heartbeat, and control plane.
→
Kn
Kensa
The change engine. Transactional config management with rollback.
→

Specs as code. Enforced by a compiler.

MIT licensed. Single static binary, zero runtime dependencies. Use it whether or not you use anything else from Hanalyx.

$ brew install hanalyx/tap/specter
Read the docs →View on GitHub ★