The Build

Architecture & the Trust Layer

The firm architectural principle behind Maestro: keep the part that calls the AI models separate from the part that holds the learning logic. The trust layer is the real asset — and it is the-code's IP.

Model layer vs learning logic

The briefing is firm on one thing: keep the part that calls the AI models separate from the part that holds the learning logic. The model layer should be swappable as models change. The trust layer — the learner model, the catalogue of common misconceptions, and the rules for what to show next — should stand on its own, with its own storage and audit trail, and not be tied to any one model vendor. The-code sees the learner model, not the content, as the real asset, and expects the misconception catalogue to grow from real student data over time. The Companion should pick from teaching approaches people have written, not invent teaching on the fly. The existing MVP already keeps models and prompts configurable, which fits this.

The trust layer as IP

The trust layer — the learner model, misconception catalogue, and next-step (item-selection) rules — is the-code's existing IP. The intent is for the dev team to integrate against it rather than rebuild it. That said, this is something for the team to assess: they'll get access to review the existing trust-layer code and can determine whether they're comfortable integrating as-is, or would recommend re-writing part or all of it as part of the build. Both paths are open; the decision is driven by the team's technical judgment once they've seen the code.

Who owns the mastery logic

There are two layers, configurable in different ways:

Layer	Who owns it & how it's set
The mastery engine	Lives inside the platform. The mechanics — how mastery is decided, how evidence is read, how the belief updates, how misconceptions are handled, how the confirming probe works — are built into Maestro and behave the same across every course. This is what makes decisions consistent, reproducible, and auditable.
The mastery bar	Set by the SME per course, per node. What counts as "mastered" for a specific concept — how deep understanding must be, which misconceptions matter, which block which assessments, what unlocks a milestone — is authored during course design in Studio. This is where academic judgment lives.

In short: the platform owns the mechanics, the SME owns the standard.

No runtime dials

The same discipline extends to the runtime governance metadata: prompt-template and judge versions are pinned to what the course was authored against, so the Companion and the diagnostic layer behave deterministically against that version rather than whatever is newest. Determinism is a first-class requirement, not a nice-to-have.