Compliance Series · Part 4 of 4 · Technical Roadmap

From "Not Compliant Today" to CE-Marked High-Risk AI System by August 2, 2027

A program-management roadmap for VP Engineering, Head of AI Governance, and Chief Compliance Officer. Five phases, 66 weeks base path or 37 weeks on the EVE acceleration path. Explicit costs, staffing, and the risk flags that kill schedules. Status document, not legal advice.

J

The EU AI Act (Regulation 2024/1689) gives you two public dates and a lot of silence in between. Program management turns those two dates into seven. This document is the roadmap from today to CE mark, working backward from August 2, 2027, with the conformity-assessment queue treated as the critical path. It is a status document, not legal advice. Conformity decisions must be validated with counsel and, where required, a notified body.

1. Executive Summary

15.5 mo To high-risk deadline
66 wk Base roadmap length
37 wk EVE acceleration path

2. Deadline Cascade

The Act gives you two public dates. Program management gives you seven. Reading the cascade: if you are at "T-15 months" today and have not yet started Phase 2 control design, you are one week late. Phase 1 classification work should already be complete.

  DATE (ISO)      T-minus    Milestone                                               Type
  ---------------------------------------------------------------------------------------------
  2025-08-02      T-24mo     Risk management system designed (Article 9 scoping)    (past)
  2026-02-02      T-18mo     Classification + scoping decisions locked              (past)
  2026-04-16      T-15.5mo   ▶▶▶ YOU ARE HERE ▶▶▶                                   (now)
  2026-05-02      T-15mo     Architecture design complete; build started            CRITICAL
  2026-08-02      T-12mo     GPAI obligations LIVE (Articles 51-55); controls operational  STATUTORY
  2026-11-02      T-9mo      Technical documentation package complete (Annex IV)    CRITICAL
  2027-02-02      T-6mo      Conformity assessment underway (notified body engaged) CRITICAL
  2027-05-02      T-3mo      Conformity assessment substantially complete           CRITICAL
  2027-08-02      T-0        HIGH-RISK OBLIGATIONS LIVE (Articles 8-17, 26, 27)    STATUTORY
  2027-08-02+     ongoing    Post-market monitoring (Article 72) begins             CONTINUOUS

The path below assumes a team starting Phase 1 on the publication date of this document and is aggressive but achievable. A team that waits until Q3 2026 to begin will not finish in time without buying pre-built components — which is one of the two sustainable paths out of this problem.

GPAI-only organizations. Foundation-model providers who do not place a high-risk system on the market have a shorter, more urgent runway: the full four phases of Phase 2/3 must be collapsed into ~12 weeks ending by August 1, 2026. The August 2, 2026 deadline has no buffer for GPAI providers.

3. The Three Architectural Invariants

Before we describe phases, establish what must be true of the end-state. These three are non-negotiable. A compliance dossier that lacks any of them will fail a notified body review or a market surveillance audit.

Invariant 1. Deterministic Pre-Execution Gate

Every AI decision must be intercepted before it executes by a governance layer that is not itself an LLM. This has two concrete implications.

Ordering. The gate runs before the model output is delivered to the downstream system, not after. A post-hoc filter is not equivalent — Article 15 (accuracy, robustness, cybersecurity) and Article 14 (human oversight) assume the control point is in the causal path of the decision, not downstream of it.

Determinism. The gate must be a pure, side-effect-free decision function whose outputs are reproducible given identical inputs. An LLM governing an LLM is not deterministic; it cannot be explained, audited, or bounded. Notified bodies will reject it.

EVE reference implementation: core/governance/failure_mode_invariant.py (127 pillars, Hard-Fail-Shut protocol, ~175 compiled regex patterns, zero I/O, zero imports outside stdlib). core/governance/veto_core.py provides the pure pre-execution checks (check_charter, check_cognitive_locks, check_drift_budget) that are formally composable and can be firmware-compiled.

