Version 1.0 · Issued 24 May 2026 · Self-authored. Not yet solicitor-reviewed; planned upgrade once revenue funds external review (target: month 3 post-launch). Comments to methodology@nuregroup.com.

NureComp Article 4 Methodology

This document explains how the NureComp platform — the AI Compliance Operating System operated by Nure Group Limited — designs, delivers, evidences, and maintains training that meets the requirements of Article 4 of the EU Artificial Intelligence Act. It is the foundation document that supports every certificate and every evidence pack the platform generates.

It is structured in twelve sections, mirroring the sequence in which a compliance officer or external auditor would interrogate the platform.

1. Scope and definitions
2. Article 4 in operational terms
3. Design principles
4. Curriculum architecture
5. Role-mapping and personalisation
6. Assessment design
7. Evidence model
8. Audit trail and tamper resistance
9. Governance and content lifecycle
10. Privacy posture (UK GDPR overlay)
11. Limitations and what this does not certify
12. Versioning and change control

1. Scope and definitions

This methodology applies to all training delivered through NureComp under the domain identifier ai_literacy, including the core curriculum, tool-specific micro-modules, role overlays, and sector overlays defined in Doc 03 of the platform specification. The platform's underlying data model supports additional compliance domains (UK GDPR refresher, cyber awareness, AML, etc.) — those domains will carry their own methodology documents when launched.

Defined terms used in this document:

• Article 4: Article 4 of Regulation (EU) 2024/1689 (the EU AI Act), which requires providers and deployers of AI systems to take measures to ensure a sufficient level of AI literacy of their staff and other persons dealing with the operation and use of AI systems on their behalf.
• Deployer: A natural or legal person using an AI system under their authority, except where the AI system is used in the course of a personal non-professional activity. (Art. 3(4))
• Provider: A natural or legal person that develops an AI system or has it developed and places it on the market or puts it into service under its own name or trademark. (Art. 3(3))
• Learner: An individual completing training inside NureComp on behalf of a customer organisation (the deployer).
• Customer organisation: The legal entity that has subscribed to NureComp and is the deployer responsible for ensuring its staff meet Article 4.
• Training matrix: The personalised set of modules assigned to each learner based on role, discovered AI tool usage, and sector.
• Evidence pack: The on-demand artefact (PDF + CSV + manifest) the customer can produce for regulators, insurers, or supplier due-diligence requests.

Where this document refers to “sufficient” AI literacy or “appropriate” training, the meaning is that defined by Article 4 itself: training taking into account the technical knowledge, experience, education, and training of the persons concerned, and the context the AI systems are to be used in. This methodology operationalises that language.

2. Article 4 in operational terms

The text of Article 4 (Regulation (EU) 2024/1689) reads:

Providers and deployers of AI systems shall take measures to ensure, to their best extent, a sufficient level of AI literacy of their staff and other persons dealing with the operation and use of AI systems on their behalf, taking into account their technical knowledge, experience, education and training and the context the AI systems are to be used in, and considering the persons or groups of persons on whom the AI systems are to be used.

We read this as imposing six concrete obligations on the deployer organisation:

1. Identify which staff are “dealing with the operation and use of AI systems”. A deployer cannot make literacy decisions without first knowing who uses what AI.
2. Tailor training to technical knowledge, experience, education and training.Generic, one-size-fits-all content does not satisfy “taking into account.”
3. Tailor training to context of AI use.What a solicitor needs to know about Lexis+ AI is different from what a recruiter needs to know about their ATS's AI scoring.
4. Consider downstream effect(“persons or groups of persons on whom the AI systems are to be used”). Higher-risk contexts (recruitment, credit, education, healthcare) require deeper coverage.
5. Take measures “to their best extent.”The standard is reasonableness in light of the organisation's resources, not perfection.
6. Be able to demonstrate compliance. The Act is enforced through documentation; an undocumented training programme provides no defence to a regulator.

NureComp translates each of these into a specific platform capability, summarised below and detailed in the subsequent sections.

