Formative vs Summative Assessment Data Models in LMS Architecture

The global LMS market is set to hit $28.58 billion in 2025, and corporate adoption jumped 24% throughout 2024. Those two numbers mean one thing in practice: a lot of organizations are locking in database architecture decisions right now, this year, possibly this quarter. And most of them are doing it under a label ("assessment support") that hides a structural problem nobody's asking about.

Here's the problem. Formative and summative assessments are different data animals, since one tracks a process while the other renders a verdict. Build your schema like they're twins and you'll end up with a system that's mediocre at both jobs instead of great at either.

What formative and summative assessments actually measure, and why that difference is the root of everything downstream

Summative assessment shows up at the end. It grades you against a standard, usually with real stakes attached, and it's almost always the thing that ends up on a transcript or a compliance record. Carnegie Mellon's teaching resources put it plainly: summative evaluates learning against a benchmark, after the fact, with a grade attached.

Formative works on a different timeline, since it's ongoing, low stakes, and sometimes no stakes at all. Its whole job is to catch gaps while there's still time to fix them, rather than hand down a ruling. Northern Illinois University's instructional materials frame this as product versus process, and that phrase is doing more work than it looks like, because it describes, literally, what shape the resulting data takes.

There's a third type worth naming here even though it rarely gets billing: diagnostic assessment, which checks what a learner already knows before instruction even starts. It shares DNA with formative data in that both happen early and neither one closes the book on anything. That similarity matters later, when the conversation turns to how Learning Record Stores organize data by tier.

Picture a practice quiz with instant feedback sitting next to a final graded exam. Same tool, arguably even the same questions. The difference between them has nothing to do with quiz format. It comes down to a single question: does this event close a record, or does it feed into something still in motion?

How summative assessment maps to a relational data model

Summative events are tidy. Each one produces a discrete, terminal record: one row per attempt, a score, a pass or fail flag, a timestamp, a learner ID, a shape relational databases were basically born to handle.

Canvas, one of the more mature LMS platforms on the market, models its courses, enrollments, assignments, and grades across 35 tables. That's the architecture of a system built to represent finished, stable relationships between a manageable set of entities: student, enrollment, assessment, attempt, score, rubric. None of that changes shape much over time, which is exactly what relational databases like.

The advantages are real and unglamorous: referential integrity, ACID transactions, an audit trail you can actually follow. Compliance teams live and die by that kind of structure.

Here's where a lot of LMS reporting dashboards quietly fall apart. Many of them collapse two separate fields, completion_status and success_status, into a single column labeled "Status." Sounds harmless, but it isn't, because a learner can show up as "completed" while having failed the actual assessment, and the dashboard will happily display that as a green checkmark.

Run an audit against that record and you've got a problem, since "completed" without "passed" is a failed training record, full stop, no matter what the status column implies. The data might technically exist somewhere in the system, but if the schema doesn't surface it cleanly, you're relying on someone to go dig for it manually, which is exactly the kind of thing that doesn't happen until an auditor asks an uncomfortable question. This is a design choice, and it has teeth.

Retrieval for summative data tends to be point-in-time: look up a score, aggregate a cohort's pass rate, compare against a benchmark. SQL joins handle all of that without breaking a sweat.

How formative assessment generates a fundamentally different data shape

Formative assessment produces a stream, and a messy one at that: dwell time on a page, which answer a learner clicked first, how many times they retried a question, where in a video they hit pause, where in a quiz they gave up and closed the tab.

Trade publications covering xAPI and Learning Record Stores describe exactly this kind of tracking: how long someone lingered on a page, which option they clicked first, how many attempts it took to pass. None of that fits neatly into a row-per-assessment table, and there's no clean terminus to any of it.

The volume alone breaks the summative mental model. One learner moving through a single module might throw off dozens of formative events, where the equivalent summative data would generate exactly one row. Multiply that across a cohort and the math stops being cute.

Schema variability compounds the problem. A video emits different event types than a quiz, which emits different events than a simulation or a plain reading assignment. Force all of that into one rigid relational table and you're stuck choosing between wasted columns or dropped data. Neither option is good.

Querying diverges too. Formative questions tend to sound like "what happened at step three for the learners who eventually failed the exam?" That's a temporal sequence question, and relational joins get slow and cranky trying to answer it at any real scale.

This is exactly the terrain where document stores and NoSQL architecture start to make sense: flexible schema, horizontal scaling, an event-log pattern built for write-heavy, shape-shifting data. Try to house summative grades and formative event logs in the same schema and you'll end up over-engineering one side while starving the other of the structure it needs.

What SCORM was built to track and where its architecture ends

SCORM tracks completion, quiz scores, and time spent inside a browser-based course, which is basically a mirror image of the summative data shape: terminal, bounded, one record per finished attempt.

SCORM's architecture doesn't extend to the things formative assessment cares about most. Informal learning, mobile activity, social learning, in-progress behavioral signals; none of it exists as far as SCORM's architecture is concerned. That gap is baked into the design, not an oversight somebody forgot to patch. SCORM assumes learning happens inside a bounded course, delivered through a browser, that ends cleanly with a completion event. Anything that doesn't fit that shape is invisible to it by construction.

