Everything logs what a learner did.
Cognivia measures what their memory is doing.

What the flow looks like

One event in. A diagnosis, a prediction, and a next move out.

A partner doesn't adopt a new gradebook or migrate their content. They translate what a learner just did into a single, standard structure, the Learning Trace, and send it. Cognivia's models run on that common structure and return intelligence the partner's own system never had. The same six stages run whether the event came from a village classroom on a shared PC or a commercial AI tutor.

The Learning Trace

A common language for what happens during learning.

Cognivia's intelligence can't be built on any one app's private metrics, so it defines a universal representation of a single learning event: learner → task → concept → response → context → confidence → latency → error → intervention → outcome. Two things make it different from ordinary event logs: it captures the raw response, not just right or wrong, and it captures a confidence rating taken before feedback. Without those two, there is no mechanism and no metacognition to read.

On your own content

Point the diagnosis at your items and your syllabus.

Misconception-targeting and prerequisite-gap detection run on your material, not a fixed taxonomy. Upload two small maps once, keyed by your own item_ref and concept strings, and every later diagnosis uses them. An item map turns a specific wrong option into the misconception behind it; a prerequisite map lets a miss be traced to a foundation the learner never mastered. Both are scoped to your account, and you can read them back or replace them any time.

# name the misconception behind a wrong answer to your item
POST /v1/content/items
{ "items": [{ "item_ref": "q_1042",
    "distractors": { "6/8": "adds numerators and denominators" } }] }

# trace a miss to a weak foundation
POST /v1/content/prerequisites
{ "prerequisites": [{ "concept": "Adding fractions",
    "requires": ["Equivalent fractions"] }] }

How it stays honest

Every field in a response carries its own uncertainty.

Here is what we observed. Here is what we infer. Here is how certain we are. Here is the evidence. Here is what we recommend. And here is whether the recommendation worked.

Every inferred field in an API response carries a probability or a credible interval, and when the evidence is too thin, the field returns insufficient_evidence instead of a fabricated number. That isn't a limitation to hide; it's what separates measurement infrastructure from a system that guesses confidently. A partner integration is expected to render it, not paper over it. The full discipline, every metric's definition, model, uncertainty method, validation study, and the exact claims it is and isn't allowed to make, lives in the Cognivia Measurement Specification, the project's scientific constitution.

What the layer will not do

A learning trace is sensitive. It's treated that way.

For agents · MCP

Give any AI agent the diagnosis, as a tool.

Cognivia ships as an MCP server, so a tutoring agent, an IDE, or an assistant can call it directly. The agent sends what a learner just did and gets back the error type, the memory state, and the next move, each with its uncertainty. No bespoke glue.

For terminals · CLI

Diagnose and pull reports from the command line.

For developers and researchers: run a diagnosis over an export, read a learner's memory state, or generate a report, straight from a terminal or a data pipeline. The demo path runs on bundled sample data, with no key required.

What it returns

Three reports, built from the same trace stream.

The point was never a quiz. It is the output: readable, exportable reports a teacher, a developer, or a researcher can act on, and every number carries its uncertainty.