3. Design principles

The platform is designed against six principles. Every architectural decision in Docs 01–25 of the build specification is traceable to one of these.

3.1 Discovery before instruction

Training assignments are not made until the organisation knows what AI its staff use. Generic baseline-only training is technically possible but explicitly discouraged in the onboarding flow — the platform's empty state nudges the admin toward running discovery first.

3.2 Personalisation by default

Every learner's training matrix is computed from three signals: role, discovered tool usage, sector. No two learners in the same organisation get an identical matrix unless their role and tool usage are identical.

3.3 Evidence is the deliverable

Training without records does not constitute compliance under Article 4 (or under the broader Article 99 enforcement regime that backs it). The platform treats the evidence pack and the live Readiness Score as the primary deliverables; the training content is the means by which evidence is generated.

3.4 Privacy by minimisation

For SSO-mode tenants (Pro and Enterprise) the platform stores zero staff personally identifiable information. Training records link to pseudonyms derived via HMAC of the IdP subject claim plus the customer organisation's identifier and a server-held secret. This satisfies UK GDPR's data minimisation principle while preserving the audit trail.

3.5 Append-only audit trail

Every state-changing event is recorded in an append-only audit log. Each row is cryptographically signed (SHA-256) and chained to its predecessor. The chain provides tamper evidence without external trust anchors.

3.6 Continuous, not periodic

Article 4 is in force continuously. The platform's Continuous Evidence Dashboard and Monitor screen treat compliance as a state, not an event. Evidence is regeneratable at any moment.

4. Curriculum architecture

The curriculum is structured as a four-layer matrix. Every learner completes Layer 1 (Core); the other layers depend on personalisation signals.

Layer 1 — Core (always assigned)

Five modules, ~50 minutes of structured learning, ~1.25 CPD hours total:

1. What AI is and isn't (8 min, 0.25 CPD hours)
2. The EU AI Act in 15 minutes (15 min, 0.25 CPD hours)
3. Responsible use at work (12 min, 0.25 CPD hours)
4. Your responsibilities (8 min, 0.25 CPD hours)
5. Sector application (general) (7 min, 0.25 CPD hours) — replaced by a sector-specific variant when a sector overlay is assigned

Layer 2 — Tool overlays (assigned per discovered tool)

One module per common AI tool, written to address that tool's specific data-handling profile, failure modes, and practical rules. At launch:

• ChatGPT (12 min, 0.25 CPD hours)
• Microsoft Copilot (12 min, 0.25 CPD hours)
• Google Gemini (10 min, 0.25 CPD hours)
• Claude (10 min, 0.25 CPD hours)
• Perplexity (8 min, 0.25 CPD hours)
• GitHub Copilot (12 min, 0.25 CPD hours)

Sector-specific tools (Lexis+ AI, Harvey, Westlaw Edge, accountancy AI, ATS AI) ship in production cycle 2.

Layer 3 — Role overlays (one per learner)

• Staff — the all-staff baseline overlay (10 min, 0.25 CPD hours)
• Manager — oversight responsibilities (12 min, 0.25 CPD hours)
• Compliance / Legal / Risk — deeper material (15 min, 0.25 CPD hours)
• HR — Annex III #4 high-risk treatment (12 min, 0.25 CPD hours)
• Refresher — annual update for previously-certified learners (10 min, 0.25 CPD hours)

Layer 4 — Sector overlays (one per tenant; optional for individuals)

Replaces the generic Module 5 with a sector-specific Module 5, addressing the regulatory context the learner's work most commonly engages:

• UK Legal Practice — SRA principles, professional negligence, confidentiality
• UK Accountancy — ICAEW Code of Ethics, audit independence
• UK Recruitment — Annex III #4 obligations, Equality Act 2010
• UK Financial Services — FCA Consumer Duty, SMCR, Annex III #5
• UK Marketing & Creative — Article 50 transparency, IP, advertising standards

Total structured learning per learner

