The content kernel

Every piece of content in MTP — scenarios, lessons, rubrics, flows, coaching templates, item banks, curriculum plans, even dashboards and tenant themes — is a versioned, schema-validated JSON document interpreted by an engine. The platform ships no vertical logic; it ships engines that interpret what tenants author. If you consume the Platform API, this page describes the shape of everything you will read and write.

Schema registry

Content types are rows in a registry, not code. Each content type definition is a JSON Schema (draft 2020-12) plus UI hints. A 50-field law-enforcement persona card is one row; a financial-literacy role-play card is another; tenants can register their own. Definitions are versioned, and published versions are immutable.

Content items and per-field provenance

A content item holds its document as JSON plus typed columns for the query axes (type, status, tenant, tags). Every field of authored content carries a provenance record:

Rules that hold platform-wide:

• A rationale is always present; publish validation fails without it.
• AUTHORED and SYNTHESIZED fields carry exactly two alternatives; regeneration replaces the set.
• Edit history is append-only, and any human touch upgrades a field’s provenance to AUTHORED, preserving the prior value as the first alternative.
• Every model inference is logged append-only: prompt template and version, full prompt, raw response, model identity, latency, token counts, and retrieval IDs. The log is never edited and never deleted.

Universal approval workflow

Nothing user-generated reaches a learner without traversing an approval workflow. This is a platform tenet, not a per-feature behavior: because everything publishable is a content-kernel item, version history, approval, and audit are inherited rather than reimplemented.

Workflow definitions are themselves data. The launch workflow is Draft → Submitted → [Conformance Review] → Approved → Published → Archived with rejection paths, append-only review notes, escalation SLAs, single-writer draft locks, and an immutable audit row per transition. Tenants tune states, gates, SLAs, and reviewer classes without code changes.

Approvers are resolved declaratively per workflow step:

• ROLE — any holder of a named permission in the organization
• NAMED — an explicit user list
• UNIT_CHAIN — walk the author’s org-unit ancestry and resolve the nearest ancestor unit’s holder of the required permission, continuing upward on SLA expiry
• SEPARATION — modifiers on any strategy: no self-approval (default on), distinct-from-prior-steps, n-of-m

Versions are structural

Every publish creates an immutable version row. Learners only ever see a published version; edits fork a new draft; rollback means re-publishing a prior version through the same approval gate, never mutating anything. For any delivered artifact the audit trail answers: who wrote each field (provenance), who changed what and why (edit history and notes), who approved it and against which version (approval rows), and who saw it (delivery events).

Registries all the way down

The same registry pattern covers behavior, not just documents:

• Activity kinds bind a content schema to a renderer key, runtime requirements (needsMetahuman, needsVoice, needsGatewaySession), grader bindings, and a declarative completion policy. The metahuman is a property of an activity kind, never a platform assumption.
• Renderers map renderer keys to web components. An unknown kind degrades to a metadata card instead of an error, so old clients never break on new kinds.
• Graders are plugins referenced by rubrics: deterministic expressions, LLM assessment tasks, authored lookups, item answer keys, numeric tolerance, symbolic equivalence, and attestations.
• Assessment items align to 1EdTech QTI 3 item types, stored in per-tenant item banks with QTI import and export.

Flows, rubrics, and coaching

Three more definition families complete the kernel:

• Flow definitions describe session state machines — states, transitions, gates, timers, trainer overrides, and terminal rules — interpreted by a deterministic server-side flow engine. See Training sessions.
• Rubric definitions declare scoring layers and criteria; the assessment payload schema is generated from the rubric, and grades (including LTI AGS grade passback) derive from payloads via declarative mappings.
• Coaching templates choreograph the debrief — outcome-state matrices, panel sequences, authored verdicts, and language rules — rendered entirely from the stored assessment payload with zero LLM calls at render time.