Polychro — Comparison¶
How Polychro relates to the adjacent tools teams reach for when they want to lint and govern their specifications. For a feature inventory see Features; for the bigger picture see Spec-Driven Integration.
A 2019 problem vs. a 2026 problem¶
Most of the "lint your specs" space solves a 2019 problem: how do we govern OpenAPI files in CI? Polychro is built for the 2026 problem: how do we validate any spec, in-process, at the speed an AI agent generates it? That reframing is the whole point.
The neighbours fall into three segments, each operating at a different layer:
- Meta-linters / orchestrators — Super-Linter, MegaLinter. Large Docker images that bundle dozens of third-party linters and run them in CI. They delegate spec linting to a rule engine.
- Spectral-family rule engines — Spectral (Node), Vacuum (Go), Redocly Lint (TypeScript). Single-purpose linters for OpenAPI / AsyncAPI rulesets.
- Embeddable, polyglot, agent-era spec engines — Polychro. A composable pipeline (well-formedness → schema → ruleset → format-aware) that runs as a native binary, a JVM library, an MCP server, or a GitHub Action.
Polychro replaces the rule-engine layer and absorbs the spec-validation slice of the meta-linters — collapsing what is today three or four tools, two or three config files, and a Docker dependency into one binary, one config, one diagnostic format, sub-second. Because it speaks the Spectral ruleset format natively, existing rule investment carries over unchanged.
Side-by-side¶
| Dimension | Super-Linter | MegaLinter | Spectral | Vacuum | Polychro |
|---|---|---|---|---|---|
| Category | Meta-linter | Meta-linter | Rule engine | Rule engine | Spec engine |
| Primary language | Bash (wraps tools) | Python | TypeScript / Node | Go | Java (+ GraalVM native) |
| Distribution | Docker ~2 GB | Docker 0.8–2 GB | npm + Docker | Single binary | Binary + JVM + npm + PyPI + Go module |
| Cold start | 10–60 s | 10–60 s | 2–5 s | <100 ms | <100 ms |
| In-process embedding | ❌ | ❌ | JS only | Go only | Java + Go + Node + Python SDKs |
| MCP server mode | ❌ | ❌ | ❌ | ❌ | ✅ polychro serve |
| Well-formedness layer | partial (yamllint) | partial (yamllint) | ❌ | ❌ | ✅ dedicated module |
| JSON Schema for YAML | ❌ | via v8r | ❌ | partial | ✅ Draft 2020-12 native |
| Spectral-format rulesets | via Spectral CLI | via Spectral CLI | ✅ native | ✅ native | ✅ native engine |
| Markdown structural rules | style only | style only | ❌ | ❌ | ✅ anchors, links, frontmatter |
| HTML rules | htmlhint | htmlhint | ❌ | ❌ | ✅ document / fragment / email / embedded-ui |
| Custom rule functions | n/a | n/a | JS | JS + Go | Java SPI + JS + Python + Groovy |
Interoperate, don't contest¶
Polychro doesn't try to win every lane — it interoperates with the ecosystem:
- it speaks the Spectral ruleset format, so existing
given/thenrules run unchanged, - it emits SARIF, so its findings drop straight into CI and code-scanning dashboards, and
- it runs as a GitHub Action, so it slots into the same workflows the meta-linters already orchestrate.
The migration story is "keep your rulesets, swap the engine."
When another tool is the better pick¶
Scoping the wedge honestly:
- Reach for a meta-linter (Super-Linter, MegaLinter) when you want a one-line "lint everything in the repo" sweep across 20+ languages, and the spec-validation slice is a minor part of the job.
- Reach for Vacuum when you lint only OpenAPI, host only Go, and want best-in-class OpenAPI polish (dashboard, auto-fix) — Polychro offers no advantage there.
- Stay on Spectral when you have deep Stoplight/Studio investment and are happy with the status quo.
Polychro is the right call when you need to validate non-OpenAPI specs (capabilities, MCP manifests, CRDs, instruction files), embed validation in-process inside a JVM app, or wire an MCP-callable guardrail into an AI agent loop — and want one tool, one config for well-formedness, schema, rulesets, and Markdown/HTML at once.