Invariant 2. Cryptographically-Signed, Hash-Chained Audit Ledger

Every decision must emit a tamper-evident record that can be independently verified by a third party (auditor, regulator, insurer) without EVE's or the vendor's participation. This requires:

EVE reference implementation: core/governance/unified_audit_bus.py + core/governance/jcs_canonicalize.py + core/governance/merkle_aggregator.py. See core/memory/deletion_proof.py for GDPR-grade deletion receipts (adjacent control, not an AI-Act control, but notified bodies look for them).

Invariant 3. Fail-Closed Defaults

When a governance component errors, when an input is unrecognized, when a state transition is ambiguous — the default action is veto, never pass-through. The engineering principle: "an uncertain system is not a safe system."

Concrete rules:

These three invariants together anchor the entire technical argument you will make to a notified body. Make them load-bearing in your architecture; do not retrofit them.

4. Phase-by-Phase Technical Roadmap

Five phases. Durations assume a dedicated team of 3 engineers + 1 compliance lead + 0.5 legal counsel working through the schedule. Larger teams can compress Phases 2 and 3; Phases 1, 4, and 5 do not parallelize well.

Phase 1 — Classification + Scoping (Weeks 1–4)

Duration 4 weeks

Entry criteria Legal and product agreement that at least one AI system in the portfolio may fall into a high-risk category.

Exit criteria A written classification memo per system, a data-flow inventory, a signed risk-management-system charter (Article 9), and a go/no-go decision from the executive sponsor.

# Activity Owner Output
1Enumerate every AI system in scope (including upstream GPAI providers you integrate)Engineering + ProductAI system inventory
2Classify each: Annex I, Annex III (and which of 8 use cases), GPAI, or out-of-scopeCompliance + LegalClassification memo per system
3For each high-risk system, identify role: provider, deployer, distributor, importerLegalRole memo
4Data-flow map — where training data comes from, where inference data goes, where logs go, retentionEngineeringData lineage diagram
5Identify all intended purposes and reasonably-foreseeable misusesProduct + ComplianceIntended-use statement
6Stand up the Risk Management System (RMS) — the living process that owns all controls (Article 9)ComplianceRMS charter
EVE acceleration: None in Phase 1 — this is reasoning work, not build work. However, EVE's core/coreguard/policies/ reference policy packs (e.g., lending_v1.py) serve as templates for how to structure control-domain scoping.

Phase 2 — Control Design (Weeks 5–12)

Duration 8 weeks

Entry criteria Phase 1 complete; architecture team assigned; compliance lead has reviewed the Annex IV requirements.

Exit criteria Sealed architecture design document covering the three invariants and the four obligation controls; signed ADRs; threat model; human-oversight UX prototype.

# Activity Owner Output
1Design the deterministic pre-execution gate — decision schema, intercept points, latency budgetEngineering (Architect)ADR-001: Pre-Execution Gate
2Design the signed audit architecture — JCS layer, HMAC key management, hash chain, Merkle rootsEngineering (Security)ADR-002: Audit Ledger
3Design fail-closed error handling across every componentEngineeringADR-003: Fail-Closed Defaults
4Design Article 14 human-oversight UX — stop/override, explanation surface, escalation workflowEngineering + UXUX prototype, HITL workflow
5Design Article 15 accuracy/robustness/cybersecurity regime — eval harness, adversarial testingEngineering (ML)Eval harness spec
6Design Article 12 record-keeping — exactly what each log entry containsEngineering + ComplianceLog schema
7Design incident response workflow (Article 73 serious incidents, 15-day reporting clock)Compliance + EngineeringIncident playbook
8Threat model the governance layer itself (what breaks the invariants?)Engineering (Security)Threat model doc
EVE acceleration: core/governance/failure_mode_invariant.py is already a validated pre-execution gate design — 127 pillars, 1000-vector adversarial gauntlet, zero false positives in the published test set. core/governance/unified_audit_bus.py + core/governance/jcs_canonicalize.py is already a reference audit architecture. Adopting these drops Phase 2 from 8 weeks to 2 weeks of integration-planning work.

