Training Record methodology

1. Header — learner name, email, role profile, record date, Keypra imprint.
2. Article 4 summary line — a single sentence a DPA can read: "As of {date}, {name} has completed {N} hours of AI literacy training appropriate to their role as {role}."
3. Training time — total hours, broken down by surface (Lessons, Live classroom, Academy sessions, Practice Lab, Assessments).
4. Role appropriateness — the curricula required for the learner's role, and which have been completed.
5. Retention checks — 7 / 30 / 90-day results after each completed curriculum.
6. Consent & disclosures — recent legal acceptances (Terms, Privacy, DPA, AI-graded assessment consent).
7. Integrity footer — a SHA-256 checksum of the underlying payload and the generation timestamp.

Hours accrue passively. While the learner has a Keypra learning surface open, the browser sends a small heartbeat every 30 seconds recording that the tab is foreground and non-idle. Idle is defined as no keyboard, mouse, scroll or touch activity for 60 seconds.

Heartbeats are batched and written every two minutes to training_time_log, capped at a maximum of 15 minutes per row (defensive; the client never sends more). Time in background tabs, on other apps, or while genuinely idle is not counted.

Only aggregate hours are visible to the learner's organisation, via theget_learner_training_hours RPC. Per-row session data is never exposed to employers — this is enforced at the database policy level and reflects our employer-side classification ban.

Article 4 explicitly requires that literacy training is appropriate to the context in which staff use AI. We operationalise this with a mapping of job function ( Legal, Finance, Sales, HR, Ops, Executive, Other) → the specific Keypra lessons required for that function. Keypra publishes sensible defaults; organisations can override the mapping for their own tenant via role_curriculum_requirements.

The learner sets their own role profile from the Training Record page. Organisations can set it during member onboarding. If no role is set, the record still generates but flags the appropriateness section as unevaluated (this itself is useful evidence — you can tell who to remind).

The record's underlying payload is serialised with sorted keys and hashed with SHA-256. The hash excludes the generation timestamp but includes everything else — so two independent generations on the same "as of" date for the same learner produce identical checksums. Tampering with any field flips the hash.

Every generation is written to an append-only audit table (training_record_exports) recording who generated the record, when, the checksum, and the storage path. Learners see their own history; org admins see their members' history; Keypra staff see everyone's.

Generated PDFs are stored in a private bucket and served via short-lived signed URLs (14 days). The audit ledger is retained for the life of the account. On account deletion, PDFs and time-on-task rows cascade delete; the audit ledger is preserved only in pseudonymised form (subject user id nulled).

• It is not a certification. Keypra is not an accredited body under EU regulation.
• It is not a mastery score. Consistent with our employer-side classification ban, no per-person AI mastery rating is published to employers.
• It does not attest to conduct. It records completions, hours, and consent — not what the learner did with the training.