What the artifacts evidence

The shape of the answer

53 control rows across five frameworks. Every row carries exactly one label, and there is deliberately no fifth label meaning probably fine.

Read the fourth column first. Twenty rows — more than a third of the map — are covered by nothing at all, and the EU AI Act is the worst of them at seven of nine. That ratio is the reason to trust the other columns. A vendor map with no gaps is not a map, it is a brochure.

The three that are fully documented

All three are NIST SSDF, and none of them is about AI. They are about a toolchain that records what it did.

• PO.3.3 — “Configure tools to generate artifacts of their support of secure software development practices as defined by the organization.” The runner writes the result file itself: exact argv, the tool’s version string, exit code, what triggered it, what it covered and what it did not. The commit trailer is the second artifact, and it survives the tooling — git log --grep answers “which requirement did this commit serve” on a machine that has never heard of Productizer.
• PO.4.1 — “Define criteria for software security checks and track throughout the SDLC.” The whole declaration is one committed file: which checks exist, what triggers each, whether it blocks, what it must have covered, which requirement ids it claims.
• PW.7.1 — “Determine whether code review and/or code analysis should be used…” That determination is the checks stage’s premise — configured rather than baked in — and per-item scoping decides which checks a given change triggers.

What Productizer covers nothing for

This section is the credibility of the rest of the page, so it is not buried at the bottom in small type.

Risk classification of an AI system. Nothing here decides whether a system is high-risk under Article 6, whether it falls in an Annex III area, or whether the Article 6(3) narrow-procedural-task derogation applies. That determination is the provider’s, and Productizer neither performs it nor prompts for it.

Data governance and training-data lineage. No dataset inventory, no provenance records, no quality criteria, no labelling logs, no SBOM. Article 10, SSDF PS.3.2 and the whole ISO 42001 A.7 group are untouched.

Model cards and model documentation. Productizer documents a change and the requirement it served. It documents no model.

Bias, fairness and disparate-impact testing. MEASURE 2.11 is not covered and there is nothing adjacent to it. Anyone reading the acceptance-criteria table as evidence of fairness testing would be reading it wrongly.

Impact assessment, human oversight design, conformity assessment, post-market monitoring, and incident reporting to authorities. Article 73’s fifteen-day, ten-day and two-day clocks have no counterpart here, and neither does Article 14’s human-oversight design or Article 43’s conformity route.

Runtime logging of an AI system’s inferences. Article 12 is not covered. Productizer records decisions about a specification; it does not record what a deployed model did. Anyone who needs Article 12 needs a different instrument.

Access control and operational security. CC6.1, CC7.4 and CC9.2 are not covered. There is no server and no account; access control is your git host’s, and it is stronger than anything this tool could add.

ISO/IEC 42001, stated honestly

The standard is paywalled and its text was not read. The publisher’s pages returned HTTP 403, so not even clause titles came from the source. The nine ISO rows therefore carry titles from a named third-party summary, no obligation text at all, and the label UNVERIFIED throughout. Two third-party listings that were checked agree on 38 controls under nine objectives — but agreement between two paraphrases is not verification of a standard neither of them quotes, and the map says so rather than quietly treating consensus as fact.

This is the row a competitor would have been tempted to fill in. Naming a control you have not read is how a compliance map becomes fiction, and an assessor who asks one follow-up question finds out.

And the question underneath all of it

It is not established that a general-purpose coding agent is a high-risk AI system under Annex III at all. Article 6 and Annex III were read in full and neither settles it. If it is not high-risk, the Chapter III obligations never engage, and most of the EU column on this page is moot. The Commission’s Article 6(5) guidelines would settle it in practice; they were not fetched, and the map records that as unknown rather than guessing.

The separate question of whether any regulator currently requires AI-authorship provenance is answered on the regulatory picture page. The short version: no, and the two 2026 moves that mattered both went the other way.

The verdict. If you need a certification, buy an assessor. If you need someone to hand you pre-written policy so a risk function can tick a box without anyone writing down what the product is supposed to do, other products do that and do it well. What this map is for is narrower and, in the end, more useful: when an assessor asks who agreed this behaviour, when, and what was checked before it shipped, the answer is a file in your repository rather than a reconstruction. Everything else on the list above is somebody else’s job, and the map says which somebody.

Framework text was extracted from primary documents — NIST AI 100-1, SP 800-218 v1.1, SP 800-218A and Regulation (EU) 2024/1689 — and quoted rather than paraphrased, except ISO/IEC 42001, which is paywalled and labelled unverified throughout, and the AICPA criteria, which were read from a third-party copy of TSP section 100 in its red-lined edition. Counts on this page are generated from the map file and will move as it does. Independent analysis; this page is not affiliated with, endorsed by, or accredited by NIST, the European Commission, the AICPA, ISO, or any certification body. Nothing here is legal or audit advice.