Phase 3 — Build + Integration (Weeks 13–32)

Duration 20 weeks

Entry criteria Phase 2 ADRs signed; test environments provisioned; CI/CD available.

Exit criteria Four obligation controls operational in staging; internal penetration test passed; end-to-end signed decision trace demonstrable; GPAI controls live by Aug 2, 2026 (if applicable).

# Activity Owner Output
1Implement (or integrate) Article 12 record-keeping — hash-chained ledger, signed certificates, Merkle aggregationEngineeringLedger in staging
2Implement (or integrate) Article 14 human-oversight — stop button, override UX, escalation routingEngineeringHITL in staging
3Implement (or integrate) Article 15 accuracy/robustness — eval harness, adversarial test suite, post-market monitoring hooksEngineering (ML)Eval pipeline green
4Implement (or integrate) Article 26/27 deployer controls — FRIA workflow, monitoring dashboards, affected-persons notificationEngineering + ComplianceDeployer tooling
5Wire the pre-execution gate into every inference path (no bypass)EngineeringAll endpoints gated
6Build the technical-documentation generator (auto-produces Annex IV sections 1–9 from runtime state)EngineeringTechDoc generator
7Internal red-team / penetration test targeting the governance layerSecurity team or externalPen-test report
8Load testing — prove the gate's latency budget holds under production trafficEngineeringLoad test report
EVE acceleration: core/coreguard/ + the /v1/decisions/evaluate endpoint covers items 1, 5, and 6 directly. EVE Proof SDK (sdks/proof/) covers independent verification for item 1. core/governance/novel_attack_detector.py (27 TF-IDF classes) covers adversarial testing at item 3. This drops Phase 3 from 20 weeks to 8–10 weeks when the team uses EVE modules and spends the saved time on UX and integration rather than primitives.

Phase 4 — Technical Documentation + Dossier (Weeks 33–44)

Duration 12 weeks

Entry criteria Phase 3 complete; staging fully exercising all four controls; 30+ days of operational telemetry collected.

Exit criteria Complete Annex IV technical documentation package; FRIA (for deployers in public services); Quality Management System (QMS) artifacts per Article 17; Instructions for Use (Article 13); signed EU declaration of conformity draft.

# Activity Owner Output
1Assemble Annex IV sections 1–9 (system description, data, algorithms, metrics, HITL, changes)Compliance + EngineeringAnnex IV dossier
2Write the Instructions for Use (Article 13) — accuracy claims, limitations, HITL expectationsCompliance + ProductIFU document
3Assemble the QMS artifacts — policies, procedures, records, roles and responsibilities (Article 17)ComplianceQMS manual
4Draft the EU Declaration of Conformity (Article 47)LegalDoC draft
5Complete FRIA if you are a deployer in scope of Article 27 (public service, migration, law enforcement)Compliance + LegalFRIA document
6Build the runtime conformity evidence package — signed audit samples, eval reports, incident logsEngineering + ComplianceEvidence binder
7Internal conformity pre-audit — run the dossier against Annex IV line-by-lineComplianceGap report
8Remediate gaps from pre-auditAllRemediations
EVE acceleration: The core/governance/build_attestation.py module auto-generates supply-chain provenance (SLSA Level 2: git state, dependency hashes, source tree hash, Docker digest), which satisfies several Annex IV sub-requirements directly. core/resilience/trunk_certificate.py provides the signed resilience attestation that notified bodies have begun asking for as evidence of continuous control-plane health. Reduces Phase 4 from 12 weeks to 6–8 weeks.

Phase 5 — Conformity Assessment + CE Marking (Weeks 45–66)

Duration 22 weeks (6 months) — heavily dependent on notified body queue.

