Framework comparison
This is a scoped comparison, not a certification or a legal assessment of an installation. The technical capabilities and their limitations are in Capabilities and boundaries; follow-up work is in Gaps, owners and acceptance. A control can support several objectives without proving that any framework is fulfilled.
Sources were checked on 7 November 2026. The mappings below are this project's interpretation. Recheck the sources and the deployed system when using them for a customer, procurement exercise or public claim.
Evidence classes in the tables identify the available entry point: S means source/document inspection only; T points to the behavior-test contract and evidence in the owning ADR; O means deployment evidence is still open. T does not claim that the entire external requirement has passed; consult the ADR and the validation record for the tested revision. No row claims a verified deployment. Owners are roles to assign to actual teams.
Digital Public Goods Standard
The DPG Standard has nine indicators, with 9A--9C covering different harms. Its review concerns the core solution, not individual installations. The following evidence prompts apply to nr-llm's own scope:
| Indicator | Control or inspection reference | Evidence class, owner and remaining work |
|---|---|---|
| Application assessment | S/O; project and adopters. Demonstrate public-benefit outcomes; openness alone is insufficient. |
| LICENSE; licence boundary | S/O; maintainers and operator. Review dependencies and the separate model, dataset and service terms. |
| Responsibility register | S/O; project and application owner. Name accountable people and reporting channels for the deployment. |
| Provider abstraction; portability inventory | S/O; integrator. Test substitution and enumerate proprietary dependencies under RAI-09. |
| Capability inventory; evidence record | S/O; maintainers and integrator. Document the actual application, operating procedure and limitations. |
| Analytics;
inspected scope | S/O; integrator. Qualify the non-PII round trip in RAI-09; billing CSV can contain PII. |
| Data-flow inventory; locality evidence | S/O; operator. Assess purpose, actual recipients, contracts and applicable obligations. |
| Provider interface design; claim-maintenance rule | S/O; maintainers and integrator. Link versioned checks and validate the deployed integration; no whole-standard pass is claimed. |
| 9A. Privacy and security | Run; provider privacy;
retention procedure | T/O; maintainers and operator. Verify configured permissions, recipients and deletion across copies under RAI-01/03/06. |
| 9B. Inappropriate or illegal content | Approval controls; application test matrix | S/O; application team. Implement suitable moderation and incident handling; approval alone does not assess content legality. |
| 9C. Protection from harassment | CODE_;
complaint ownership | S/O; community and application owners. Test reporting and response procedures for application users as well as contributors. |
The practical DPG guide clarifies the non-PII scope of indicator 6. This is not a reason to export credentials or bypass access restrictions.
The TYPO3 registry entry lists only the TYPO3 core repository as assessed. It explicitly excludes unlisted repositories, add-ons and features. Its recognition therefore does not establish recognition of nr-llm or a customer installation.
ALTAI
The European Commission's ALTAI self-assessment organizes assessment into seven areas. Use the complete checklist for a specific application; the following is a starting map, not its completion.
| Area | Control or inspection reference | Evidence class, owner and remaining work |
|---|---|---|
| Human agency and oversight | Permissions; approval boundary | S/O; integrator and operator. Reviewers can understand, refuse, correct and escalate actions; exercise the real workflow. |
| Technical robustness and safety | Fallback privacy tests; egress qualification | T/O; maintainers and operator. Exercise deployed failure, shutdown and recovery procedures beyond the tested privacy scope. |
| Privacy and data governance | Privacy; Purge;
RAI-03 | S/O; operator. Verify actual recipients, lawful handling, schedules and deletion of all in-scope copies. |
| Transparency | After;
source checks;
publication checks | S/O; application and editorial teams. Test actual notices, source support, uncertainty and user understanding. |
| Diversity, non-discrimination and fairness | Golden;
application evaluation | S/O; application team and domain reviewers. Test relevant groups, languages and accessibility with affected-person feedback. |
| Environmental and societal well-being | Usage reporting; resource assessment | S/O; operator and application team. Measure resource impact, benefits and harms against suitable alternatives. |
| Accountability | Evidence ownership; assessment record | S/O; project and deployment owners. Name people, exercise complaint/incident handling, and review outcomes. |
A successful test of an approval mechanism does not demonstrate effective human oversight. A benchmark score does not demonstrate fairness across populations. Budget, token and cost records do not measure energy, water or emissions.
NIST AI RMF and Generative AI Profile
This comparison uses AI RMF 1.0 and NIST AI 600-1, July 2024. The NIST overview describes voluntary use and ongoing revision work. Pin the edition in an assessment rather than silently adopting later changes.
The action IDs below come from the Generative AI Profile. The evidence column is this project's proposed application of a selected subset.
| Action | Action theme and evidence entry point | Evidence class, owner and remaining work |
|---|---|---|
| GV-1.3-002 | Release thresholds; evaluation report | S/O; application owner. Record acceptance criteria and decision. |
| GV-1.3-007 | Stop deployment; evaluation report | S/O; operator. Exercise shutdown and assign its decision owner. |
| GV-1.5-001 | Review ownership; claims rule | S/O; project and operator. Name provenance/incident reviewers. |
| GV-1.5-003 | Evidence retention; RAI-03 | S/O; operator. Apply a privacy-aware evaluation-retention policy. |
| GV-6.2-006 | Fallback risks; provider-attempt privacy | T/O; maintainers and operator. Test the enabled fallback chain and actual recipients under RAI-07. |
| MP-1.1-001 | Intended purpose; assessment record | S/O; application team. Describe purpose, data sources and limits. |
| MP-1.1-003 | Measurement plan; RAI-05 | S/O; application team. Run risk-linked cases and human review. |
| MS-2.3-002 | Capability validation; benchmark identity | T/O; maintainers and evaluators. Validate application claims; identity tests alone do not establish model quality. |
| MS-2.5-001 | Limit claims; evaluation limits | S/O; evaluators. Report sample limits and uncertainty. |
| MS-2.5-003 | Verify citations; source procedure | S/O; application team. Test claim support and ongoing source drift. |
| MS-2.7-007 | Adversarial tests; egress procedure | S/O; security and application teams. Exercise injection/abuse scenarios across every enabled boundary. |
| MS-2.11-001 | Bias benchmarks; test matrix | S/O; domain evaluators. Run relevant cases and document limits. |
| MS-2.12-003 | Environmental impact; resource limits | S/O; operator and provider. Supply energy/water evidence and method. |
| MG-4.1-002 | Operational monitoring; review procedure | S/O; operator. Record quality/incident review after deployment. |
Benchmark revision and generator provenance are separate evidence. Record evaluator versions, grader prompts/models, thresholds, settings and sample sizes as well. A content fingerprint does not freeze an external model or prove that the benchmark measures the intended outcome.
EU transparency requirements
Legal duties are separate from voluntary ethical assessment. Evaluate the actual system, role and use case against Article 50 and the Commission's scope guidelines.
| Provision | Integration question |
|---|---|
| Article 50(1) | Does a person interacting directly with the system receive the required AI notice, considering the applicable exceptions? |
| Article 50(2) | Are relevant outputs marked in a machine-readable and detectable way? A private database flag alone does not demonstrate this. |
| Article 50(3) | If applicable, are people informed about emotion-recognition or biometric-categorisation systems? |
| Article 50(4) | Does publication require deepfake or public-interest-text disclosure? Assess the respective exceptions separately. |
| Article 50(5) | Is the information clear, distinguishable and accessible by the first interaction or exposure? |
Human review or editorial control, together with editorial responsibility, is relevant to the text-publication exception in paragraph 4. It is not a general exemption from every transparency duty.
Article 50 generally applies from 2 August 2026. The consolidated AI Act, Article 111(4) provides until 2 December 2026 for Article 50(2) compliance by providers of the specified synthetic-content systems placed on the market before 2 August 2026. This transition does not postpone all of Article 50.
The Code of Practice on Transparency of AI-generated Content was finalized on 10 June 2026. The Commission describes it as an adequate voluntary compliance tool for its marking and labelling scope. It does not replace the Act, constitute a general ethics certificate, or automatically make users of nr-llm signatories. It is distinct from the GPAI model code.
Additional references and software freedom
The TYPO3 Open Web Manifesto provides a values basis for independence, participation and privacy. Provider choice and non-AI access paths are practical application choices to assess against those values.
The UNESCO Ethical Impact Assessment helps assess individual systems before and during use, including engagement with affected stakeholders. The OECD AI Principles provide a broader reference. Neither is a product badge supplied by this comparison.
ISO/IEC 42001:2023 addresses an organization's AI management system. nr-llm controls can contribute evidence; they cannot establish organizational certification.
The GPL licence remains unchanged. Development commitments, recommended practices and supported-use boundaries add no licence restrictions. The Open Source Definition, notably sections 3, 5 and 6, protects modification and rejects discrimination by person, group or field of use. An unevaluated use is not thereby prohibited under the software licence, and a runtime safeguard is not a prohibition on changing the software.