Technical White Paper
Ripplemesh Experience Statements vs. xAPI
A technical and philosophical comparison of ADL's xAPI standard versus Ripplemesh's proprietary organizational experience language — two systems that share a grammar but serve fundamentally different missions.
xAPI (Experience API)
IEEE StandardAn open standard developed by ADL (Advanced Distributed Learning) for the U.S. Department of Defense, formalized by the IEEE. Designed to replace SCORM and standardize the exchange of learning experience data between eLearning systems. Licensed under Apache 2.0.
- Origin: ADL / DoD — 2011 (Project Tin Can)
- Formal Release: xAPI v1.0 — 2013
- IEEE Standardization: v2.0 — 2020+
- Domain: Learning & Development ONLY
Ripplemesh Experience Statements
ProprietaryA proprietary organizational intelligence language built by Ripplemesh over 9 months and 2,000+ engineering hours. Inspired by xAPI's Actor→Verb→Object grammar, but redesigned entirely to serve the full organizational ecosystem — operations, safety, HR, compliance, maintenance, and beyond.
- Origin: Ripplemesh Platform — 2024
- Storage: Cloudflare D1 (Edge SQL)
- Privacy Model: PII-separated by design
- Domain: Entire Organizational Ecosystem
What They Share — The Actor → Verb → Object Grammar
Both xAPI and Ripplemesh Experience Statements share the same foundational data model — a structured triple that describes who did what to or with what thing, along with supporting context, result, and timestamp data. This shared grammar is where the similarity largely ends.
Actor
The person or system performing the action
xAPI Example
learner@org.com (mbox)Ripplemesh Example
user_abc123 (uid — non-PII)Verb
The action that was performed
xAPI Example
http://adlnet.gov/expapi/verbs/completedRipplemesh Example
https://ripplemesh.com/verbs/isolatedObject
The target or subject of the action
xAPI Example
eLearning module, quiz, SCORM objectRipplemesh Example
LOTO procedure, shift handover, work orderDetailed Side-by-Side Comparison
| Dimension | xAPI (Standard) | Ripplemesh Experience Statements |
|---|---|---|
| Primary Domain | Learning & Development ONLY — eLearning, simulations, mobile learning, assessments | Entire organizational ecosystem — learning, operations, maintenance, HSE, compliance, HR, finance, communications, intelligence |
| Design Origin | U.S. DoD / ADL — designed to replace SCORM for military training interoperability | Ripplemesh — designed to capture organizational intelligence across every role and domain |
| Persistence Layer | Learning Record Store (LRS) — a separate, conformance-certified server that validates and stores statements | Cloudflare D1 — distributed edge SQLite database. No LRS required. SQL-queryable directly. |
| Conformance Requirement | Mandatory — ADL Conformance Test Suite must be passed. Non-conformant LRS cannot participate. | Not applicable — proprietary standard. Platform-native validation via Ripplemesh's own entity schema. |
| Actor Identification | Email (mbox), SHA1 hash of email, OpenID, or account reference — PII is IN the statement | Non-PII Universal Actor ID (uid: user_<id>). PII stored separately in D1 PII schema. Structurally GDPR-safe. |
| Verb Vocabulary | Globally registered vocabularies (ADL Verb Registry, community profiles). Must be internationally recognized URIs. | Proprietary Ripplemesh Verb Registry (https://ripplemesh.com/verbs/). Organizationally governed. Maintained in Verb entity. |
| Example Verbs | completed, passed, failed, launched, attempted, experienced | isolated, qualified, investigated, responded, endorsed, handedover, approved, bypassed, observed |
| Statement Trigger | Must be explicitly triggered by learning content (LMS, SCORM module, mobile app) | Can be auto-generated by Ripplemesh platform automations, backend functions, scheduled tasks, or explicit user actions |
| Passive Capture | Not supported — requires active digital instrumentation of every activity | Fully supported — role assertions, sync operations, entity change events auto-emit statements without user action |
| Query Method | LRS REST API (GET /statements endpoint with filters) | Direct SQL via Cloudflare D1 backend functions — complex JOINs, aggregations, cross-domain correlation |
| Analytics Target | LRS visualizations (DAVE), connected LMS reports, third-party BI tools | Milam Analytics (AI agent), Unified OI Dashboard, Group Leader Dashboard, Head of Learning Dashboard, D1 Catalog |
| Cross-Domain Analysis | Not designed for it — architecture assumes L&D silo | Core design principle — correlate safety incident statements with training completion, maintenance work orders with certification records |
| Interoperability Goal | Global cross-system semantic interoperability — any two xAPI-compliant systems can exchange and interpret data | Internal organizational semantic consistency — precision within the Ripplemesh ecosystem, no external interoperability needed |
| Governance Body | IEEE (P9274.1.1 Working Group), ADL, international standards community | Ripplemesh platform administrators — verb registry and statement schema governed internally |
The Six Major Divergences — Where Ripplemesh Fundamentally Departs from xAPI
1. Scope — The Most Fundamental Difference
xAPI was designed to answer: "Did this learner complete this eLearning activity?" Every structural decision — the LRS, the verb registries, the conformance testing — flows from that question.
Ripplemesh was designed to answer: "What is actually happening across this entire organization, to every person, in every domain, right now?" A maintenance technician completing a Lock-Out/Tag-Out procedure, a compliance officer approving a permit-to-work, a group leader conducting a shift handover — xAPI was never designed to capture any of these realities.
2. Persistence — No LRS Required
The LRS is the beating heart of xAPI. Without a conformance-tested LRS, you cannot run xAPI. The LRS validates every statement, enforces structural conformance, and serves data back via a REST API — but it was never designed for complex SQL analytics.
Ripplemesh replaced the LRS with Cloudflare D1 — a purpose-built, edge-deployed, SQL-queryable database. This means Milam Analytics can run complex JOIN queries across experience statements and organizational entities in a single SQL call. An LRS was never capable of this.
3. Privacy — Structurally Different Philosophy
In xAPI, the actor's email address (or its hash) lives inside the statement. This means every statement in the LRS carries identifying information by design. GDPR compliance requires careful LRS-level access controls and deletion workflows.
In Ripplemesh, statements use a non-PII Universal Actor ID (uid: user_abc123). All PII lives in a separate D1 PII schema, accessed only via the audited resolveActorPII function. The experience ledger itself is structurally clean — it can be analyzed, exported, or shared without exposing any personal information.
4. Verb Vocabulary — Registered vs. Proprietary
xAPI verbs must come from globally recognized, registered vocabularies. The verb http://adlnet.gov/expapi/verbs/completed means the same thing to every xAPI-compliant system in the world. This enables global interoperability.
Ripplemesh verbs are designed for internal organizational precision. The verb https://ripplemesh.com/verbs/isolated in a LOTO context means something very specific to a Ripplemesh operations workflow that no global vocabulary would ever define. Organizational specificity is more valuable than global interoperability when you own the entire platform.
5. Auto-Generation — A Critical Innovation
xAPI statements must be explicitly triggered by digital content. If a learner reads a physical safety manual or performs a real-world procedure without digital instrumentation, xAPI cannot capture it. Every activity must be wired up individually.
Ripplemesh statements can be auto-generated by Ripplemesh platform automations. When a ProjectTask is marked completed, an automation fires logProjectTaskExperience. When a ManagedUser's role is updated, syncManagedUsersToExperience auto-emits a role assertion. The experience ledger grows organically as the organization operates — no instrumentation required.
6. Analytics Architecture — What the Statements Feed
xAPI feeds an LRS, which feeds LRS visualizations or third-party BI tools via a REST API. The analytics layer is separate from the LRS and requires additional integration work.
Ripplemesh Experience Statements feed Milam Analytics natively. Milam calls queryD1Experience, d1LearningAnalytics, d1OperationsAnalytics, and d1SafetyAnalytics directly — cross-domain SQL aggregations that correlate safety incidents with training completions in a single function call. The AI analytics layer is a first-class citizen of the architecture, not an afterthought.
Why Ripplemesh Diverged — The Honest Answer
xAPI was designed in 2011 by a U.S. Department of Defense research initiative to solve a very specific, well-defined problem: eLearning SCORM data was trapped inside Learning Management Systems and couldn't be shared or analyzed across systems. It solved that problem brilliantly for the L&D world.
Ripplemesh was designed to answer a completely different question: "What is actually happening across this entire organization, in real-time, and how do we use that data to make the organization smarter, safer, and more effective?"
The Actor → Verb → Object grammar was exactly the right foundation. It is elegant, flexible, and proven. But the LRS, the global verb registries, the IEEE conformance testing, the eLearning-centric assumptions about what constitutes an "activity" — none of those served the broader organizational intelligence mission. So Ripplemesh kept the grammar, discarded the L&D constraints, and built an organizational intelligence layer on top of Cloudflare's edge infrastructure.
What Ripplemesh Built Instead
A unified organizational experience ledger that captures human activity across every operational domain — learning, operations, safety, compliance, HR, finance, and communications — stores it in a privacy-safe, SQL-queryable edge database (Cloudflare D1), and feeds a deterministic AI analytics engine (Milam Analytics) — all within a single, fully integrated platform. This does not exist anywhere else. It is the culmination of 9 months and over 2,000 hours of engineering and design work.
Calling Ripplemesh Experience Statements "xAPI" would be like calling a modern jet engine a "propeller aircraft" because both use combustion. The grammar is borrowed. The mission, architecture, privacy model, persistence layer, verb vocabulary, and analytics target are entirely original.
Explore the Verb Registry
Browse all 70+ registered Ripplemesh verbs — searchable by domain, with canonical URIs for every operational action from LOTO isolation to shift handover.
Want to go deeper?
Explore the full Experience States Semantic Architecture — the knowledge graph layer that grounds every Ripplemesh experience statement with governed meaning, canonical concepts, and cross-domain relationships.