Skip to content
// productizer compliance coverage

What the artifacts evidence

Productizer produces a paper trail as a by-product of the work: a living spec with permanent requirement ids, a classification record for every intent, a D-numbered ruling whenever a human resolved a contradiction, declared checks that record what they examined, and waivers that keep a failure visible while naming who accepted it. Several control frameworks ask for artifacts of that shape. This page states which ones, control by control — and, at greater length, which ones it produces nothing for.

One word does the load-bearing work on this page, and it is not “compliant”. The verb throughout is evidences. Productizer does not satisfy a control, does not make anything compliant, and certifies nothing — certification is an assessor’s word and no assessor has looked at this. A tool that tells you it makes you compliant with a standard it has not read is selling you a feeling.

The full map lives in the repository at references/compliance-map.md, with a machine-readable copy at templates/compliance-map.yaml. It is descriptive: nothing reads it, and no check is driven by it.

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.

FrameworkRowsDocumentedPartialNot coveredUnverified
NIST SSDF — SP 800-218 v1.113373—
NIST AI RMF 1.012066—
SOC 2 — AICPA TSP section 10010064—
EU AI Act — Reg (EU) 2024/16899027—
ISO/IEC 42001:202390009
Total53321209

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.

Frequently asked questions

Does Productizer make my project compliant with the EU AI Act or ISO 42001?

No, and the map says so in the strongest terms. Productizer evidences control obligations; it does not satisfy them and it certifies nothing — certification is an auditor's word. On the EU AI Act specifically the coverage is deliberately weak: of the nine articles mapped, seven are marked NOT COVERED, including Article 9 risk management, Article 10 data governance, Article 12 record-keeping, Article 14 human oversight, Article 43 conformity assessment and Article 73 incident reporting. The two partial rows concern technical documentation under Article 11 and Annex IV, and quality-management obligations under Article 17.

What does the compliance map actually cover?

53 control rows across five frameworks: NIST AI RMF 1.0 (12 rows), NIST SSDF SP 800-218 v1.1 (13), the EU AI Act (9), SOC 2 via AICPA TSP section 100 (10), and ISO/IEC 42001 (9). Three rows are DOCUMENTED — all of them NIST SSDF: PO.3.3 on generating artifacts of tool support, PO.4.1 on defining criteria for security checks, and PW.7.1 on determining whether code review or analysis is used. 21 rows are PARTIAL, where an artifact covers part of the obligation and the row names which part is left. 20 rows are NOT COVERED, meaning Productizer produces nothing for them.

Why are the ISO 42001 rows marked unverified?

Because ISO/IEC 42001 is paywalled and its text was not read. The publisher's own pages returned HTTP 403, so not even clause titles were obtainable from the source. The nine ISO rows therefore carry control titles taken from a named third-party summary, with no obligation text at all, and are labelled 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.

Is a coding agent even a high-risk AI system?

That is unresolved, and it is the question the whole compliance argument rests on. Article 6 and Annex III of Regulation (EU) 2024/1689 were read in full and neither settles it; Article 6(3) carries a derogation for systems performing a narrow procedural task. If a general-purpose coding agent is not high-risk under Annex III, the Chapter III obligations — including Article 12 record-keeping — never engage at all. The Commission guidelines under Article 6(5) would settle it in practice and were not fetched.

glick.run