Technical White Paper · 2026
Experience Statements vs. xAPI
A technical and philosophical comparison of ADL's xAPI standard versus the proprietary organizational experience language — two systems that share a grammar but serve fundamentally different missions.
Randy Stewart Miller · 2026
xAPI (Experience API)
IEEE Standard
An open standard developed by ADL 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.
- • Origin: ADL / DoD — 2011 (Project Tin Can)
- • Formal Release: xAPI v1.0 — 2013
- • IEEE Standardization: v2.0 — 2020+
- • Domain: Learning & Development ONLY
Experience Statements
Proprietary Architecture
A proprietary organizational intelligence language built by Randy Stewart Miller over 9 months and 2,000+ engineering hours. Inspired by xAPI's grammar, but redesigned to serve the full organizational ecosystem.
- • Origin: Randy Stewart Miller — 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 Experience Statements share the same foundational data model — a structured triple that describes who did what to or with what thing. This shared grammar is where the similarity largely ends.
Actor
xAPI
learner@org.com (mbox)
Experience Statements
user_abc123 (uid — non-PII)
Verb
xAPI
http://adlnet.gov/expapi/verbs/completed
Experience Statements
https://verbs/isolated
Object
xAPI
eLearning module, quiz, SCORM object
Experience Statements
LOTO procedure, shift handover, work order
Detailed Side-by-Side Comparison
| Dimension | xAPI (Standard) | Experience Statements |
|---|---|---|
| Primary Domain | Learning & Development ONLY — eLearning, simulations, mobile learning, assessments | Entire organizational ecosystem — learning, operations, maintenance, HSE, compliance, HR, finance, communications |
| Design Origin | U.S. DoD / ADL — designed to replace SCORM for military training interoperability | Randy Stewart Miller — designed to capture organizational intelligence across every role and domain |
| Persistence Layer | Learning Record Store (LRS) — a separate, conformance-certified server | Cloudflare D1 — distributed edge SQLite database. No LRS required. SQL-queryable directly. |
| Actor Identification | Email (mbox), SHA1 hash of email — PII is IN the statement | Non-PII Universal Actor ID (uid). PII stored separately. Structurally GDPR-safe. |
| Verb Vocabulary | Globally registered vocabularies (ADL Verb Registry). Must be internationally recognized URIs. | Proprietary Verb Registry. Organizationally governed. Maintained in Verb entity. |
| Passive Capture | Not supported — requires active digital instrumentation of every activity | Fully supported — automations auto-emit statements without user action |
| Cross-Domain Analysis | Not designed for it — architecture assumes L&D silo | Core design principle — correlate safety incidents with training, maintenance with certification records |
| Analytics Target | LRS visualizations, connected LMS reports, third-party BI tools | AI Analytics agent, Unified OI Dashboard, direct SQL aggregations |
The Six Major Divergences
Scope — The Most Fundamental Difference
xAPI was designed to answer: 'Did this learner complete this eLearning activity?' This architecture was designed to answer: 'What is actually happening across this entire organization, to every person, in every domain, right now?'
Persistence — No LRS Required
The LRS is the beating heart of xAPI. Without a conformance-tested LRS, you cannot run xAPI. This architecture replaces the LRS with a purpose-built, edge-deployed, SQL-queryable database enabling complex JOIN queries across experience statements and organizational entities in a single call.
Privacy — Structurally Different Philosophy
In xAPI, the actor's email address lives inside the statement — every statement carries identifying information by design. In this architecture, statements use a non-PII Universal Actor ID. All PII lives in a separate schema. The experience ledger itself is structurally clean.
Verb Vocabulary — Registered vs. Proprietary
xAPI verbs must come from globally recognized vocabularies. This architecture uses verbs designed for internal organizational precision — 'isolated' in a LOTO context means something very specific that no global vocabulary would ever define.
Auto-Generation — A Critical Innovation
xAPI statements must be explicitly triggered by digital content. Experience Statements can be auto-generated by platform automations. When a task is marked completed, an automation fires automatically. The experience ledger grows organically as the organization operates — no instrumentation required.
Analytics Architecture
xAPI feeds an LRS which feeds third-party BI tools via REST API — the analytics layer is separate and requires additional integration. Experience Statements feed AI analytics natively — cross-domain SQL aggregations that correlate safety incidents with training completions in a single function call.
Randy Stewart Miller · 2026
The Experience Statement architecture was conceived and built by Randy Stewart Miller as the data foundation for Ripplemesh.