Skip to content
RODMENA
Menu

Learning records

RODMENA LRS

Coming soon

The evidence store for learning: what happened, recorded once, kept exactly.

Contact us

RODMENA LRS is a Learning Record Store: it receives records of learning activity in the xAPI format, stores them unchanged, and returns them through the standard xAPI query interface. It passes every test in the ADL LRS Conformance Test Suite for xAPI 1.0.3 and xAPI 2.0. Every customer’s records are isolated from every other customer’s inside the database itself. Record contents are encrypted at rest, and learner identifiers are stored only in a keyed, pseudonymous form. Stored records cannot be altered; a learner’s personal data can be erased on request, and each erasure is written to a tamper-evident log.

Who it is for. Learning platforms and training providers that need a conformant place to keep learner activity records. It is a back-end service: products are built on it and call it from their servers. Learners and browsers do not talk to it directly. REES is its first consumer.

Status
Coming soon
Licence
Proprietary. Copyright RODMENA LIMITED, all rights reserved.
Conformance
1,365 xAPI 1.0.3 conformance tests, all passed
1,435 xAPI 2.0 conformance tests, all passed
Verified 23 September 2026
Tags
xAPILearning recordsConformanceMulti-tenantData protectionAudit trail

Technical specification

Stated for a technical assessor. A row with no measured value is left out.

Standards

xAPI 1.0.3
ADL Experience API Specification, version 1.0.3
xAPI 2.0
IEEE 9274.1.1-2023
Version selection
Per request, by the X-Experience-API-Version header. 1.0.x and 2.0.x are accepted; a missing or unknown version is refused with 400.
Conformance suite
ADL LRS Conformance Test Suite, commit 5bc232d, last run 23 September 2026
Conformance result
xAPI 1.0.3: 1,365 of 1,365. xAPI 2.0: 1,435 of 1,435.
Beyond the suite
Requirements the suite states it does not test are each covered by a dedicated check. Six suite tests that assert nothing were identified and covered separately.
Deliberately absent
OAuth 1.0, as deprecated. Cross-origin browser access, because consuming products call the service from their own servers. Certificate-chain trust for signed statements: the signature is verified cryptographically, and the signer certificate is not validated against a trust chain.

Interface

Resources
Statements, State, Activity Profile, Agent Profile, Activities, Agents and About, with HEAD on every GET route.
Authentication
HTTP Basic with credentials the service issues. 256-bit secrets, stored only as a keyed verifier. Unknown, disabled and expired credentials receive byte-identical 401 responses.
Alternate Request Syntax
Supported under 1.0.3 and refused under 2.0, as that specification requires.
Signed statements
JWS with RS256, RS384 and RS512, verified when a certificate is included.
Attachments
multipart/mixed, matched by SHA-2 hash. 5 MiB per attachment and 1 MiB per statement body, both configurable.
Paging
Signed stateless cursors that stay valid across a restart, with the xAPI consistency header on every statements response.
Idempotency
Re-sending an identical statement id is accepted without duplication. A conflicting one is refused with 409.
Rate limiting
Per credential, with a separate budget for failed authentication per client address.
Interface description
The xAPI specification itself.

Isolation and security

Tenant isolation
PostgreSQL row-level security, enabled and forced on every table holding tenant data. The application database role owns nothing and cannot bypass it. Each transaction takes its tenant from the authenticated credential alone.
Isolation, enforced
A catalogue test fails the build if any tenant table, or any partition created at runtime, lacks the policy.
Encryption at rest
AES-256-GCM on statement bodies, documents, attachments, activity definitions and credential identities, under a per-record key derived with HKDF-SHA256.
Ciphertext binding
Each ciphertext is bound to the identity of its row, so it cannot be moved to another row and still decrypt.
Key custody
Three keys held outside the database, in 0600 key files or the environment. There is no default key, and the service refuses to start without them.
Key rotation
The index key rotates by an offline, resumable rekey. Rotating the credential key means reissuing credentials. The data key is not yet rotatable, though the storage format already records the key id, so rotation will need no data migration.
Learner identifiers
Held only as HMAC-SHA256 tokens under a per-tenant key, so the same learner in two tenants yields unrelated tokens. No column holds a learner identity in clear.
Credential scopes
The xAPI scope set: statements/write, statements/read, statements/read/mine, state, profile, all/read and all. The narrowest reads only the statements that credential itself wrote.
Immutability
Statements and attachments are append-only, enforced by database triggers that refuse UPDATE, DELETE and TRUNCATE. The only permitted changes are the voiding flag and an erasure.
Database transport
TLS with full certificate and hostname verification is mandatory; the service refuses to start otherwise.
Request audit events
One structured event per request carrying request id, credential key id, tenant, method, resource, status, record count, duration and filter names. Learner values in filters are tokenised before they are logged.
Tamper evidence
The erasure log is hash-chained and can be verified end to end by a command. The per-request event stream is not tamper-evident on its own, because that depends on where it is shipped.

Data protection

Erasure
A pseudonymising redaction. The learner is replaced by a random pseudonym in every position a statement can name them, free-text responses and attachments are removed, and their State and Agent Profile documents are deleted. Physical deletion is not used.
Erasure, recorded
Every erasure is written to the hash-chained log. The command refuses an erasure that matches nothing, so a mistyped learner cannot resemble a completed one.
Backups
An erasure is complete once backups taken before it have expired. After a restore, the erasure log is replayed.
Retention
By calendar month, per instance. The month is detached, exported as one file per tenant, and dropped. The drop is refused unless the exported row count matches.
Retention, per customer
A customer needing its own retention period needs its own instance.
Export on exit
The standard xAPI interface. A customer can page through every record as xAPI JSON with its attachments. There is no bulk export tool.
Residency
No region is offered today, because no hosted instance exists. The service needs only a PostgreSQL database, so an instance can be deployed where it is required.

Operations and verification

Deployment model
A shared multi-tenant instance, or a dedicated instance per customer. There is no hosted offering yet.
Probes prove they can fail
Each of the 47 behavioural probes must be shown to FAIL against a deliberately broken build before its pass is counted, and the harness enforces that. The conformance suite is run against broken builds for the same reason.
Adversarial review
In-house, run by a separate engineering agent against its own deployment built from the published commits, completed 23 September 2026. Eight defects found, all eight fixed and re-verified. This was not a third-party audit, an accredited security assessment or a penetration test.
Release conditions
Release is conditional on a load test on production hardware against a signed-off latency target, and on observed behaviour through a first database failover.
Performance
No production figure is published. Measurement on production hardware is the first release condition.

What it does

  • Conformance-tested

    Passes all 1,365 tests of the ADL LRS Conformance Test Suite for xAPI 1.0.3, and all 1,435 for xAPI 2.0.

  • Records never change

    Once stored, a statement cannot be edited or overwritten, only voided, as the standard specifies.

  • Isolated by design

    Each customer’s records are separated by rules enforced in the database, and not only by application code.

  • Encrypted and pseudonymous

    Record contents are encrypted at rest, and learner identifiers are indexed only as keyed tokens.

  • Erasure with an audit trail

    A learner’s personal data is removed from their records on request, and every erasure is recorded in a tamper-evident, hash-chained log.

  • Scoped credentials

    Each credential is limited to the operations it needs, down to reading only the records it wrote itself.

For documentation, a pilot or an integration, contact us.