Entry criteria Annex IV dossier complete; pre-audit clean; selected path (notified-body route for Annex I / internal route for most Annex III).

Exit criteria CE mark; entry in EU database of high-risk AI systems (Article 71); DoC signed and filed; ongoing post-market monitoring in place.

# Activity Owner Output
1Select path: notified body (Annex I, biometrics) or internal assessment (most Annex III)Legal + CompliancePath decision
2If notified body: RFP, engagement, contractLegal + ProcurementNB engaged
3Submit dossier to notified body; respond to document requestsComplianceDossier under review
4Onsite or virtual audit (typical: 3–5 days); remediate findingsAllAudit findings closed
5If internal: formally execute Module A internal assessment per Annex VIComplianceInternal assessment
6Receive certification or positive internal assessment outcomeCertificate
7Apply CE mark; file DoC; register in EU database of high-risk AI systems (Article 71)Legal + ComplianceRegistration
8Stand up post-market monitoring (Article 72): telemetry, review cadence, incident reporting (Article 73)Engineering + CompliancePMM live
EVE acceleration: EVE cannot shorten a notified body's queue. But the EVE /coreguard and /proof products substantially reduce document-request round-trip time during NB review because every question about "how does your system actually demonstrate X" has a pre-built signed-evidence answer. Typical observed reduction: NB review compresses from 22 to 14–16 weeks.

After T-0: Post-Market Monitoring (ongoing)

Article 72 requires a documented post-market monitoring system: systematic collection of operational data, periodic review, incident reporting (Article 73: 15 days for serious incidents, 2 days for widespread infringement or critical-infrastructure disruption). This is not a phase — it is a permanent operating mode that begins the day you place the system on the market or put it into service. See §9 for how to operationalize post-market monitoring with unified audit bus, Merkle aggregator, and the resilience score engine.

5. Build vs. Buy Decision Matrix

For each of the four technical obligation controls, the realistic options are: build from scratch, buy a point solution (limited vendor market in early 2026), hybrid (build the last-mile, buy the primitive), or adopt EVE AI Core. Effort in person-weeks assumes a 3-engineer team with no prior governance-infrastructure experience.

Obligation Build (PW) Buy Hybrid EVE Option EVE Integration (PW)
Art. 12 — Record-keeping
Hash-chained ledger, JCS canonicalization, signed certificates, Merkle aggregation, root publication
20–30 Not available as a turnkey product in April 2026. Adjacent SIEMs do not provide JCS + Merkle + inclusion proofs. Build the audit schema; adopt a crypto-primitives library (HMAC/Merkle). Saves ~5 PW. unified_audit_bus.py + merkle_aggregator.py + jcs_canonicalize.py 2
Art. 14 — Human oversight
Stop/override UX, explanation surface, escalation routing, audit of oversight events
15–20 Partial: several vendors offer "human-in-the-loop" annotation UX, but none integrate cleanly with a pre-execution gate. Build the UX; use EVE for the decision-ledger integration. EVE Proof SDK + action_registry.py (3-phase propose/approve/execute workflow) 4
Art. 15 — Accuracy, robustness, cybersecurity
Eval harness, adversarial test suite, continuous monitoring, ingress/egress filters
25–40 Limited: Red-teaming vendors exist but most do not produce persistent signed evidence suitable for a conformity dossier. Buy red-teaming as a service; build the persistent evidence pipeline. failure_mode_invariant.py (127 pillars) + novel_attack_detector.py (27 TF-IDF classes) + resilience_score.py 4
Art. 26/27 — Deployer controls + FRIA
Monitoring dashboards, affected-persons notification, FRIA workflow, data-subject rights tooling
12–18 Some GRC platforms offer FRIA templates. None wire to a live gate. Buy templates; build the runtime integration. core/coreguard/ endpoint + deletion_proof.py (data subject erasure) 3
Totals 72–108 PW build 13 PW integration