A typical Pro-tier learner with two assigned tools and the Staff role overlay completes ~85 minutes of structured learning across 8 modules, earning approximately 2.0 CPD hours. A Compliance lead in a regulated sector with broader tool usage may earn 2.5–3.0 CPD hours. A non-regulated learner with no tool overlays earns ~1.0 CPD hours.

The CPD hour values are documented in the separate CPD Methodology document and are calculated independently of the time any individual learner actually takes to complete a module.

5. Role-mapping and personalisation

The auto-assignment algorithm runs at admin request from the Map screen and re-runs automatically on three triggers: a new AI tool surfaces in the Registry, a learner's role changes, or an annual currency check identifies an expiring certificate.

The algorithm, for each learner L within a customer organisation:

1. Assigns the five Layer 1 (Core) modules to L.
2. For each AI tool that L's pseudonym recorded in the most recent discovery survey: if a Layer 2 (tool) module exists for that tool, assign it. Unknown tools surface as “Pending classification” in the admin Registry and do not trigger an assignment until classified.
3. Looks up L's role from the customer's SSO group claim, HRIS field, or admin-set role tag. Assigns the corresponding Layer 3 (role) overlay.
4. Reads the customer's registered sector. If a Layer 4 (sector) overlay exists for that sector, replaces L's generic Module 5 with the sector-specific variant.

Module assignments are idempotent: re-running auto-assign adds only the modules L does not yet have. The assignment record stores the source (core, tool, role,sector, manual, or auto_renewal) so the evidence pack can later show which modules were assigned because of which discovered tool or role signal.

Coverage of the “best extent” standard

The platform's Readiness Score, surfaced on the admin Evidence dashboard, captures coverage as a single weighted metric:

• 30% — proportion of staff with a current core certificate
• 30% — proportion of staff with all assigned tool modules complete
• 20% — proportion of staff with a current AUP acknowledgment (within 12 months)
• 20% — evidence pack freshness (regenerated within last 30 days)

A score of 100 indicates the deployer has, in our view, taken every measure NureComp surfaces toward Article 4 readiness. A score below 80 indicates a documented gap; the dashboard names the gap explicitly.

6. Assessment design

Article 4 sets an outcome (“sufficient AI literacy”) and is silent on assessment mechanics. NureComp adopts a two-tier assessment regime widely accepted as evidence of comprehension in regulated professional contexts:

Module quizzes

Each Layer 1 module concludes with a five-question knowledge check sampled from the module's question pool. Pass mark: 80% (4 of 5). Unlimited retries. Question sampling is deterministic per learner-attempt-day so that immediate re-takes encounter the same questions (avoids penalising mid-session retries) but a fresh cohort of questions surfaces after a 24-hour window.

Final scenario-based assessment

After all Layer 1 modules are passed, the learner takes a 15-question final assessment sampled from a broader pool of 30+ scenario-based items. Pass mark: 80% (12 of 15). Two attempts allowed per 24-hour window; failure of the second attempt imposes a 24-hour cooldown before further attempts.

Anti-cheating measures

• Question selection is deterministic per learner+module+attempt+date via HMAC seed.
• Answer options are independently shuffled per question per attempt.
• Module reading time is gated: the quiz button does not enable until the learner has scrolled to 90% of content height AND spent at least 60% of the estimated reading time, whichever is later. Time-on-page is tracked via the visibilitychange event, so off-tab time does not count.
• The final assessment timer is server-tracked, not client-tracked.

Why 80%, not 100%

100% pass marks invite memorisation rather than comprehension. 80% leaves room for genuine misunderstanding of a single question without negating the broader learning. This is consistent with professional CPD assessment conventions in the UK (Bar Standards Board, SRA, ICAEW).

7. Evidence model

The platform produces three distinct evidence artefacts.

7.1 Per-learner certificate

Issued at the moment a learner passes the final scenario-based assessment. Carries:

