What "AI-native" should mean in an LMS, and how to test it

"AI-native" is claimed by almost every learning platform on the market, which means it no longer tells a buyer anything. Four questions restore the signal. What is the model reading — your material, or what it remembers from the open web? Can it act, and what stands between a proposal and a change? When it is wrong, does a person catch it or does the model commit? And can you reconstruct, six months later, what was proposed and what was applied? A product that answers all four with a mechanism is AI-native. One that answers with a prompt is a chat window with good marketing.

The phrase decayed the ordinary way. A summarise button became "AI-powered", that became table stakes, and the field moved to "AI-first" and then "AI-native" — each a claim about architecture made in a sentence containing none. What genuinely varies is where the model's output goes and who may stop it, and that rarely reaches a feature page.

Question one: what is the model reading?

Ask the assistant something answered by your own material and nowhere else — an internal policy number, a course code, the version of a standard you actually teach. A grounded system quotes the passage and names the document, version and page. An ungrounded one returns a fluent, generic answer — the same answer the same model gives with no product around it.

The harder test is absence. Ask about something your material does not cover. A retrieval system with nothing to retrieve should say so. A model asked to be helpful invents instead, in exactly the register your documents are written in, because that is the register it was shown.

Two follow-ups separate a demo from a deployment. Which documents were in scope — if retrieval runs over one shared index for the whole tenant, the assistant is a sideways read of everything anybody uploaded. And is the citation checkable: "source: the employee handbook" is not, since nobody can turn to it.

Question two: can it act, and what confirms the action?

An assistant that can only talk is safe the way a suggestion box is safe. The interesting products can change something — publish a module, enrol a cohort, adjust a rubric, archive a programme — and the moment that is true, the question stops being about the model and becomes one about the workflow around it.

• Advisory. It answers, and nothing else happens. Nothing to confirm, because nothing is applied. Safe, low ceiling.
• Propose and confirm. The change arrives as a draft — a diff, a staged item, a queued action — and a named person applies it. The model has no path to the live object.
• Act and report. The model makes the change and tells you afterwards. Demonstrated as autonomy; in practice it turns every model error into an incident.

Ask a vendor to name one thing their assistant can change, then to show the confirmation step in the product. Two answers should worry you. "It asks you first" — where in the code is that enforced? And "the system prompt tells it not to" — a prompt is a request, which is also what a hostile sentence in an uploaded document is making.

The distinction is where the check runs. A control inside the generation can be argued with by the generation. A control that runs after it, over the output, cannot. That is why prompt injection is practical rather than theoretical: a policy PDF with one hostile sentence in it is a document your staff have every reason to upload.

Question three: what happens when it is wrong?

Models are wrong at some rate and will stay that way. The design question is who absorbs the error and how far it travels first. Rank what the assistant can do by blast radius: a draft one author reads; an edit to a live course a cohort opens on Monday; a released grade, which a named person may appeal; a bulk operation over records.

Grading is where this gets sharp, because it is where a model's mistake becomes an institutional judgement about somebody. A rubric score an instructor reviews is a draft. The same score released automatically is a decision nobody made. When a learner asks who decided their mark, "the system" has to resolve to a person's name, and the way to make that true is to leave the release with them.

The tutor case has the opposite shape. A tutor that hands over the answer is not dangerous, only an expensive way to ruin the exercise — but it fails at the moment a struggling learner pushes hardest, and no quantity of "do not reveal the answer" in a prompt survives fifty rephrasings.

Question four: can you reconstruct what happened?

Six months after a course goes wrong, somebody will ask what happened. The useful record has three parts, and most products keep only the last one.

1  The request      who asked, what they asked, which documents were
                   retrieved, which provider and model answered.

2  The proposal     what the model returned, in full, before anybody
                   touched it.

3  The application  what a person applied, when, and to what — plus what
                   they rejected, which is the entry that proves the
                   control was doing something.

Storing the applied change is ordinary version history. The link between the proposal and the application is what turns it into an audit trail: the difference between knowing a lesson changed and knowing that a model proposed this wording, an author rewrote two sentences, and this named person accepted the result at 14:12.