The build-from-scratch path for a 3-engineer team is approximately 24–36 calendar weeks of engineering alone. The EVE integration path is approximately 4–5 calendar weeks. The ~20-week difference is the dominant determinant of whether an organization starting today hits the August 2, 2027 deadline.

6. Cost Model (Micro / Mid / Enterprise)

The numbers below are internal-cost estimates. Actual cost varies significantly by jurisdiction, engineer seniority, and existing tooling. Figures in USD; conformity assessment fees are in EUR as quoted.

Scenario A — Micro (1 AI product, solo founder + 1–2 contractors)

Build Path
Roll-your-own
Engineering (55 PW × $4k)$220k
Compliance lead (12 PW)$42k
Legal counsel (6 PW)$30k
Internal pen-test$25k
EVE licensing
Conformity (internal)$5k
Annex III total ~$322k
Annex I (NB): ~$352k–$390k
EVE Path
Acceleration
Engineering (8 PW)$32k
Compliance lead (8 PW)$28k
Legal counsel (4 PW)$20k
Pen-test (less surface)$15k
EVE licensing (12 mo)$24k–$48k
Conformity (internal)$5k
Annex III total ~$124k–$148k
Annex I (NB): ~$154k–$213k
Delta
Savings

Savings of approximately $174k–$198k on the Annex III internal-route. The dominant saver is engineering: 55 PW of governance-primitive building collapses to 8 PW of integration when you do not have to invent JCS, Merkle, Hard-Fail-Shut, and a 127-pillar enforcement list from first principles.

At a solo-founder cost structure, the EVE path also shortens calendar time enough to matter for runway.

Scenario B — Mid-Market (5–50 engineers, 2–4 AI products, 1 regulated)

Build Path
In-house program
Engineering (180 PW)$720k
Compliance (2 FTE × 15 mo)$450k
Legal counsel$120k
Pen-test + red-team$80k
Conformity (NB, 1 product)EUR 80k–120k
Internal assessment (3)$45k
Total ~$1.5M–$1.6M
EVE Path
Licensed acceleration
Engineering (30 PW integration)$120k
Compliance team$300k
Legal counsel$80k
Pen-test$50k
EVE licensing (15 mo)$180k–$360k
Conformity assessmentsEUR 80k–120k + $45k
Total ~$860k–$1.15M
Delta
Savings

Savings of approximately $400k–$700k, and — more importantly — a faster path through the notified body queue. In Q1 2027 the marginal calendar week is worth more than the marginal dollar.

The compliance and legal headcount does not collapse, because those teams still have to run FRIA, Instructions for Use, QMS, and the incident-response program. What collapses is the build effort.

Scenario C — Enterprise (50+ engineers, regulated industry, 5+ AI products)

Build Path
Platform team
Engineering (6–8 FTE × 18 mo)$2.2M–$3.0M
Compliance (4–6 FTE)$1.5M–$2.2M
Legal + external counsel$400k–$700k
Third-party audit + pen-test$200k–$400k
Multi-NB engagementsEUR 300k–800k
Total ~$5M–$7.5M
EVE Path
Enterprise license
Engineering program$800k–$1.2M
Compliance + risk$1.0M–$1.5M
Legal$300k–$500k
Third-party audit$150k–$300k
EVE enterprise (24 mo)$600k–$1.4M
Multi-NB engagementsEUR 300k–800k
Total ~$3.5M–$5.5M
Delta
Savings

Savings of approximately $1.5M–$2.0M on a base spend of five to seven million, plus the reduction in execution risk that comes from not building governance primitives while also shipping product.

At enterprise scale the audit-evidence substrate is reused across every product line, so the licensing cost amortizes quickly.

Notified body rates are rising. Market signal as of Q1 2026: EUR 30k–60k for a single Annex III conformity with a small product; EUR 80k–150k for Annex I or biometric systems; EUR 150k–400k+ for complex multi-model dossiers. Availability tightens significantly through 2026 as demand ramps. Engage a notified body now if you intend to use one.