And yet SCORM is still everywhere in compliance training. That's just the reality on the ground, and any architect building or evaluating an LMS has to work around it rather than pretend it's going away.

The practical consequence: plenty of organizations that standardized on SCORM years ago have databases beautifully tuned for summative records and little to nothing set up to catch formative signals.

How xAPI and the Learning Record Store create a separate data infrastructure for formative events

xAPI came out of the ADL Initiative in 2011, originally built for the U.S. Department of Defense, and it's now an IEEE standard. It was built to catch the things SCORM structurally can't reach: offline activity, mobile behavior, cross-platform events.

The core unit is called a Statement, made of an Actor, a Verb, and an Object. Deceptively simple, and flexible enough to represent "Susan viewed a video clip" using the exact same structure as "Susan completed Data Science Ethics (Novice)." One format, two completely different levels of significance.

That flexibility is xAPI's real advantage over SCORM, since it handles formative and summative data without forcing a choice between them.

The Learning Record Store is the database purpose-built to hold those statements. It's worth being precise here: the LRS supplements the LMS database rather than replacing it, running alongside it as a parallel store that pulls in event data from multiple sources at once.

Here's a detail that matters more than it sounds like it should. A lot of platforms that support both SCORM and xAPI write SCORM completions to the relational database the instant LMSFinish fires, but xAPI statements often get written to the LRS asynchronously. That gap means a summative grade and its associated formative trail can be temporarily out of sync, and if an audit or analytics workflow joins both stores without accounting for the timing, the numbers won't line up cleanly. It's something architects need to design around instead of assume away.

The LRS tiered model is where the formative/summative split becomes explicit instead of implied:

• Noise tier: low-level micro-events, like "Susan viewed a video clip." High volume, low signal on their own.
• Transactional tier: mid-level events, aggregated up from the noise tier.
• Authoritative tier: high-level competency claims, like "Susan completed the DM course, grade A." This is functionally identical to a summative terminal record.

That structure is the actual mechanism by which formative noise and summative outcomes get separated and queried at different zoom levels, rather than dumped into one undifferentiated bucket.

One more upside worth mentioning: because the LRS lives outside any single LMS, learner data can travel with a person across organizations and systems. That kind of portability is out of reach for flat relational schemas locked inside one platform.

How event-driven and microservices architecture handles the data volume formative tracking generates

Formative event streams are heavy on writes and prone to bursts. Put a whole cohort through the same interactive module at the same time and you get a spike that a single monolithic relational database will handle about as gracefully as a screen door on a submarine.

Event-driven architecture treats each learner interaction as its own message, something that can be routed, queued, and consumed independently. That decouples the part of the system generating events from the part storing and analyzing them.

Microservices extend the same logic further. Content delivery, the assessment engine, the grade store, the LRS, each one owns its own schema, connected through APIs or an event bus rather than crammed into one shared database. Each piece can evolve on its own schedule.

That structure also makes life easier when connecting to HR systems or third-party analytics tools, since events already carry standardized xAPI metadata instead of some proprietary format that needs translating.

The tradeoff is eventual consistency, and it's a real one, since a course assignment might not show up on a dashboard the instant it happens. Formative event data can lag behind summative grades in reporting tools. Architects need to draw a clear line: which queries absolutely require strict, real-time consistency (a compliance audit, for instance), and which can tolerate a delay (a learning analytics dashboard usually can). Treating both categories the same is how systems end up either too slow or too sloppy.

Serverless patterns are also gaining ground for the event-generation side specifically, suited to formative traffic that spikes without warning and then goes quiet again.

What to evaluate when an LMS claims to support both assessment types

"Assessment support" on a spec sheet doesn't tell you much. The real question is whether the architecture underneath actually treats formative and summative as two separate data problems, or whether it's quietly forcing them into one.

On summative integrity: does the platform keep completion_status and success_status as two distinct fields, or mash them into one? Can someone pull a compliance report that separates "completed and passed" from "completed and failed" without writing a custom query to do it?

On formative infrastructure: is there a native Learning Record Store, or does xAPI data get shipped off to a third-party one? What's the actual granularity of the events being captured, just completion, or real behavioral detail like clicks, dwell time, retry counts? And is there any tiering to the LRS, or does everything land in one undifferentiated pile with no way to zoom in or out?

On the sync gap between the two stores: when do summative records hit the relational database versus when xAPI statements land in the LRS, at the same moment or on a delay? Is that lag documented anywhere, and does it put audit-trail accuracy at risk?

On schema flexibility: is the whole thing relational-only, or is there a document store handling the high-volume event side? Can new event types, an AR simulation, say, get added without a full migration?

And on tracking standards: SCORM alone is a tell that the architecture is summative-first, while xAPI support signals real formative capability, and cmi5 is a more recent tracking specification built on xAPI. Worth asking directly which standard governs the compliance records and which one governs the behavioral analytics, and whether those two things run through the same pipeline or two completely separate ones. The answer tells you more about the system than any feature list ever will.