Productizer vs AI Unified Process

The two methods agree that an AI-built product needs a written specification the agent is accountable to, and that the lifecycle should be staged rather than ad hoc. They diverge on the shape of the artefact and on what is machine-enforced. Productizer keeps one living spec with permanent ids and stops the run when a new intent contradicts what is already written. AIUP keeps a set of linked artifacts — a requirements catalogue, a use-case diagram, one file per use case, test cases, an entity model, BPMN processes and a glossary — and puts its enforcement into a normative grammar, a validator, a cross-file linter, a coverage auditor and a CI workflow that produces pull requests. As of v4.2.0 the second half of that sentence is no longer only theirs — Productizer ships a grammar, a validator and a spec-derived coverage denominator too. What remains theirs is the last clause: a CI workflow that produces pull requests. Both now run their checks on every push; only theirs puts an agent in CI, and only theirs opens a PR. Each still has invariants the other does not.

Where AIUP is genuinely ahead

The CI lifecycle is the clearest one, and it is not close. AIUP ships .github/workflows/aiup-generate.yml as a versioned reusable workflow: it diffs the spec against the default branch, fences that diff into the prompt, runs a skill through anthropics/claude-code-action@v1, advances the status, and opens a pull request carrying a correlation id. Productizer has nothing equivalent that has ever run — its own 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 pull request. Since v4.67 it ships an experimental, copyable workflow that would do the dispatch-to-draft-PR step, adapted from AIUP’s and credited to it, but that workflow has never run on a real GitHub runner and is labelled do not adopt yet, so the lifecycle has still not been exercised end to end through CI. If your requirement is “a spec change lands as a reviewable PR without a human driving the agent,” AIUP does that today and Productizer does not.

The reasoning behind passing the diff rather than the whole spec is worth reading in their own words, because it is a failure mode most spec-driven tooling never notices: “A specification edit that only removes a requirement is invisible to the skill: the remaining text is already satisfied by the existing code, so the run finds nothing to do and the dropped behaviour survives.” That is a careful observation about deletion, and it applies with more force to Productizer than to AIUP, because our supersession rule keeps the original sentence in place on purpose. v4.2.0 adopted it: scripts/spec-diff.sh fences the spec and constitution diff into the Build prompt, and its own header says it is adapted from the AI Unified Process workflow. That is now an even row rather than an AIUP win — with one asymmetry left, which is that theirs is invoked by a CI workflow and ours by the stage.

Format enforcement is executable on both sides now, and both run it in CI — but only one of them runs it strict. AIUP’s references/format-spec.md is normative and scripts/validate_use_case.py — stdlib-only, so it runs anywhere — enforces it with two severities: ERROR for unparseable, WARN for parses-but-violates-the-contract. CI runs it in both --self-test and --strict modes. Productizer v4.2.0 shipped the same shape: a normative references/format-spec.md and a stdlib-only scripts/validate-spec.py, with 53 diagnostic codes then and 65 now, the same ERROR / WARN split, a --self-test that now covers 42 fixtures, and a --strict mode. CI runs the self-test and the validator on every push and PR. --strict used to fail on our own spec, because R14, R16 and R21 each carried two shall clauses; backlog item B9 split them on 2026-08-29, and --strict now passes with 0 errors and 0 warnings. One thing keeps the row tilted their way: our CI runs the validator without --strict, so nothing on a push holds us to the bar we currently clear.

The coverage audit is mechanically derived, and the definitions are strict — and Productizer took the definitions. A dedicated AIUP agent restricted to read-only tools flattens each spec into enumerable units and gives every one a verdict of Covered, Partial, Missing or n a — where n a requires a stated reason, because “‘Hard to test’ is not n/a”, and where “a disabled, skipped, or todo test covers nothing.” scripts/run-checks.sh now derives its denominator from the spec on the same terms: every active requirement gets a row, the same four verdicts, an n a that needs a reason with the same exclusion, the same rule about disabled and skipped checks, and a Missing row that refuses. So a check can no longer shrink its own scope and pass. Both now run on every push. What AIUP still has that we do not is the part that runs it: theirs is an agent in a workflow, ours is a script, and our mapping from requirement to check is declared rather than proven by running the tests. And behind theirs sits a committed eval corpus of 40 scenarios across 448 scored criteria that is graded at publish time. Ours is graded only in one-off runs, and when it was, the plugin did no better than the bare model. That last clause is the real gap on this row.

Status advance is guarded better than ours. AIUP’s advance is rank-gated and forward-only, and it refuses to move on a run that produced nothing: “A run that produced nothing has no result to take over.” On top of that, a use case carries a human approval status — Draft, Reviewed, Approved — and the implement skills refuse one that is not yet Approved. And AIUP reaches more surfaces — a Claude Code plugin marketplace, IntelliJ and VS Code navigators, and Studio on the web. Productizer is Claude Code only.

Traceability reaches further, and it goes all the way to code. AIUP’s specification is a set of linked artifacts, and spec_lint.py checks the links: a requirement no use case covers (FR_UNCOVERED), a citation that points nowhere (DANGLING_REF), a use case missing from the diagram (NOT_IN_DIAGRAM), a process step mapped to nothing (BPMN_UNMAPPED), a term the glossary says to avoid (GLOSSARY_AVOIDED_TERM), and weak words. Past the specification, it ships stack-specific implement and test skills for Vaadin / jOOQ, Angular / JPA, Blazor / .NET and NestJS / Next.js, and a reverse-engineer skill for existing code. Productizer’s Build stage is stack-agnostic and ships no implementation skills at all.

Where Productizer differs structurally