7. Risk Flags That Kill Schedules

These are the failure modes that most commonly cause a compliance program to slip past August 2, 2027. Every one of them has been observed in adjacent regulatory programs (GDPR, DORA, HIPAA).

Risk 1 · Architectural
Logging is not tamper-evident.
Typical impact: +8–16 weeks
Discovered in Phase 4 when the notified body asks for a hash-chain demonstration. Requires a backend rewrite. Mitigation: design JCS + HMAC + hash-chain in Phase 2, not Phase 4. Adopt core/governance/unified_audit_bus.py if time-constrained.
Risk 2 · Architectural
LLM-based governance wrapper is presented as the control.
Typical impact: +12–20 weeks (architectural rebuild)
The notified body (correctly) rejects it under Article 15 because it is non-deterministic and non-reproducible. Mitigation: Invariant 1 is non-negotiable. The pre-execution gate must be deterministic. Full stop.
Risk 3 · Process
FRIA effort underestimated for deployers in public services.
Typical impact: +4–8 weeks
Applies to migration, law enforcement, essential private services. Mitigation: start FRIA drafting in Phase 2, not Phase 4. Assign a named compliance owner.
Risk 4 · Supply-side
Notified body queue overwhelm in Q1 2027.
Typical impact: +8–16 weeks of waiting
Market surveillance authorities and notified bodies have publicly signalled demand will peak January–April 2027. Mitigation: engage notified body by October 2026. Have contracts signed by December 2026.
Risk 5 · Standards
Harmonized standards not yet finalized.
Typical impact: +2–6 weeks of rework per affected control
CEN-CENELEC JTC 21 work under Article 40 is releasing on a rolling basis through 2026. A standard you wrote to may be superseded. Mitigation: track CEN/CENELEC JTC 21 releases weekly. Build to the published-standard latest-version and version-pin.
Risk 6 · Supply chain
Upstream GPAI provider non-compliance cascades.
Typical impact: +4–12 weeks
You integrate a foundation model whose provider is not compliant with Articles 51–55 by August 2, 2026. You inherit the defect. Mitigation: diligence every upstream GPAI supplier. Contractual representations about Annex XI. Have a fallback model ready.
Risk 7 · Documentation debt
Annex IV narratives written only in Phase 4.
Typical impact: +6–10 weeks of writing
Engineers wrote code but not the narratives during Phases 1–3. Mitigation: require Annex IV fragments as exit criteria for every ADR and every merged PR. Auto-generate what can be auto-generated.
Risk 8 · UX
Human-oversight UX is treated as a button, not a workflow.
Typical impact: +4–8 weeks
Article 14 requires meaningful oversight — including the ability to override, halt, monitor performance, and escalate. A stop button alone fails. Mitigation: treat HITL as a first-class product surface in Phase 2 design. User-test it.
Risk 9 · Ongoing
Post-market monitoring not designed before go-live.
Typical impact: +3–6 weeks; potential certificate suspension
Article 72 is an ongoing obligation; bolting it on after certification triggers a QMS finding on the next audit. Mitigation: build PMM telemetry in Phase 3 as part of the runtime.
Risk 10 · Regulatory
Incident reporting clock misunderstood.
Typical impact: regulatory enforcement risk
Article 73 requires reporting within 15 days of becoming aware (2 days for widespread or critical-infrastructure incidents). Many teams assume calendar-quarter cadence. Mitigation: put the 15/2-day clock into the incident playbook in Phase 2.

8. The Acceleration Path — If You Have EVE AI Core

The base roadmap totals approximately 66 weeks (Phases 1–5, weeks 1–66). Integrating EVE AI Core modules compresses the phases as follows:

Phase Base (weeks) With EVE (weeks) Delta
1. Classification + Scoping44−0
2. Control Design82−6
3. Build + Integration208−12
4. Technical Documentation127−5
5. Conformity Assessment2216−6
Total6637−29