Rejections are the underrated half. A log of accepted drafts with no rejected ones is not evidence of a good model — it is evidence that nobody reads the drafts. Ask whether entries can be edited afterwards, too: a log that supports updates records what its last editor wanted you to see.

Scoring the usual patterns

Most products land in one of five shapes. None is a bad product; they are different bets, and the test tells you which bet you are buying. Named facts below come from our sourced notes on alternatives.

The assistant in the corner

A chat panel beside the catalogue. Grounding varies, action is nil, wrongness is contained because nothing it says changes anything, and audit is absent because nobody thought a chat log needed one. It passes question three by not doing anything — a real answer, and a low ceiling.

AI arriving through plugins or integrations

Moodle's AI capabilities arrive through third-party plugins rather than the core product, and Canvas's AI features are added through integrations rather than being native to authoring, grading and reporting. That is not a criticism of any particular plugin. It is about where the guarantee lives: grounding, containment and audit become properties of whichever component you installed, so the platform's answer to all four questions is "it depends which one".

The generation button

A "generate a lesson" or "generate ten questions" control in the authoring tool. Strong on question two, because the output is a draft an author accepts. Weak on question one, because the only grounding is the sentence somebody typed into the box. The result reads well and belongs to no particular syllabus.

The agentic copilot

The strongest answer to question two and the easiest place to fail three and four. The failure mode is uneven coverage: an agent that can perform fifty actions and confirms five, because confirmation was added action by action as somebody thought of it.

The platform built around the model

Sana is the clearest example of a product positioned this way, and there the label describes architecture rather than decorating it. AI-native describes how a system is built, not what happens to it: Workday completed its acquisition in November 2025 and relaunched the product as part of the Workday suite in March 2026.

Where Lurno passes this test, and where it loses

We built Lurno's AI against a version of this test, so the passes are unsurprising and the losses are the useful part. Generation is grounded in documents your organisation uploaded and cites document, version and page. Every write arrives as a proposal a person applies: drafts are accepted block by block, grades are drafted over an anonymised submission and released by an instructor, publishing a programme needs a second approver. Tutor containment is a server-side check against the answer key. Requests, accepted drafts and rejected drafts are separate entries in a hash-chained audit log, and tenant isolation sits in the database — separation enforced underneath the platform. Detail on security.

Now the losses — the part a competitor would put on a slide.

• SCORM, xAPI and LTI are in development. Modelled in the product; the runtime is being built. Courseware locked inside SCORM packages is not a source we can ground in today.
• Confirmation is slower than autonomy. There is no mode in which our AI writes to a live programme or releases a grade by itself. If you want an assistant that simply does the thing, this will irritate you.
• The copilot refuses more questions than a looser one would. It queries a registry of certified metrics, so a question the catalogue cannot express gets a refusal and the nearest metric instead. In a demo, a confident wrong number often beats an honest refusal.
• The calls still go to a third party. We do not build models. OpenAI, Anthropic and Google are supported, chosen per organisation, and your own key changes whose account is billed, not the fact that text leaves.
• We hold no SOC 2 or ISO 27001 certification. The audit chain is a design property you can inspect and test, not an auditor's opinion.
• You cannot run this test on us unaided. Self-serve signup and trials are in development; accounts are created by invitation. Against a product you can sign up for and probe alone, that is a real disadvantage.

Running the test in an hour

1. Bring your own document, have them upload it live, and ask a question only that document answers. Then ask one it does not.
2. Ask them to list every action the assistant can take without a person. The length of the pause is data.
3. Pick the highest-risk item on that list and ask to see its confirmation step in the product, not on a slide.
4. Ask to see an audit entry for something the AI proposed and a person rejected.

That is the test. Is it reading your material or its own memory. Can it act, and what stands between the proposal and the change. When it is wrong, does a person catch it. And is there a record linking what was proposed to what was applied, including what somebody refused. A vendor who answers all four with a mechanism has built something. A vendor who answers with adjectives has written a landing page.