diff --git a/ai-compliance-workflow.md b/ai-compliance-workflow.md
new file mode 100644
index 0000000..1069d32
--- /dev/null
+++ b/ai-compliance-workflow.md
@@ -0,0 +1,149 @@
+# CE AI-Adjacent Product Compliance Checklist (CE-COMP)
+Version: 1.0 | Effective: 2026-07-04 | Review cycle: Monthly | OHIOD: HOE001
+
+## 0. How to use this document
+
+**For AI agents (Claude Code, local models, vibe-coding sessions):**
+Treat every item below as a task with an `id`, `status`, and `evidence` field. When asked to "run compliance check" or "retrofit [product]," iterate every item in Sections 2–9, verify against actual product state, update `status` and `evidence`, and flag any item that regresses from a prior PASS. Never mark PASS without a concrete evidence path or artifact reference. If uncertain, mark `NEEDS-HUMAN` and stop — do not guess at compliance status.
+
+**For John (OHIOD gate):**
+Every item marked `NEEDS-HUMAN` or `FAIL` requires your review and sign-off before the product ships. Monthly reviews only need to re-check items flagged `RECHECK-MONTHLY`. Retrofits run the full checklist once, then drop to monthly cadence.
+
+**Status values:** `PASS` | `FAIL` | `IN-PROGRESS` | `N/A-JUSTIFIED` | `NEEDS-HUMAN`
+
+---
+
+## 1. Intake & Classification (run once per product, re-run on scope change)
+
+| ID | Item | Status | Evidence | Notes |
+|---|---|---|---|---|
+| CE-001 | Intended purpose statement written in plain language (who uses it, what decision/output it produces) | | | |
+| CE-002 | Checked against Annex III categories — record actual match or non-match, do not default-label | | | Classification is honest even though engineering treats everything as high-risk |
+| CE-003 | Checked against Annex I / Article 6(1) — is this a safety component of an already-regulated product (medical device, machinery, toy)? | | | |
+| CE-004 | Excluded-use screen: remote biometric ID, military operations, invasive/privacy-violating surveillance | | | Auto-decline at intake if triggered — see memory policy |
+| CE-005 | Provider vs. deployer role identified (who places this into service, under whose name) | | | Critical when client resells/redistributes (e.g. Ramps model) |
+| CE-006 | Downstream redistribution risk flagged (does the client resell or sublicense to their own clients?) | | | Each downstream deployment may need its own CE-001–004 pass |
+
+---
+
+## 2. Risk Management File (Article 9) — open at design time, never retrofitted after the fact
+
+| ID | Item | Status | Evidence |
+|---|---|---|---|
+| CE-101 | Risk log created before first line of production code | | path: |
+| CE-102 | Foreseeable misuse scenarios documented (not just intended use) | | |
+| CE-103 | Each identified risk has a stated mitigation and residual risk level | | |
+| CE-104 | Risk log updated at every material design change (log entry, dated) | | |
+| CE-105 | `RECHECK-MONTHLY`: any new risk surfaced since last review | | |
+
+---
+
+## 3. Data Governance (Article 10)
+
+| ID | Item | Status | Evidence |
+|---|---|---|---|
+| CE-201 | Data source and lawful basis documented per dataset/corpus | | |
+| CE-202 | Representativeness check for the actual deployment population | | |
+| CE-203 | Known bias vectors screened and logged, even if none found | | |
+| CE-204 | Sensitive data scrubbed before any frontier-model handoff (per standing policy) | | |
+| CE-205 | `RECHECK-MONTHLY`: no new data sources added without re-screening | | |
+
+---
+
+## 4. Human Oversight Design (Article 14)
+
+| ID | Item | Status | Evidence |
+|---|---|---|---|
+| CE-301 | OHIOD gate location explicitly documented (where in the pipeline a human decides) | | |
+| CE-302 | What the human can see at that gate is defined and sufficient to decide | | |
+| CE-303 | What the human can override is defined and actually functional (not cosmetic) | | |
+| CE-304 | Gate cannot be bypassed by prompt injection or automated retry | | |
+
+---
+
+## 5. Logging & Traceability (Article 12)
+
+| ID | Item | Status | Evidence |
+|---|---|---|---|
+| CE-401 | Two-stream logging in place (compliance stream / operational stream) | | |
+| CE-402 | Retention periods match documented standard (5.5yr compliance / 90-day encrypted operational) | | |
+| CE-403 | Logs are tamper-evident and access-controlled | | |
+| CE-404 | `RECHECK-MONTHLY`: log storage integrity check (Object Lock, Restic backup verified) | | |
+
+---
+
+## 6. Testing & Validation (Article 15)
+
+| ID | Item | Status | Evidence |
+|---|---|---|---|
+| CE-501 | Accuracy/robustness tested against defined metric, not vibes | | |
+| CE-502 | Adversarial/edge-case testing performed | | |
+| CE-503 | Fairness testing across relevant demographic/use-case splits, where applicable | | |
+| CE-504 | Failure-mode test: does the OHIOD gate actually catch a confidently-wrong output? | | |
+| CE-505 | Tested at most-constrained hardware tier first (Ambrosiana-style validation) | | |
+
+---
+
+## 7. Documentation Package (Annex IV)
+
+| ID | Item | Status | Evidence |
+|---|---|---|---|
+| CE-601 | General description, architecture, data flows documented | | |
+| CE-602 | Risk file, data governance, oversight design, logging spec all cross-linked | | |
+| CE-603 | Client-facing bilingual summary prepared (IT primary / EN reference) | | |
+| CE-604 | Filepath confirmed against DIRECTORY.md before commit | | |
+
+---
+
+## 8. Conformity & Delivery (Article 47, Annex VI)
+
+| ID | Item | Status | Evidence |
+|---|---|---|---|
+| CE-701 | Internal conformity self-check completed and signed (name, date) | | |
+| CE-702 | Draft declaration of conformity prepared and matches actual tested scope | | |
+| CE-703 | Excluded-use / anti-repurposing disclaimer attached (per attorney-drafted clause) | | |
+| CE-704 | Client sign-off on stated intended use, logged | | |
+
+---
+
+## 9. Post-Market Monitoring (Article 72)
+
+| ID | Item | Status | Evidence |
+|---|---|---|---|
+| CE-801 | Monitoring mechanism actually operating (not just documented) | | |
+| CE-802 | Drift/incident trigger defined — what causes a re-review | | |
+| CE-803 | `RECHECK-MONTHLY`: any incident or drift signal since last check | | |
+
+---
+
+## 10. Regulatory Watch Log
+
+| Date checked | Change observed | Source | Action taken |
+|---|---|---|---|
+| 2026-07-04 | Digital Omnibus provisional agreement: Annex III obligations deferred to 2 Dec 2027; national sandbox deadline deferred to 2 Aug 2027. Not yet formally adopted. | artificialintelligenceact.eu, digital-strategy.ec.europa.eu | Continue building to 2 Aug 2026 baseline; treat deferral as margin, not pause |
+
+*(Append a row every monthly review, even if "no change" — silence in this log is itself a gap.)*
+
+---
+
+## 11. Retrofit Procedure (for previously-built products)
+
+1. Run Sections 1–9 in full against the existing product, treating it as a new intake.
+2. Do not assume prior "it works" status implies any item passes — verify each with fresh evidence.
+3. Where a gap is found, log it in Section 2 (Risk Management) as a newly identified risk, dated to discovery — not backdated.
+4. Update the product's own dossier and re-issue Section 8 sign-off before continued client use.
+5. Add the product to the monthly cycle going forward.
+
+---
+
+## 12. Monthly Review Procedure
+
+1. Re-check every item tagged `RECHECK-MONTHLY` across all active products.
+2. Append a row to Section 10 regardless of outcome.
+3. Any `FAIL` or new `NEEDS-HUMAN` halts client delivery until resolved.
+4. Increment document version number if the checklist itself changes; log the change here.
+
+---
+
+## Changelog
+- v1.0 (2026-07-04): Initial version.
\ No newline at end of file