• Learner's name (taken from the live IdP claim at the moment of certificate generation; never persisted)
• Customer organisation name and Companies House number (if registered)
• Course title and version
• Issue and expiry dates (12-month validity)
• Final assessment score (e.g. “passed at 14/15”)
• Per-module CPD hour breakdown
• Total CPD hours earned
• Unique verification code (XYZ-NNNN-AB format)
• QR code linking to the public verification page
• CPD claim text (“designed to meet CPD principles”); CPD Provider line where issued
• Methodology document reference (this URL)

The certificate PDF is generated on demand from the underlying database records, never stored as a binary blob. Regeneration always produces an artefact consistent with the current organisation name and current verification status of the certificate.

7.2 Evidence pack (ZIP)

Generated on admin request, expires from temporary storage after 7 days, regeneratable at any time without charge. Contains:

1. Cover letter PDF — date range, organisation, signatory, contents listing
2. Methodology PDF — this document, fixed to the version that was current at pack generation
3. Curriculum summary PDF — module list, learning outcomes, durations, CPD hour values
4. Staff completion summary PDF — per-learner status table
5. Individual certificates folder — one PDF per completed learner
6. Training records CSV — machine-readable raw data
7. Audit log CSV — filtered to the date range, with hash chain prefix on each row
8. Verification manifest JSON — schema-versioned for automated processing

7.3 Public verification page

Every issued certificate is independently verifiable at /verify/[code]. The page:

• Confirms or denies that the code matches an issued certificate
• Shows status (Valid / Expired / Revoked)
• Shows course title and version, organisation name, issuance and expiry dates, score
• Does NOT show the learner's name (privacy; identity-binding sits with the customer organisation)
• Is rate-limited (10 requests per IP per minute)
• Every successful verification is recorded in the audit log

8. Audit trail and tamper resistance

The audit log is the foundation under everything else in this methodology. If the log were modifiable, the certificate and evidence pack would be defensible only to the extent of the platform operator's integrity. The hash chain elevates them to a cryptographic standard.

Action vocabulary

Actions are drawn from a closed canonical vocabulary of ~70 strings, namespaced <domain>.<verb> (e.g. learner.module_completed,certificate.issued, evidence_pack.downloaded). Free-form actions are not accepted. This makes audit-log analysis deterministic across customers and over time.

Hash chain

Every audit row carries two hash fields:

• prev_hash — the self_hash of the immediately prior row
• self_hash — SHA-256 of prev_hashconcatenated with a canonical-JSON serialisation of the row's fields (org_id, actor_type, actor_id, action, target_type, target_id, metadata, IP, UA, and timestamp)

Modifying any historical row breaks the chain at and after that point — a verifier can compute the expected chain from any starting row and detect mismatches.

Retention

Audit-log rows are retained for six years from creation, in line with the UK Limitation Act 1980 (which governs the longstop period for most contract and tort claims) and longer than the typical EU AI Act enforcement window. The retention is calibrated to defend against retrospective regulator inquiries.

What is NOT in the audit log

We deliberately omit free-text learner reflections, learner-trainer chat content, and any payload that could constitute sensitive personal data beyond the strict minimum needed to evidence training. The audit log is designed to be auditable, not surveillance-grade.

9. Governance and content lifecycle

The training content is governed under the following cycle:

9.1 Authoring

Initial content is authored by the platform operator with subject-matter consultation from senior UK legal and compliance practitioners. Every module carries a version number and a published-at timestamp.

9.2 Solicitor review (in flight)

At the time of writing this document, content has not been independently reviewed by a UK solicitor with AI and data-protection specialism. Engagement of independent counsel for full review is budgeted for the first quarter post-launch and is the highest-priority improvement to the credibility floor of the platform. Until that review completes, every customer-facing surface carries a visible “DRAFT pending solicitor review” marker on the published content.

9.3 Quarterly review

Once initial review completes, content is reviewed quarterly. Reviews respond to:

