Every pillar, every control, every plugin, every pipeline step — with inputs, outputs, and worked examples. Built from the full architecture conversation.
One sentence each — before anything else.
AIGAP = The full medical system that checks whether an AI is ethical and safe before it reaches real users.
CER = The first doctor who reads your code and says: "Here's what you've done right, here's what's missing, here's what you need to build — before we can certify this."
The 78 rules = The clinical checklist the doctor uses. Grouped into 11 categories called Pillars. The doctor observes — they never certify.
4 tools that together govern whether an AI system is ethical. Aligned to EU AI Act, NIST AI RMF, ISO 42001.
Scans your GitHub repo or ZIP against 78 ethical rules. Pre-assurance only. Tells you what to build before the formal review.
Developers building AI systems. Run the CER repeatedly to close gaps — before the human AI Design Reviewer phase begins.
"Certified", "Compliant", "Legally required", "Passed", "Failed." Only: pass · partial · missing · not triggered · not evaluable.
AIGAP has 4 tools in sequence. The CER is Tool 2 — the first thing a developer actively works with.
Dataset Ethics Analyzer. Checks training data — fairness, licensing, provenance.
Code Ethics Reviewer. Scans code against 78 rules. Produces findings and handoff packages.
AI Design Reviewer. Human reviewer uses CER handoff package to assess design intent.
AI Certifier. Final stamp. Issues PASS / CONDITIONAL / FAIL using CER pre-registered evidence.
The developer fills this form before the scan. It sits just outside the CER boundary — but feeds directly into every key step.
Your passport is not part of airport security — but security reads it at every checkpoint. The intake profile is the CER's passport. The developer fills it in once. The CER uses it at S1, S3, S4, and S8 to know what to look for, what rules apply, and whether the code is honest about what was declared.
Is the intake part of the CER? It sits just outside the CER boundary — filled in a separate AIGAP registration step. But the CER ingests the resulting project profile as a structured data object at S1 and reads it throughout the scan.
A tier tells the CER where to look for evidence of a rule. Every one of the 78 controls has exactly one tier.
Evidence is directly in source files, config files, test files, lockfiles, or prompt templates. CER plugins scan automatically.
Evidence lives in a document file — policy doc, model card, risk register, markdown. Plugin finds the file, then LLM reads the content to check quality.
Evidence is in a human governance decision — signed approvals, stakeholder reviews. Cannot be detected in code. CER sends a supplement form.
T3 asks for a file path — not a yes/no. Developer types governance/risk_register.xlsx. CER checks if that file exists in the manifest. File found → PARTIAL. File not found → MISSING. Not submitted at all → NOT_EVALUABLE + escalation_required = true.
Not all 15 T3 controls fire for every project. T3 controls go through the same applicability filter as T1/T2 at S4. Only T3 controls that pass the applicability check get a supplement form. T3 controls that fail the check → NOT_TRIGGERED → no supplement sent.
Every step shown with what goes in, what comes out, and why it exists. S9 is the only step with an LLM. Everything else is deterministic.
Not all 78 controls fire automatically. S3 detects AI type. S4 filters using the project profile. Controls that don't apply → NOT_TRIGGERED (removed entirely). T3 controls → supplement queue. Only active T1/T2 controls enter the plugin queue.
Developer submits. Registry version verified. Hard stop if mismatch.
Developer provides a GitHub URL, ZIP file, or pasted snippets. CER immediately checks that the registry version in the project profile matches the one locked when the project was registered. A version mismatch is a hard stop — not a warning. The rulebook must be identical to when the project was first scanned.
Full manifest built. Secrets masked before anything is stored. Workspace fingerprinted.
CER clones or unzips the repository and builds a complete file manifest — every file path with its SHA-256 fingerprint. Secret masking runs immediately — any detected API key or password is replaced with [REDACTED] before being stored anywhere. Secret values are never held. Only "secret detected at line X" is logged. Finally the entire codebase is fingerprinted as the workspace_hash for the sealed audit record at S11.
Code import patterns read. gen_triggered and rel_triggered flags set. Conflicts noted as escalation hints.
S3 reads import statements and file patterns across all source files to understand what kind of AI system this is. Code import patterns are specific lines — like import openai or from transformers import AutoModel — that reveal which libraries or APIs the project depends on. The CER reads these as text only — it never executes the imports. The detected flags then control which of the 78 rules activate at S4.
One universal applicability filter. T3 → supplement queue. Active T1/T2 → plugin queue. NOT_TRIGGERED → gone.
This is the critical filter step. S4 applies one universal applicability check to all 78 controls. Tier is only used to decide what happens next — not whether a control applies. Controls that fail the applicability rule are removed entirely regardless of tier. Only T3 controls that pass the filter get supplement forms.
31 plugins. All simultaneously. 30-second timeout each. Never execute code. Produce RawFindings only — never PASS/FAIL.
Every active T1/T2 control's registered plugins run simultaneously — not sequentially. Each plugin reads files as data only — like reading a book, not running a program. Plugins never execute Python, never run notebooks, never run shell commands. A single plugin can be registered to multiple controls and produces one RawFinding per control it covers.
Plugin = witness. RawFinding = sworn statement. Evidence Mapper = judge. The witness only reports facts. "I saw this, I did not see that." The judge at S7 decides the verdict — never the witness.
Registry anchor mapping lookup. Qualified RawFindings tagged with overlay_relevance + anchoring_primary. Unqualified findings pass through unchanged.
S6 is a routing and tagging step — no new scans run. It reads every RawFinding from S5, looks up the GEN/REL anchor mapping table in the registry, and tags findings that belong to GEN or REL overlay controls. "Anchored by" means the GEN/REL control is bolted onto a PRIMARY control — it cannot float freely. The GEN/REL control is the dependent one. The PRIMARY is the foundation. The tag does not change the CER's question — it is a signal to the Reviewer that this PRIMARY result also carries GEN/REL significance.
TRAN-08's question does NOT change when GEN-04 is anchored. The CER always asks the same question — "does watermarking exist?" The GEN-04 tag is a sticky note for the Reviewer: "When you look at this TRAN-08 result, remember GEN-04 also needs your attention." The Reviewer derives GEN/REL status — the CER never assigns it directly.
100% deterministic. No AI. Same input → same output. Always. Strict decision tree applied per control.
The most important step. The Evidence Mapper reads every tagged RawFinding, compares it against what the canonical registry says is required at this assurance level, and assigns a status. The LLM in S9 can only explain this decision — never change it.
3 checks. escalation_hints[] from all 3. escalation_required = true only from Check 2 and Check 3.
S8 is a comparison engine. It takes the project profile (what was declared) and everything detected (code signals, statuses, T3 supplement responses) and checks if they agree. It produces hints and flags — but does not change any statuses, re-run plugins, or cancel the scan.
Compares every intake field against what was detected in code. Intake said no GenAI but import openai found? Hint raised. Scan can still proceed — developer should correct intake.
Checks override rules: rights-affecting endpoint detected → minimum Capstone. Minor users detected → minimum Capstone. Regulated sector → minimum Industrial. Level can only go up.
All active T3 controls must have their supplement forms submitted. Missing submission → NOT_EVALUABLE + blocker. Submitted but file not found → MISSING (not a blocker, but a finding).
escalation_hints[] comes from all 3 checks. escalation_required = true comes only from Check 2 and Check 3. Check 1 is informational — "you should fix this." Checks 2 and 3 are hard blockers — "you cannot move forward until you fix this."
The only AI step. 3 prompts. Temperature = 0. LLM input built by CER automatically. LLM never changes a status.
By S8, every control has a status. But "PRIV-01 PARTIAL" means nothing to a developer who doesn't know the system. S9 fixes that — it writes plain English explanations, remediation steps, and classifies ambiguous documents. The CER builds the LLM input automatically from S2/S3/S5/S7 data. The developer never writes these prompts. Temperature = 0 — same input, same output, every time.
Pure assembly. Zero new decisions. Same data — 6 different packages — 6 different audiences.
S10 takes everything produced by S7, S8, and S9 and packages it into 6 outputs. Like a post office sorting room — all the letters are already written. S10 puts each letter in the right envelope and sends them out. It makes no decisions, runs no scans, calls no LLM.
Human-readable findings. Plain English from S9. Remediation steps with priority. Severity flags. T3 supplement form. Escalation hints.
Same findings — simpler language. Uses 80-word student_summary from S9. No "critical" severity language. Encourages learning over compliance tone.
Machine-readable. All 78 control statuses as structured objects. Evidence paths, gap signals, overlay tags, escalation hints — all queryable.
Upload to GitHub — ethics findings appear as inline code annotations in pull requests. Like lint errors but for ethics. Developer sees issues without leaving GitHub.
Pre-fills the ADR human reviewer's workspace. Per-control records, T3 supplement entries, escalation hints, overlay tags. Reviewer does not start from scratch.
Registers evidence files found with SHA-256 fingerprints. Certifier already knows what to verify. e_type_candidates is advisory only — developer must confirm E-type at submission.
Immutable record sealed first. Workspace deleted within 60 seconds. Source code gone. Fingerprints remain forever.
S11 produces nothing new. Every other step produces something. S11 preserves what was produced and removes what is no longer needed. The sealed record cannot be changed by anyone — developer, Ethiksa, Reviewer, Certifier. The 60-second workspace deletion is a hard deadline — audit record is always sealed first, then code is deleted. Never the other way.
Extra obligations that activate only for specific AI types. Neither GEN nor REL ever gets a direct status from the CER — only the Reviewer assigns those.
Extra rules for systems using LLMs, image gen, audio gen. Each GEN control is anchored to a PRIMARY control it cannot exist without.
Extra due-diligence rules when you use someone else's model instead of training your own.
Click any pillar to see exactly what every control looks for, what files or code patterns it targets, and what makes it pass.
Who owns this AI? Who approves changes? What happens when it fails? These 10 controls verify that ownership, oversight, and governance processes are formally in place.
| ID | Tier | What it searches for | Key signals |
|---|---|---|---|
| GOV-01 | T1 | Named owners + enforced PR approval gates CODEOWNERS file assigning responsibility per directory. PR approval gates enforced in CI before any code merges. Both must exist. | CODEOWNERSPR approval rulesrelease workflow YAML |
| GOV-02 | T2 | System purpose, intended users, non-use boundaries A document stating what this AI does, who it's for, and explicitly what it must NOT be used for. | system_description.*intended_use.*README purpose |
| GOV-03 | T3 | Stakeholder impact assessment Who is helped, harmed, or excluded by this AI? Developer must point to the document via supplement form. | Supplement: file path required |
| GOV-04 | T3 | Initial project risk assessment Was a risk assessment done at design time — before building started? Supplement required. | Supplement: file path required |
| GOV-05 | T2 | Human oversight model documented Who reviews AI outputs, who can intervene, at what decision points. Roles + intervention points both required. | oversight_plan.*escalation_workflow.* |
| GOV-06 | T2 | Incident response plan with escalation chain What happens when the AI causes harm or fails? Written runbook with named escalation chain. | incident_response.*runbook.*INCIDENT.md |
| GOV-07 | T2 | Post-deployment monitoring schedule How often is the AI reviewed after launch? Defined cadence and monitoring workflow required. | monitoring_schedule.*review_cadence.* |
| GOV-08 | T3 | Change management / version governance policy When model, prompt, or data changes — who approves? What must be tested first? Supplement required. | Supplement: file path required |
| GOV-09 | T2 | Re-evaluation trigger policy What events — model change, incident, new users — must force a formal re-review of the system? | reevaluation_policy.*trigger_conditions.* |
| GOV-10 | T2 | Regulatory compliance mapping Which laws (GDPR, EU AI Act) apply? How does each design choice respond to each obligation? Full mapping required. | regulatory_mapping.*compliance_matrix.*eu_ai_act_mapping.* |
Did you think about what could go wrong before building? RISK-01/02/03 are T2 — CER scans for documents. RISK-04/05/06 are T3 — human governance decisions, CER asks for file paths.
| ID | Tier | What it searches for | Key signals |
|---|---|---|---|
| RISK-01 | T2 | System context documentation Domain, stakeholders, scale, decision impact, operating environment, and dependency context — all 6 components documented. | system_context.*project_risk.* |
| RISK-02 | T2 | Risk classification with written rationale System formally classified as low/medium/high risk with a written justification for why that classification was chosen. | risk_classification.*risk_matrix.* |
| RISK-03 | T2 | Ethical impact assessment Who could be harmed by this AI — identified, prioritised, and mitigation noted before implementation. Not after. | ethics_impact.*impact_assessment.*/ethics/ directory |
| RISK-04 | T3 | Signed residual risk acceptance After mitigations — remaining risks must be accepted by a named accountable owner with their signature on record. | Supplement: signed risk acceptance doc |
| RISK-05 | T3 | Maintained risk register — living document A document tracking all risks with owners, mitigations, and review dates — kept updated over time. Not a one-time artifact. | Supplement: maintained risk register |
| RISK-06 | T3 | Reassessment trigger events defined What specific events must trigger a formal risk re-assessment? Model change, new users, incidents — all must be named. | Supplement: reassessment trigger policy |
Can a human stop the AI? Can users fight back? HUMO-02 and HUMO-04 are T1 — visible in code. HUMO-01/03/06/07 are T2. HUMO-05 is T3.
| ID | Tier | What it searches for | Key signals |
|---|---|---|---|
| HUMO-01 | T2 | Named oversight roles with training requirements Who reviews AI outputs, what competence is required, how are roles assigned. All three components documented. | oversight_roles.*training_requirement.*RACI chart |
| HUMO-02 | T1 | Working kill switch and admin override in code Actual working code — not documentation — that lets a human pause, halt, or override AI decisions. Enforced on critical paths. | kill_switchadmin_override endpointmanual_review_queue |
| HUMO-03 | T2 | User appeal / dispute endpoint + recourse process A real working endpoint for users to challenge decisions, plus documentation of the recourse process and timeline. | POST /appealPOST /disputerecourse UI strings |
| HUMO-04 | T1 | Timeout + retry + fallback + abstention — all 4 linked When AI is uncertain or fails, it steps aside gracefully. All 4 components must be present and linked. Timeout alone = PARTIAL. | timeout logicretry chainfallback functionabstention_threshold |
| HUMO-05 | T3 | Support SLA — response time commitments Written commitment on how long it takes to get help for different issue types. Supplement required. | Supplement: support SLA document |
| HUMO-06 | T2 | HITL gate enforced in code for high-risk decisions For decisions that matter — code must force a human to review and approve before the AI acts. | @requires_human_reviewapproval_queue |
| HUMO-07 | T2 | No fully autonomous consequential decisions Checks for ABSENCE of human gate on rights-affecting endpoints. Autonomous consequential paths = MISSING. | consequential endpoints without @requires_human_review |
How does your AI handle personal data? PRIV-01/03/04/05 are T1 — directly in code. PRIV-02/06/08/09 are T2. PRIV-07 is T3.
| ID | Tier | What it searches for | Key signals |
|---|---|---|---|
| PRIV-01 | T1 | PII not in logs, field-level minimisation in schema Personal data must not appear in log statements. Schema must collect only necessary fields. Both checked. | log statements near email/phoneredaction patterns |
| PRIV-02 | T2 | Lawful basis for data collection A document stating the legal reason for collecting each type of data — consent, contract, legitimate interest. | lawful_basis.*privacy_notice.*GDPR_basis.* |
| PRIV-03 | T1 | User-facing AI disclosure and data use notice in UI code Users told in the app that AI is involved and what data is used — not just in buried terms and conditions. | AI disclosure strings in UIconsent banner config |
| PRIV-04 | T1 | Data retention TTL config AND working deletion jobs Rules saying "delete after X days" AND working code that actually executes the deletion. Config alone = PARTIAL. | TTL config valuesdeletion endpointsdeletion cron jobs |
| PRIV-05 | T1 | RBAC — least-privilege on all data and model endpoints Role-based access control decorators on all sensitive routes. No over-privileged roles. | @requires_roleRBAC middlewareIAM policy files |
| PRIV-06 | T2 | Training data provenance — origin, license, restrictions Where did training data come from, what license does it have, are you legally allowed to use it for AI? | dataset_provenance.*data_rights.*data_card.* |
| PRIV-07 | T3 | Cross-border data transfer assessment Does data leave the country? If yes — has the legal basis for that transfer been assessed and documented? | Supplement: cross-border assessment |
| PRIV-08 | T2 | De-identification evaluation report If you anonymised data — prove it works. Method + validation approach + guarantee all required. | deidentification_eval.*k-anonymity config |
| PRIV-09 | T2 | Synthetic data governance — provenance + bias amplification If using GAN/VAE synthetic data — how was it made, what biases might it carry, and are limitations disclosed? | synthetic_data_config.*bias_amplification_assessment.* |
Does your AI treat everyone equally? FAIR-01/02 are T1. FAIR-03 through FAIR-07 are T2. No T3 rules. Story: Find → Plan → Run → Fix → Set Limits → Keep Watching → Let Users Fight Back.
| ID | Tier | What it searches for | Key signals |
|---|---|---|---|
| FAIR-01 | T1 | Fairness evaluation notebooks with subgroup metrics Notebooks or scripts measuring AI performance broken down by demographic group — not just overall accuracy. | fairness eval notebooksprotected_attribute_config.*demographic_parity checks |
| FAIR-02 | T1 | Bias testing plan with target groups and thresholds Written plan: which groups tested, what metrics used, what gap is acceptable. All three required. | bias_testing_plan.*fairness_test_config.yamlacceptable_thresholds.* |
| FAIR-03 | T2 | Executed bias test results with interpretation Not just "tests ran" — actual numbers, what they mean, and what action was taken. Results without interpretation = PARTIAL. | bias_test_results.*fairness_evaluation_report.* |
| FAIR-04 | T2 | Bias mitigation code with documented tradeoffs Not just noting bias — actually using libraries to reduce it. Experiment notebook + tradeoff doc both required. | Fairlearn importAIF360 importbias_mitigation.* notebooks |
| FAIR-05 | T2 | Numeric fairness thresholds in config file Not "we aim to be fair" — a specific number like "no group can be more than 5% worse than the best performing group." | fairness_thresholds.yamldemographic_parity keys |
| FAIR-06 | T2 | Ongoing fairness monitoring on a schedule Fairness monitored post-launch on a recurring schedule — not just once before launch. Cron job or CI/CD workflow. | fairness_monitor.*drift_detection.*CI/CD cron schedule |
| FAIR-07 | T2 | Appeals endpoint for fairness complaints + timeline A working route where users can challenge a decision they believe was unfair. Timeline documented. | POST /appealPOST /review-requestfairness_recourse.* |
Is your AI honest about what it is? Can it explain its decisions? TRAN-01/05/07/08 are T1. TRAN-02/03/04/06 are T2. No T3 rules.
| ID | Tier | What it searches for | Key signals |
|---|---|---|---|
| TRAN-01 | T1 | "AI-powered" disclosure strings in UI code Users told AI is involved — visible in the app. Plus refusal policy and content moderation API calls. | AI disclosure stringscontent moderation callsrefusal policy code |
| TRAN-02 | T2 | System limitations doc with user-facing text Known failure modes and uncertainty conditions — documented AND communicated to users in the UI. Both required. | limitations.*user-facing limitation strings |
| TRAN-03 | T2 | Explainability library or endpoint with documentation The AI can explain why it made a decision. SHAP/LIME imported and used, or explanation endpoint exists. | SHAP importLIME importexplanation_api.* |
| TRAN-04 | T2 | All 4 documentation components present Model card + system description + assumptions + intended/prohibited use. All 4 required. Missing even one = PARTIAL. | model_card.*intended_use.*prohibited_use.*assumptions.* |
| TRAN-05 | T1 | Trace ID on every request + audit log writes on decision paths Every AI decision gets a trace ID. Every decision written to audit log with input, output, and trace ID linked. | trace ID injectionaudit log writes@log_interaction |
| TRAN-06 | T2 | Decision log schema with reconstructable rationale field Not just logging that a decision happened — logging WHY in enough detail to reconstruct the reasoning later. | decision_log.* with rationale fieldSHAP values stored |
| TRAN-07 | T1 | AI identity truthfulness — no deny-AI patterns in prompts If user sincerely asks "are you AI?" — code must answer honestly. No deny_ai_identity or pretend_human patterns allowed. | sincerity_check conditionabsence of deny_ai_identityabsence of pretend_human |
| TRAN-08 | T1 | Content provenance watermarking on AI-generated output C2PA library or watermarking applied to every generated output. GEN-conditional — only active if gen_triggered = true. | C2PA library importwatermarking configSynthID patterns |
Does your AI behave safely when things go wrong? SAFE-01 and SAFE-04 are T1. SAFE-02/03/05/06 are T2. No T3 rules.
| ID | Tier | What it searches for | Key signals |
|---|---|---|---|
| SAFE-01 | T1 | Input validation on all external endpoints + safety doc Every API endpoint taking external input must validate it with a schema library. Plus a safety requirements document. | Pydantic validatorszod/joi schemassafety_constraints.* |
| SAFE-02 | T2 | Edge-case, stress, and adversarial test files Tests for weird inputs, failure conditions, and deliberate attacks — not just happy-path tests. | edge_case_tests.*adversarial_test.*stress_test.* |
| SAFE-03 | T2 | Distribution-shift robustness evaluation How does the system perform when real-world conditions differ from training? OOD test scripts required. | distribution_shift_eval.*ood_test.*robustness_eval.* |
| SAFE-04 | T1 | Complete fallback chain — all 4 must be linked Timeout + retry + fallback + abstention — all 4 present and linked. One component missing = PARTIAL. None = MISSING. | timeout logicretry chainfallback functionabstention_thresholdcircuit_breaker |
| SAFE-05 | T2 | Red-team report with documented attack scenarios Someone deliberately tried to break the AI before launch. Report with scenarios, findings, and what was fixed. | red_team_results.*adversarial_probing.* |
| SAFE-06 | T2 | Post-deployment harm monitoring with alerting thresholds After launch — harm signals defined, alerting thresholds set, and response triggers documented. | harm_monitor.*safety_alert_config.*harm_threshold.* |
Can your AI be hacked or misused? SEC-01/02/03/06/07 are T1. SEC-04/05 are T2. SEC-07 is Industrial-only.
| ID | Tier | What it searches for | Key signals |
|---|---|---|---|
| SEC-01 | T1 | No hardcoded secrets + auth middleware + threat model No API keys or passwords in code. Auth middleware on all sensitive routes. Threat model document exists. All 3 required. | hardcoded key patternsauth middlewarethreat_model.* |
| SEC-02 | T1 | Prompt injection defences + exfiltration guards For LLM systems — defences against attackers hijacking AI via crafted inputs. Input schema validation on LLM inputs. GEN-conditional. | prompt sanitisationinjection test casessystem_prompt isolation |
| SEC-03 | T1 | Pinned lockfile + SBOM + CI secrets scan + PR review gate All 4 must be present. Lockfile pins exact versions. SBOM lists all libraries. CI scans for secrets. PRs require approval. | package-lock.jsonsbom.json (CycloneDX)secrets scan in CI YAMLPR review gate |
| SEC-04 | T2 | Rate limiting + abuse reporting endpoint Rate limiting stops API abuse. POST /report-abuse lets users flag misuse. Both required. | @limiter.limit decoratorPOST /report-abuse |
| SEC-05 | T2 | Vulnerability management policy + Dependabot + CVE disclosure Written plan for handling security bugs. Automated dependency updates. CVE disclosure process. All 3 required. | SECURITY.mddependabot.ymlCVE disclosure process |
| SEC-06 | T1 | Pre-trained model provenance — license, safety, fitness Using HuggingFace/OpenAI models — a document assessing the model's license, known limitations, and safety testing. REL-conditional. | model_provenance.*HuggingFace model card URLsbase_model_safety.* |
| SEC-07 | T1 | Membership inference + model inversion assessment Can the model be tricked into revealing training data? Both assessments with risk level and mitigation. Industrial-only. | membership_inference_assessment.*model_inversion_analysis.* |
Is everything written down and traceable? DOC-05 is the only T1 in this pillar. DOC-01/02/03/04/06/07 are T2. DOC-08 is T3.
| ID | Tier | What it searches for | Key signals |
|---|---|---|---|
| DOC-01 | T2 | All 5 system description components Purpose + intended users + scope + assumptions + limitations. All 5 required. LLM checks completeness at S9. | system_description.*system_card.*scope_definition.* |
| DOC-02 | T2 | Dataset documentation — provenance, license, context, constraints Where training data came from, its license, collection context, and known constraints. All 4 fields checked by LLM. | datasheet_for_dataset.*dataset_card.* |
| DOC-03 | T2 | Model card — intended use, forbidden use, evaluation approach All 3 fields required. Forbidden use must be explicitly stated — not just implied or absent. | model_card.*model_documentation.* |
| DOC-04 | T2 | Decision log schema — reconstructable rationale field Not just logging outcomes — storing enough to reconstruct exactly what happened. LLM confirms reconstruction is possible. | decision_log.* with rationale fieldreconstructable decision schema |
| DOC-05 | T1 | All 4 versions pinned and linked — data, model, prompt, code All four components versioned together in one manifest. Any past state must be fully reproducible. | version_manifest.*model version referencesprompt version tags |
| DOC-06 | T2 | Evidence retention policy — scope + duration + access controls All 3 parts required: what is kept, for how long, and who can access it. Missing any one = PARTIAL. | retention_policy.*evidence_retention.* |
| DOC-07 | T2 | Append-only audit logs + integrity hash verification Logs that cannot be edited or deleted. Plus a mechanism to detect tampering. Both must exist. | CloudTrail / Kafka configWORM storagehash verification script |
| DOC-08 | T3 | Certification-trace design specification Document explaining how certification decisions, inheritance, and audit outputs are structured. | Supplement: cert_trace.* doc |
Can everyone use your AI? ACC-07 is the only T1. ACC-01/03/05/06/08 are T2. ACC-02 and ACC-04 are T3 — user testing cannot be detected in code.
| ID | Tier | What it searches for | Key signals |
|---|---|---|---|
| ACC-01 | T2 | Accessibility requirements — disability, language, device, usability Written plan covering all 4 accessibility dimensions. WCAG lint configured for automated checks. | accessibility_requirements.*WCAG lint config |
| ACC-02 | T3 | Inclusive design testing with real or proxy users Was the system tested with people from the intended audience? Participant records or proxy testing report. | Supplement: testing evidence |
| ACC-03 | T2 | Human-factors hazard doc — over-trust, automation bias, misuse All 3 hazard types identified and designed against. UI warning strings about AI limitations. | human_factors_hazards.*automation_bias_warning.* |
| ACC-04 | T3 | User comprehension validation Evidence that real users were tested and confirmed to understand notices, explanations, and key interactions. | Supplement: comprehension validation |
| ACC-05 | T2 | Vulnerable user protections — code enforcement + documentation If children or elderly are in user base — both a protection document AND working code enforcement must exist. | minor_safeguarding.*age_verification code |
| ACC-06 | T2 | Human alternative route — mandatory, not optional For consequential outcomes — a working code route AND documentation stating it is mandatory. | fallback_to_human routeescalate_to_human endpoint |
| ACC-07 | T1 | No dark patterns — no pre-ticked boxes, no coercive consent Scans for ABSENCE of manipulative UI patterns. Pre-ticked consent, asymmetric buttons, buried disclosures = MISSING. | consent code without pre-ticked boxesabsence of dark_pattern anti-patterns |
| ACC-08 | T2 | Support channel doc + accessible contact endpoint Both must exist. The support channel itself must be accessible — not just a phone number if users cannot hear. | support_channels.*accessible_contact endpoint |
What is the bigger impact on society and the planet? No T1 rules — nothing in this pillar is detectable purely in code. SOC-02/04/05 are T3. All others are T2.
| ID | Tier | What it searches for | Key signals |
|---|---|---|---|
| SOC-01 | T2 | Societal benefit statement — who benefits and how to measure it All 3 parts: benefit type + beneficiary group + recognition criteria (how you'd know it's working). | societal_benefit.*benefit_statement.* |
| SOC-02 | T3 | Societal harm assessment Broader harms — exclusion, misinformation, surveillance — identified and assessed. societal_impact_scanner also checks; if file found automatically, status = PARTIAL. | Supplement: harm_assessment.* |
| SOC-03 | T2 | Carbon tracking + compute budget + environmental impact doc All 3 required. codecarbon import alone = PARTIAL. Need implementation + budget config + impact document for PASS. | codecarbon importcompute_budget.*environmental_impact.* |
| SOC-04 | T3 | Cultural and contextual appropriateness review Has the system been reviewed for local language, norms, and context-specific harms in the region it operates? | Supplement: cultural review doc |
| SOC-05 | T3 | Workforce and labor impact assessment Does this AI displace workers, enable unfair monitoring, or create safety risks? Someone must have assessed this. | Supplement: workforce_impact.* |
| SOC-06 | T2 | Dual-use / misuse assessment — repurposing scenarios How could this AI be weaponised or repurposed for harm? Scenarios and risk levels documented. | dual_use_assessment.*abuse_scenarios.* |
| SOC-07 | T2 | Harm reporting endpoint + public disclosure commitment A working endpoint where anyone can report harmful outputs. Plus a public disclosure document. | POST /report-harmpublic_disclosure.* |
| SOC-08 | T2 | Equity of access — all 4 barrier types assessed Cost + language + literacy + infrastructure barriers all considered. Missing even one barrier type = PARTIAL. | equity_of_access.*access_barrier_assessment.* |
All 31 plugins — grouped, typed, and cross-referenced. DET = fully automatic. HYB = automatic detection + LLM content check. All run in parallel at S5.
Not all 31 plugins run for every scan. Each control is routed only to its registered plugins at S4. A plugin only runs if at least one of its registered controls is active. The full 31 only run if all controls are active and no filter removes any.
| # | Plugin | Type | Controls | What it looks for |
|---|---|---|---|---|
| 01 | secrets_scanner | DET | SEC-01SEC-03SEC-06 | Hardcoded API keys, tokens, passwords, connection strings. Env var references vs inline values. |
| 02 | authz_scanner | DET | HUMO-02HUMO-07SEC-01 | Auth/authz decorators on endpoints. Missing auth on sensitive routes. Admin override. Absence of HITL gate on consequential endpoints. |
| 03 | input_validation_scanner | DET | SAFE-01SEC-01SEC-02 | Input schema validation on API handlers. Schema library usage — Pydantic, Zod, Joi. |
| 04 | rate_limit_scanner | DET | SEC-04SAFE-04 | Rate limiting middleware, throttle decorators, API gateway config. |
| 05 | privacy_log_scanner | DET | PRIV-01PRIV-03PRIV-04 | Log statements near sensitive field names — email, phone, name. PII proximity scoring per line. |
| 06 | retention_scanner | DET | PRIV-04 | TTL config values, deletion endpoints, deletion cron jobs, retention policy file references. |
| 07 | access_control_scanner | DET | PRIV-05SEC-01 | RBAC decorators, least-privilege patterns, credential scope review. |
| 08 | pii_classifier | HYB | PRIV-01PRIV-03DOC-04 | PII field detection from schema definitions. LLM classifies ambiguous field names — "passenger_ref": personal data or order number? |
| # | Plugin | Type | Controls | What it looks for |
|---|---|---|---|---|
| 09 | prompt_injection_scanner | DET | SEC-02 | Prompt templates, system prompts, injection test cases, agent orchestration, tool permission constraints. |
| 10 | moderation_scanner | DET | TRAN-01 | Content moderation API calls, refusal policy code, output filtering logic. |
| 11 | grounding_scanner | DET | TRAN-02TRAN-03 | RAG retrieval integration, citation formatters, source attribution, hallucination evaluation scripts. |
| 12 | disclosure_scanner | DET | TRAN-01TRAN-07ACC-07 | AI disclosure text in UI. Identity truthfulness logic. Sincerity-check conditions. Dark pattern detection. |
| # | Plugin | Type | Controls | What it looks for |
|---|---|---|---|---|
| 13 | dependency_scanner | DET | SEC-03SEC-06DOC-05 | Lockfiles, dependency manifests, LLM/AI vendor imports, unpinned dependencies. |
| 14 | sbom_scanner | DET | SEC-03 | SBOM artefact presence — CycloneDX, SPDX formats. Provenance attestation. SLSA artefact. |
| 15 | ci_security_scanner | DET | GOV-01GOV-09SEC-03SEC-05 | Branch protection, release approval gates, dependency scan workflow, secrets scanning step in CI YAML. |
| # | Plugin | Type | Controls | What it looks for |
|---|---|---|---|---|
| 16 | fairness_artifact_scanner | DET | FAIR-01FAIR-02FAIR-03 | Fairness evaluation notebooks, subgroup metrics scripts, bias mitigation experiments, protected attribute configs. |
| 17 | robustness_test_scanner | DET | SAFE-02SAFE-03SAFE-05 | Edge-case tests, adversarial test suites, robustness eval scripts, red-team artefacts. |
| 18 | fallback_scanner | DET | SAFE-04HUMO-04 | Timeout + retry + fallback chains, abstention thresholds, graceful degradation, circuit breakers. All 4 must be linked together. |
| # | Plugin | Type | Controls | What it looks for |
|---|---|---|---|---|
| 19 | docs_scanner | HYB | GOV-01–04GOV-10RISK-01–03TRAN-02–04DOC-01SOC-01/06/08 | Model cards, system descriptions, risk registers, impact statements, regulatory mapping. LLM classifies ambiguous doc types. |
| 20 | traceability_scanner | DET | DOC-04DOC-05TRAN-05TRAN-06 | Trace ID injection, audit log writes, decision log fields with rationale, version pin discipline. |
| 21 | governance_scanner | DET | GOV-01GOV-05–07GOV-09/10 | CODEOWNERS, PR templates, incident response runbooks, monitoring schedule, re-evaluation trigger config. |
| 22 | oversight_code_scanner | DET | HUMO-01–04HUMO-07 | Manual review queues, admin override functions, kill switches, escalation hooks, HITL gates, autonomous decision anti-patterns. |
| # | Plugin | Type | Controls | What it looks for |
|---|---|---|---|---|
| 23 | synthetic_data_scanner | HYB | PRIV-09 | Synthetic data generation config, provenance files, bias amplification assessment. LLM checks content quality. |
| 24 | pre_trained_model_scanner | DET | SEC-06 | Pre-trained model references, HuggingFace model card URLs, licensing notes, safety assessments. |
| 25 | inference_privacy_scanner | HYB | SEC-07 | Membership inference assessment, model inversion analysis, privacy attack evaluation. LLM checks risk and mitigation documented. |
| 26 | ui_accessibility_scanner | DET | ACC-01ACC-03ACC-05ACC-07 | WCAG lint config, ARIA attributes, alt text, human alternative paths, dark pattern detection. |
| 27 | content_provenance_scanner | DET | TRAN-08 | C2PA library imports, watermarking config, provenance metadata fields, SynthID patterns. |
| # | Plugin | Type | Controls | What it looks for |
|---|---|---|---|---|
| 28 | risk_document_scanner | HYB | RISK-01–06 | Risk registers, threat models, ethical impact assessments, residual risk acceptance (LLM checks for owner signature field), reassessment trigger policies. |
| 29 | societal_impact_scanner | HYB | SOC-02/03/06/07/08 | Societal harm assessment files, carbon tracking imports, dual-use assessment docs, harm reporting endpoints, equity of access docs. |
| 30 | doc_completeness_scanner | HYB | DOC-02/03/06/07/08 | Dataset docs, model cards, evidence retention policy, audit trail integrity controls, certification-trace design spec. LLM checks completeness of each. |
| 31 | recourse_fairness_scanner | HYB | FAIR-04–07HUMO-03ACC-06ACC-08 | Fairness mitigation imports, parity threshold configs, fairness monitoring cron jobs, appeal endpoints, human alternative routes, support channel docs. |
Every active control gets exactly one status after S7. Assigned by the Evidence Mapper — never by the LLM. These are the only values the CER ever uses.
All required evidence found at this assurance level. Control is fully covered. No gaps.
Some evidence found but not all required. Example: retention policy doc exists but deletion cron job missing.
No evidence at all. Required files or code patterns don't exist. Must be built before proceeding to Reviewer.
Rule does not apply to this project. TRAN-08 only applies to GenAI. Not shown in report. No supplement sent.
T3 rule needing human input — supplement form sent. Or T1/T2 where no files were accessible in the repo.
The CER's lie detector. Compares what was declared against what was found. Three checks — only two can block progress.
You filled a declaration form before landing (intake questionnaire). The officer checks your bags (S3 signals + plugin findings). Then compares:
"You declared nothing to declare — but your bag has 3 bottles of wine." → CONFLICT → flagged.
"You declared professional equipment — bag matches." → No flag.
The officer does not confiscate anything. They just flag conflicts and say "sort these out before you proceed."
| Check | What it compares | Produces | Sets escalation_required? |
|---|---|---|---|
| Check 1 Declaration vs Reality | Intake fields vs code-detected signals. Undeclared GenAI, undeclared minor users, undeclared cross-border transfers. | escalation_hints[] | NO — informational only. Scan can proceed. |
| Check 2 Level Override | Declared assurance level vs override triggers. rights_affecting endpoint? → min Capstone. Minor users? → min Capstone. Regulated sector? → min Industrial. | escalation_hints[] | YES — hard blocker. Must correct intake and re-run. |
| Check 3 T3 Completeness | All active T3 controls vs supplement submissions. If supplement not submitted at all → NOT_EVALUABLE + blocker. If submitted but file missing → MISSING (not a blocker). | escalation_hints[] | YES — hard blocker. Must submit supplement before proceeding. |
S8 does not change any statuses. Does not re-run plugins. Does not cancel the scan. It only produces hints and flags. The developer sees these in their S10 report. If escalation_required = true, the developer corrects their intake and re-runs. The CER waits.
Same underlying data. 6 different views. Each shaped for its audience. S10 makes no decisions — it is a post office, not a decision-maker.
Pre-fills the human reviewer's ADR workspace. Reviewer does not start from scratch. Every gap, every hint, every overlay tag already populated.
Like checking luggage at the airport — evidence registered before arrival. Certifier already knows what to verify. SHA-256 hashes prove files haven't changed.
e_type_candidates is advisory only. CER suggests — developer must declare E-type at Certifier submission. Certifier then verifies sufficiency.
Every other step produces something new. S11 preserves what was produced and removes what is no longer needed. The only immutable step in the entire pipeline.
Everything that happened in court has been recorded verbatim — every witness statement (raw_findings), every expert opinion (LLM calls), every judge's ruling (statuses), which version of the law was used (registry_version). The reporter seals the transcript. It becomes the permanent official record. Nobody can alter it after sealing. Then the courtroom is cleared — exhibits returned or destroyed. Only the sealed transcript remains.
The assurance level determines how much evidence is required at each control. Level can only go up — never down after it's set. Override rules apply before developer preference.
Educational or experimental AI. Internal tools. Most things get PARTIAL if basic scaffolding exists. Just show awareness of each concern.
Real users with real data, limited impact. Need at least one reproducible test artefact per applicable area and basic logging.
Public-facing with significant societal impact. Real technical controls required — redaction, injection tests, subgroup fairness metrics.
Rights-affecting or regulated systems — loan, hiring, medical AI. Full audit-grade evidence required. SEC-07 only active here.
Users include children or minors → minimum Capstone, regardless of what was declared.
AI makes rights-affecting decisions (loans, hiring, benefits) → minimum Capstone.
Regulated industry (healthcare, finance, legal) → minimum Industrial.
If the code reveals an override condition and the declared level is too low → S8 sets escalation_required = true → developer must correct intake and re-run at the correct level.
Every piece of jargon from the CER architecture and our full conversation — in two sentences or fewer.
One of the 78 ethical rules — e.g. "PRIV-01: don't leak PII into logs." Each has a tier, registered plugins, and required evidence artefacts.
Where the evidence for a rule lives. T1 = in code. T2 = in a document. T3 = in a human governance decision. Determines what happens next — not whether the rule applies.
A specialist scanner registered to one or more controls. Runs in parallel with all others at S5. Reads files as data only — never executes code. Produces RawFindings, never statuses.
The structured JSON output a plugin produces. Contains: what was found, what was not found, file paths, line numbers, confidence level. The Evidence Mapper at S7 reads these to assign statuses.
The S7 component that reads RawFindings + the registry requirements and assigns PASS/PARTIAL/MISSING. 100% deterministic — same input always gives same output. No AI involved.
The single master list of all 78 controls. All four AIGAP tools use the exact same list. Includes the GEN/REL anchor mapping table and the required evidence per control per assurance level.
The structured data object produced from the intake questionnaire. Filled before the scan. CER reads it at S1, S3, S4, and S8 to set context, filter controls, and verify honesty.
Specific lines of code — like import openai — that reveal which libraries the project uses. Read by S3 as text only. Never executed. Used to set gen_triggered and rel_triggered flags.
A boolean flag set by S3 when GenAI import patterns are detected in the code. When true — GEN overlay controls activate and GEN-conditional controls like TRAN-08 and SEC-02 enter the pipeline.
A boolean flag set by S3 when third-party pre-trained model patterns are detected. When true — REL overlay controls activate and SEC-06, DOC-03, RISK-01 get REL anchor tags at S6.
Extra rules that activate only for specific AI types. They are anchored to PRIMARY controls — they cannot have their own independent status from the CER. Only the Reviewer assigns GEN/REL status.
"GEN-04 anchored by TRAN-08" means GEN-04 is the dependent control — the coat. TRAN-08 is the foundation — the hook. GEN-04 cannot exist without TRAN-08. The CER's question for TRAN-08 does not change when GEN-04 is anchored.
A field added by S6 to qualifying RawFindings. Tells the Reviewer which GEN or REL rule this PRIMARY control result is also relevant to. A signal — not a status change.
A field added by S6 alongside overlay_relevance. Confirms which PRIMARY control the tagged finding lives under in the report. Ensures GEN/REL findings don't appear as free-floating entries.
The form the CER generates for each active T3 control. Asks: "Where is this document? Give us the file path." Developer fills it in. CER checks if the file exists in the manifest.
A list produced by S8 containing all conflicts found across its 3 checks. Appears in the Developer Report and Reviewer Handoff Package. All 3 checks can produce hints.
A boolean set to true by S8 Check 2 (level override) or Check 3 (T3 supplement missing). Hard blocker — developer cannot proceed to Reviewer phase until resolved. Check 1 never sets this.
SHA-256 fingerprint of the entire codebase computed at S2. Stored verbatim in the S11 audit record. Proves exactly which version of code was scanned.
Human-in-the-Loop. A code pattern where a human must approve the AI's decision before it takes effect. Required by HUMO-06 on high-stakes decision endpoints.
Software Bill of Materials — a complete ingredient list of every library your project uses with exact versions. Required by SEC-03. CycloneDX or SPDX format. Like a food label for software.
Static Analysis Results Interchange Format. GitHub-compatible output from S10. Upload it and GitHub shows ethics findings as inline annotations in pull requests — like lint errors for ethics.
Deterministic plugin type. Finds files or code patterns using regex or AST parsing. Same input always gives same output. No LLM involved. Runs fully automatically.
Hybrid plugin type. First finds files automatically (the DET part), then an LLM reads the content to assess quality — not just that a file exists. LLM checks completeness and adequacy.
Advisory field in the Certifier Pre-Registration Package. CER suggests which evidence type (E1, E3, E5...) a found file could be. Developer must confirm. Certifier then verifies sufficiency.
A UI design trick that manipulates users — pre-ticked consent boxes, asymmetric buttons, buried disclosures. ACC-07 checks for their ABSENCE. Any dark pattern found = MISSING status.
Deliberately trying to break or manipulate your own AI before launch. Required for SAFE-05. A report must exist with attack scenarios, what was found, and what was fixed.
A GitHub file assigning named people as responsible owners of different parts of the codebase. Required for GOV-01 — along with enforced PR approval gates in CI.