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 one file per use case, and puts its enforcement into a normative grammar, a validator, 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: the CI workflow. Theirs run unattended on a push; ours run when someone runs them. 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 — its lifecycle has not yet 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 — but only one of them runs it in CI, and only one of them passes it. 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 ships the same shape: a normative references/format-spec.md and a stdlib-only scripts/validate-spec.py with 53 diagnostic codes, the same ERROR / WARN split, a twenty-fixture --self-test and a --strict mode. Two things keep the row tilted their way. Ours is not wired into CI. And --strict fails on our own spec: R14, R16 and R21 each carry two shall clauses, so each states two obligations under one id and each will be half-tested. It is logged as backlog item B9 and it is not fixed. A grammar its own author cannot pass is worth less than one whose author can.

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. 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 somebody invokes. And behind theirs sits a committed eval corpus of 36 scenarios across 410 scored criteria that is graded at publish time, where our 26 cases have never been scored by a model at all. 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.” And AIUP reaches more surfaces — a Claude Code plugin marketplace, an IntelliJ and VS Code navigator, and Studio on the web. Productizer is Claude Code only.

Where Productizer differs structurally

One living spec, not a document per feature. Productizer keeps a single .claude/productizer/spec.md per product. AIUP keeps one file per use case — and its own “Drift” tooling exists partly to manage the consequence of that split. Neither shape is free: a single file has to be classified against in full on every intent, which is exactly what Productizer does.

Ids are permanent, and this is the exact inverse of AIUP’s rule. 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”, with BR ids scoped per document so the same id recurs across files. Productizer never reuses and never renumbers an id, and a superseded requirement keeps its original text rather than being deleted or rewritten. Neither is automatically correct — gapless positional numbering reads better in a printed use case; permanent ids survive a five-year audit trail. They are different bets about what the document is for.

Every intent is classified, and a contradiction halts. This is the largest single mechanism Productizer has that AIUP does not. The whole AIUP repository contains only two passing mentions of contradiction, and conflict handling is one error-recovery bullet — “Flag the conflict explicitly… ask the user to resolve”. Nothing stops. Productizer classifies each new intent against the whole spec as extend, refine, duplicate or contradict, 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 has no principles layer.

Nothing is hosted, and nothing is closed. Productizer runs locally in your repository — no account, no server, no control plane, no telemetry — and the entire method is in the open repository. Part of AIUP’s normative method is not: format-spec.md names Studio’s closed-source UseCaseSpecificationDocument.java as “the executable reference for the structural rules”, and Studio is a closed, private-beta product. The public Python validator is a hand-maintained mirror of a parser nobody outside the project can read. That is a legitimate way to build a business; it is also a fact worth knowing before adopting the grammar as your own.

What Productizer does not have

Five things, stated plainly. First: the only accuracy figure we have is for the symbolic cross-check that runs alongside the model — 1.00 precision and 0.70 recall on the 21 cases we first wrote — but 0.67 precision and 0.12 recall on a harder 26-case corpus, which tells you the first number described the corpus more than the checker. That sample is small and self-authored, and the end-to-end system’s recall has not been measured at all. The checker’s 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: Productizer’s lifecycle has not yet been exercised end to end through CI. AIUP has that and Productizer does not, and that is the row AIUP clearly wins. Fourth: the eval corpus we do have has never been graded — 26 cases load and both ablation arms configure, but claude plugin eval is early-access gated and no case has been scored by a model, so the number that would actually answer “does the halt work?” does not exist. Fifth: --strict fails on our own spec, on the three requirements that each carry two shall clauses. All five are written down in the repository’s own backlog, which is where we found them.

The verdict. Choose AIUP if you are a requirements engineer or an enterprise team writing stakeholder-facing use cases for a long-lived business application, you want the grammar, the validator and the coverage audit running in CI rather than invoked by hand, an eval corpus that is actually graded, spec changes that 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 file per feature, ids that are never reused or renumbered so the audit trail holds, a constitution above the requirements, and an agent that stops when a new intent contradicts what you already decided — running entirely on your machine with nothing hosted and nothing closed. The two are answering different questions about the same problem, and each is better at its own.

AI Unified Process capabilities are read from its public repository, workflow and reference files as of 2026; 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 118 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.