• Regulator activity (EU Commission AI Office FAQs, UK regulator guidance)
• Case law (e.g. Ayinde v Haringey, Mata v Avianca)
• Material AI Act commencement events (e.g. Annex III enforcement, Article 50 watermarking)
• Customer-surfaced gaps or errors

Each review produces either a content patch (version increment with explicit changelog) or a full module replacement (major version bump). Already-issued certificates are not invalidated by content updates; new certificates are issued against whatever version was current at the time of certification.

9.4 Continuous regulatory tracking

The platform operator monitors EU AI Office publications, national competent authority output, sector regulator guidance (SRA, ICAEW, FCA, ICO, REC, CIPD), and selected industry commentary. A change that materially affects content triggers an out-of-cycle review.

10. Privacy posture (UK GDPR overlay)

Article 4 sits on top of, not instead of, UK GDPR. The platform's privacy design follows the data minimisation principle (Art. 5(1)(c)) and the principle of integrity and confidentiality (Art. 5(1)(f)).

10.1 Roles

For training data, NureComp acts as a processoron behalf of the customer organisation (controller). For platform marketing, account management, and the platform's own staff data, NureComp is the controller.

10.2 Pseudonymisation

SSO-mode tenants' staff are represented only by an HMAC-derived pseudonym HMAC(secret, org_id + ":" + sso_subject). The platform server holds the secret. The IdP holds the mapping back to the identified individual. This is a strong pseudonymisation under UK GDPR Article 11.

10.3 What we store

For SSO tenants: pseudonym, training records, certificates, audit timestamps. No names, no emails.

For email-mode tenants (Starter): name + email + training records, under standard processor terms.

10.4 What we do not store

Learner reflections are stored against the pseudonym and are visible only to the learner who wrote them; even an authenticated admin cannot read them. Per-learner verification queries are rate-limited and audited but never linked to specific verifier identities (the verifier is anonymous by design).

10.5 International transfers

All processing is in the EU jurisdiction. Where any sub-processor sits outside the EU (e.g. Anthropic for optional AI features in Pro/Business tiers), the transfer is governed by EU Standard Contractual Clauses or the UK International Data Transfer Addendum.

Full detail in the Privacy Policy and Data Processing Addendum.

11. Limitations and what this does not certify

The credibility of this methodology depends on honest framing of its limits. Specifically:

• Not legal advice. This document and the NureComp platform do not constitute legal advice. Customers must use the platform alongside, not instead of, qualified legal and compliance advisors.
• Does not certify any specific regulatory outcome.A NureComp certificate evidences that a named or pseudonymous individual completed a specified curriculum and assessment. It does not warrant that the customer organisation as a whole is “Article 4 compliant” — that judgement remains with the competent regulator.
• Does not cover Articles 9–14, 26, etc. These articles impose substantial deployer obligations on high-risk AI systems (Annex III) that go beyond literacy training. NureComp surfaces high-risk uses in the Discovery Registry but does not, at launch, deliver the full Article 9–14 deployer programme (risk management system, data governance, technical documentation, human oversight, accuracy and robustness testing, post-market monitoring). Customers with Annex III systems must address those obligations through separate processes.
• Does not provide assurance over customer-supplied data. Discovery survey results depend on staff self-report; staff under-reporting of unsanctioned use is a known limitation, mitigated by the optional browser-extension discovery available at the Enterprise tier.
• Self-authored at version 1.0. This document will be reviewed and re-issued by independent UK counsel as part of the first solicitor-engagement cycle. The version field at the top of this document identifies which iteration a given customer pack contains.

12. Versioning and change control

This document carries a version number and an issue date. Both are surfaced on every page of the evidence pack that references it.

Material changes — new sections, removed obligations, regulatory re-mappings — increment the major version. Editorial revisions increment the minor version. The current version is 1.0, issued 24 May 2026.

Previous versions remain available on request to methodology@nuregroup.com.

Issued by Nure Group Limited. NureComp is a trading name of Nure Group Limited. This document is published at /methodology and referenced from every evidence pack and every certificate generated by the platform.