The 37-week path begins today (week 0 = April 16, 2026) and lands at week 37 = January 1, 2027 — which leaves a 31-week buffer before the high-risk deadline. In practice that buffer is absorbed by notified body queue and by remediation cycles that are not fully predictable.

The 37-week path assumes:

Where the savings come from:

9. Monitoring After Compliance

Article 72 post-market monitoring is permanent. It is the operating mode, not a phase. The compliance program does not end on August 2, 2027; it becomes steady-state.

Four obligations persist:

  1. Operational telemetry collection. Accuracy, robustness, drift, and incident data must be continuously collected against a documented monitoring plan. EVE support: core/resilience/resilience_score.py provides a composite 0–100 score across governance, identity, behavioral, and governance sub-layers; core/resilience/trunk_certificate.py provides signed snapshots suitable for auditor verification.
  2. Periodic review. The RMS must be reviewed at minimum annually (more often if the system changes materially). Every review produces a signed record. EVE support: the unified audit bus + Merkle aggregator produces a quarterly signed Merkle root that summarizes all decisions for the quarter; regulators can verify inclusion of any single decision without downloading the full log.
  3. Incident reporting (Article 73). Serious incidents: 15 days from awareness. Widespread infringement or critical-infrastructure disruption: 2 days. Reporting is to the competent authorities of the member states affected. EVE support: the audit bus emits severity=serious events that can be wired to an incident reporting workflow.
  4. Substantial modification review. Material changes to the system trigger re-assessment. Whether a change is "substantial" is a judgment call that needs a documented policy. EVE support: the core/governance/build_attestation.py module detects git-level and dependency-level changes automatically and can trigger substantial-modification review.

Continuous compliance is cheaper than periodic compliance if the audit evidence is continuously signed and continuously verifiable. The upfront investment in the three architectural invariants pays off across every audit cycle for the life of the system.

10. Close — What to Do This Week

You have roughly 15.5 months to the high-risk deadline. The notified body queue compresses that to 9 months of useful time. This roadmap's base path is 66 weeks; the EVE-accelerated path is 37 weeks. Both are feasible from today. Neither is feasible from Q4 2026.

This week.

Where to engage EVE AI Core

Pre-Execution Gate
CoreGuard
Deterministic decision enforcement engine with a POST /v1/decisions/evaluate endpoint suitable for integration as the Invariant 1 pre-execution gate.
Signed Audit Ledger
EVE Proof
Volume-priced decision certification and independent verification SDK for the Invariant 2 audit ledger and conformity evidence package.
Enterprise License
Governance Licensing
127-pillar failure-mode-invariant module, unified audit bus, Merkle aggregator, resilience engine, and related governance primitives with deployment support.
Reference · Part 2
Obligation Mapping
For every Article, the architectural property required to satisfy it and the EVE component that provides it. Audit-ready.
Reference · Part 1
Risk Classification
Determine which tier applies to your system under Annex III. Classification drives every downstream decision on this roadmap.
Direct Engagement
Schedule Assessment
A scoping session mapping your specific deployment to the obligations above and identifying which EVE AI Core components fit your existing stack.

The document count for this compliance series ends here. The deadline clock does not. If you want a deeper pass — mapping your specific deployment to the Articles, scoping the conformity-assessment work, and sequencing the phases against your release calendar — schedule a compliance architecture review. August 2, 2027 is fifteen and a half months away. Phase 1 was supposed to be done two weeks ago. There is no runway left for delay.

Legal notice. This document is informational and does not constitute legal advice. Compliance strategy must be validated by qualified counsel and, where applicable, a notified body. EVE AI Core references describe the reference architecture as of the publication date; specific module behavior may evolve. For the authoritative source on EVE modules, see the repository at core/governance/, core/resilience/, core/coreguard/, and sdks/proof/.

End of Roadmap · Compliance Series Part 4 of 4