Productizer vs the field
One page, every comparison. Productizer is an open-source Claude Code plugin that keeps one living spec per product in your own repository — permanent requirement ids that are never reused or renumbered, a superseded requirement that keeps its original text, every new intent classified against the whole spec as extend / refine / duplicate / contradict, and a contradiction that halts the work until a human rules on it. Below are the ten structural properties that separate it from the six tools people evaluate it beside. Structural, deliberately: these are architecture decisions that do not move with the next release, not feature counts that go stale in a month. Open any column for the full per-competitor page.
| Productizer | AI Unified Process | Entire | 8090 | Lightsprint | Gas City | Credo AI | |
|---|---|---|---|---|---|---|---|
| One living spec per product, not per feature | ✓ | ✗linked artifacts, one file per use case | ✗ | ✗blueprints per feature | ✗ | ✗a work graph, not a spec | —a runtime policy, not a spec |
| Permanent requirement ids, never renumbered | ✓ | ◐top-level ids stable; steps and rules positional | ✗ | ✓ids preserved once assigned | ✗ | ✗content-addressed ids, not ordered | —requirement ids only in another product |
| Superseded requirement keeps its original text | ✓ | ✓retired by status, not deleted | ✗ | — | ✗ | ✓supersede keeps the text | —supersession not found |
| Every intent classified against the whole spec | ✓ | ✗reviews the spec set after writing | ✗ | ✗ | ✗ | ✗ | —classifies actions, not intents |
| A contradiction halts the work | ✓ | ◐lint errors block; semantic review advisory | ✗ | ✗ | ✗ | ✗rules audit reports, never blocks | —blocks violations, not contradictions |
| Principles layer above the requirements | ✓ | ✗constraints are catalogue rows | ✗ | ✗ | ✗ | ✗ | —three policy postures, not principles |
| Artifacts live in your own repo | ✓ | ✓files; Studio optional | ◐checkpoints in-repo, platform hosted | ✗hosted | ✗hosted workspace | ◐in your repo, over a database | ◐hooks in-repo, telemetry hosted |
| Nothing native to install | ✓ | ✓plugin; IDE plugin optional | ✗Go CLI + control-plane login | ✗account + GitHub App | ✗account + CLI | ✗a CLI, a daemon and Dolt | ✓hooks and skills, no gateway |
| Open source end to end | ✓ | ◐Apache-2.0 skills; hosted Studio by invitation | ◐MIT CLI, closed platform | ✗engine closed | ✗main repo private | ✓MIT both repos, no entitlement check | ✗gated research preview |
| Free | ✓ | ◐free skills; Studio pricing at launch | —no public pricing | ✗enterprise | —no public pricing | ✓free; Team Server is not | —unpublished; free in preview |
| Learn more ↓ | The product → | Full page → | Full page → | Full page → | Full page → | Full page → | Full page → |
— = unconfirmed, not necessarily absent: it marks a property the vendor does not clearly document. Every cell is read from the vendor’s own public material and matches that vendor’s dedicated comparison page.
Where each of them is ahead of us
A matrix where one column is ✓ on every row is a rigged matrix, and you would be right to distrust it. The table above is narrow on purpose — it asks only how a spec is structured, which is the one question Productizer was built to answer differently. Widen the question and each of these six is ahead of us, in named, specific places. Here they are.
| Competitor | What it does better than Productizer |
|---|---|
| AI Unified Process | A working end-to-end CI lifecycle that opens real pull requests — the cleanest win on this page, and one we still have no answer to. Both sides now run a format validator and a coverage check in CI on every push, but theirs has an agent in CI that opens a PR, and ours has no agent and opens nothing; their validator also runs --strict in CI, where ours runs without it. Traceability checked across a linked set of artifacts — requirements, use cases, diagram, test cases, BPMN processes and a glossary — and stack-specific implementation and test skills, where we stop at the spec. An eval corpus of 40 scenarios across 448 scored criteria run at publish time, where ours is graded only in one-off runs, and graded, shows no benefit over the bare model. Broader editor and IDE reach. |
| Entire | Line-level provenance — entire blame and entire why map a live line of code back to the prompt that wrote it. Ours is a Productizer-Req: commit trailer, which is provenance at the commit, not at the line, and it is a claim rather than evidence. A nine-layer redaction pipeline of roughly 2,700 lines of tested Go, where we redact commit text on the dashboard and run a secret-scan check, and nothing redacts agent sessions. Support for eight coding agents against our one. Scored merge gates that re-run on every push: we ship the runner format, a script that executes a runner and a scorer, all run by hand, with no push trigger; what re-runs on every push is our declared-check suite. |
| 8090 | A delegated review agent working across six fixed dimensions. Test-to-requirement coverage traceability that is enforced inside their platform. Ours maps declared checks to requirements and CI refuses on any uncovered requirement, but the mapping is declared, not proven by running the tests, and the commit-level scan for COV_ ids cannot tell a test from a comment. A real three-layer evaluation framework with an F2-weighted score, a golden dataset and quarterly recalibration — run routinely, where ours has been graded only in one-off runs and the result was null. |
| Lightsprint | A gate anchored to observed GitHub evidence rather than to declarations — still the honest distinction, because ours is anchored to declarations, with signals beside it — PR and CI status read from GitHub through gh when reachable, collected by a script on the local machine. Role-scoped approval that binds a non-engineer, where our hooks bind whoever is at the terminal. A published audit of their own agents’ error rate. Splitting judgment from evidence and keying it to an evidence hash is no longer a row they win alone: we now do both. |
| Credo AI | Runtime enforcement across the whole agent loop, where we gate a few points at the end of the work — deploy, publish, and publishing a view that can rewrite itself. Four outcomes — “allow, block, escalate, or advise” — at every point in that loop, where our gates and checks block, ask a person or advise only at those few. Pre-written policy at three postures, “aligned to EU AI Act, NIST RMF, ISO 42001, and sector frameworks”, so a risk function gets value on day one, where we ship default security checks and example principles but no policy aligned to any regulatory framework, and an empty spec governs nothing. An OpenTelemetry evidence trail into a hosted backend, where we have no telemetry trail — a gate decision log and committed classification records, nothing more. And a company with a control library and SOC 2 Type II behind it, against one person’s free project. The fair caveat is status: Agent Governor is a Research Preview. |
| Gas City | Cross-session memory that actually ships — a hook restores context so agents resume instead of reconstructing, where we have a committed learnings store and a one-line status at session start, and nothing that restores an agent’s working context. Hook installers for fourteen agent tools against our one. Coordination machinery for agents that genuinely contend: content-addressed ids so parallel branches never collide, and leases so a dead agent’s claim is reclaimable — where we prevent collision by partitioning work along files and have nothing to fall back on when a clean partition is not available. And a machine-readable output contract of 127 per-command schemas, enforced by a test that fails on any schema lacking a success discriminator, with every exemption named in source. |
What is true about Productizer, stated plainly
Productizer is Claude Code only. There is no IntelliJ plugin, no VS Code extension, no support for the seven other coding agents Entire handles. Its lifecycle has not yet been exercised end to end through CI — CI runs the validator, the solver gates and the declared checks on every push and PR, but no agent runs there and nothing opens a PR; the stages, hooks and gates run under a human driving the agent, and the unattended path is unproven. Runners run by hand: templates/runners/*.json defines the contract for a scored judgment, a script executes one and the scorer beside it scores it, but neither runs on a push. The graded evals show no benefit over the bare model. On a pre-registered 14-case hard corpus, 840 graded runs, the halt decision was correct in 235 of 280 runs with the plugin against 239 of 280 bare, Fisher p = 0.725: no effect, and the point estimate favours bare. Eleven of the fourteen cases were at the bare model’s ceiling, and reference files were read 0 times in 840 runs, so the mechanism was never exercised. One case, H11, reached p = 0.0471 with the plugin worse, but it is one of 14 uncorrected tests, so it is descriptive only. Grading is not run at publish time; it has only been done in one-off runs. The symbolic cross-check that runs beside the model classifier scores 1.00 precision and 0.94 recall on its 33-case self-test and 1.00 / 0.90 on the 26-case corpus — 9 caught, 1 missed, 6 escalated, 0 false halts — but it was tuned on that corpus, so the figure is in-sample, and it describes the symbolic checker alone. Nothing here should be read as “Productizer has 0.90 recall”. It is a free one-person open-source project, not a supported platform: no SLA, no support contract, no organisation behind it.
No independent third party has validated any of this — not our marks and not theirs. Every cell above is read from public material and from our own repository, by us. Where a vendor publishes its own numbers we have repeated them without re-testing them. Both sides evolve; verify specifics against current documentation before you decide anything.
Nothing on this page implies that AI Unified Process, Entire, 8090, Lightsprint, Gas City or Credo AI endorses, partners with, or is affiliated with Productizer or glick.run. Each name is the trademark of its owner and is used here only to identify the product being compared.