One living spec, not a set of linked artifacts. Productizer keeps every requirement in a single .claude/productizer/spec.md per product. AIUP spreads its specification across a requirements catalogue, a use-case diagram, one file per use case, test cases, an entity model, BPMN processes and a glossary, linked by id. Neither shape is free. A single file has to be classified against in full on every intent, which is exactly what Productizer does. A linked set describes more of the system, and it needs cross-file checks to stay consistent, which is what AIUP’s linter is for.

Ids are permanent at every level. AIUP’s top-level ids are stable too: UC, TC, BP, FR, NFR and C ids are not reused, and its linter refuses duplicates. The difference is inside a use case. AIUP’s format-spec.md states that step, flow (A1…) and rule (BR-001…) numbers are positional and that “Studio renumbers them gaplessly on save”. BR ids are scoped to their use case and cited qualified, as UC-005 BR-002, and the linter checks those citations. Productizer has no positional level: every requirement id is permanent, and a superseded requirement keeps its original text. AIUP retires items by status — Obsolete, Rejected, Deferred — rather than deleting them. Neither is automatically correct: gapless numbering reads better in a printed use case, while a permanent id on every statement survives a five-year audit trail.

Contradiction is caught before a change is written, and it halts. AIUP checks for contradictions too. /spec-review runs a review checklist whose first section is Contradictions over the whole specification set, next to a deterministic linter whose ERROR findings block. Its semantic findings, which is where a contradiction lands, are advisory by design. Productizer classifies each new intent against the whole spec as extend, refine, duplicate or contradict before it is written, and a contradiction halts the work until a human rules on it. Above requirements sits a constitution of P-numbered principles, checked before classification. AIUP’s constraints and NFRs are catalogue rows linked from the use cases they apply to, rather than a layer checked first. The difference is when the check runs and how hard it stops: we stop at intake, and they review the set and leave the semantic call to a person. That halt is a design claim. In the graded runs, the halt decision was right no more often with the plugin than without it.

Nothing is hosted. Productizer runs locally in your repository — no account, no server, no control plane, no telemetry — and the entire method is in the open repository. So is AIUP’s. Its format-spec.md is “the single normative definition” of the format, the open validator checks both the structural and the content rules, and Studio’s parser is named as the executable reference for the structural ones. AIUP Studio is a separate hosted product in private beta by invitation, and the skills work without it.

What Productizer does not have

Five things, stated plainly. First: the graded evals show no benefit over the bare model. On a pre-registered 14-case hard corpus, 840 graded runs on 2026-09-26, 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. The skill fired in 48 of 280 plugin runs, 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 (5/20 → 0/20); it is one of 14 uncorrected tests, so read it as descriptive. The earlier 26-case corpus is no stronger: 16/16 recall with the plugin against 13/16 without on 2026-08-29, then 30/42 each, p = 1.0, when re-run over every case the bare model had ever failed. Grading is not run at publish time; it has only been done in one-off runs. The symbolic cross-check that runs alongside the model 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. Its passing verdict is deliberately worded “no incompatibility inside the decidable fragment” rather than “consistent”, because it is a non-decision and not a clearance. Second: Productizer is Claude Code only, where AIUP ships for more surfaces. Third: no agent runs in CI, and nothing opens a PR. CI runs the validator, the solver gates and the declared checks on every push and PR, but the intake-to-build lifecycle has not been exercised end to end there. AIUP has that and Productizer does not, and that is the row AIUP clearly wins. Fourth: the halt rarely asks for the ruling. In the graded runs the model halts but seldom asks a person to rule: 06-ruling-requested scored 0.22 with the plugin against 0.13 bare. And the 14-case mechanism corpus is committed but has never been run. Fifth: nothing past the specification — no implementation or test skills for any stack, and no traceability across artifacts, because there is only one. The first four are in the repository’s own backlog and eval records, which is where we found them; the fifth was pointed out to us.

The verdict. Choose AIUP if your team is building a long-lived business application and wants a linked set of specification artifacts with traceability checked across them, implementation and test skills for your stack, the validator run --strict in CI, an eval corpus graded at publish time, an agent in CI so that spec changes arrive as pull requests without a human driving the agent, and support across IntelliJ, VS Code and Claude Code. Choose Productizer if you want one living spec instead of a set of linked files, ids that are permanent at every level so the audit trail holds, a constitution above the requirements, and an agent designed to stop at intake when a new intent contradicts what you already decided — knowing that the graded runs have not shown it doing that better than the bare model — running entirely on your machine with nothing hosted. The two are answering different questions about the same problem, and each is better at its own.

Corrected 2026-10-10. Simon Martinelli, the author of AIUP, pointed out errors in an earlier version of this page, and he was right. Some of them were ours when we wrote it. We called AIUP’s ids positional without saying that only the step, flow and rule numbers inside a use case are. We said retired requirements had no equivalent, when AIUP retires them by status. We described the artifact set as one file per use case, and we left out the implementation, test and reverse-engineer skills. We guessed at why the drift tooling exists, named an audience AIUP does not name, and called the public validator a mirror of a hidden parser, which format-spec.md does not say. Others went stale: /spec-review, the cross-file linter and its traceability codes, BPMN and the glossary all shipped after our previous edit on 2026-09-24, and the page carried no date that would have shown it. It names its source commit now.

AI Unified Process capabilities are read from its public repository (AI-Unified-Process/marketplace at commit d25bf91, 2026-10-05), workflow and reference files, and from its own site; every quoted sentence is verbatim from that material. Productizer marks reflect shipped capability. Neither project has independent third-party validation that we could find — that is equally true of both, and the 142 stars on the AIUP marketplace are interest, not proof. AI Unified Process, AIUP and AIUP Studio are the work of Simon Martinelli; this page is an independent architecture-level comparison and is not affiliated with, endorsed by, or partnered with that project. Both products evolve — verify specifics against current documentation.