> For the complete documentation index, see [llms.txt](https://help.cubelet.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.cubelet.ai/platform-and-integration/architecture/governance-and-provenance.md).

# Governance & provenance

*How the quality gate functions as the platform's governance layer, what provenance a passing Cubelet carries, and how licensing, credentials, and MCP sessions extend that provenance outward.*

## The quality gate as governance

Every Cubelet must clear a fixed quality gate before it is eligible to ship to a learner:

* **42/60 aggregate minimum** (70%) across the six faces.
* **Every face must score 6 or higher** — no single strong face can compensate for a weak one, and no face may score below 6 (which also means no face may score 0).
* QA is performed by the highest-capability model tier the platform runs — the gate's scoring rubric is calibrated against that tier's judgment, and is not applied at a lower tier.

A Cubelet that fails the gate is not invisible in just one place — it is excluded from **every** discovery surface. Catalog listings, direct content lookups, search, and the learner-facing study surface all filter to gate-passed content only. There is no discovery path that bypasses the gate.

## The `quality_gate` block as provenance

Every Cubelet carries a `quality_gate` block as its permanent, per-cubelet audit record (see Data model & taxonomy for the full field list):

* `passed` — whether the Cubelet is eligible to ship.
* `aggregate` — its total score out of 60.
* `scores` — its per-face breakdown.
* `reviewed_by` — which QA reviewer verified it. In production this records the canonical value `qa-agent-opus`, the platform's highest-capability review tier — the field is never allowed to claim a stronger reviewer ran the check than actually did.
* `review_date` — when that review happened.

This block is what lets a consumer — human or agent — verify a Cubelet's quality provenance directly from the content itself, rather than trusting an unqualified claim that it passed.

## Content licensing hierarchy

Source material feeding Cubelet production follows a licensing hierarchy, from least to most restrictive:

1. **Public domain** — e.g. NIST, OWASP (CC0).
2. **Permissive, with attribution** — e.g. MITRE.
3. **Law** — e.g. EU AI Act, TRAIGA. Statutory text is used as source material under its legal status rather than a content license.
4. **Reference-only** — e.g. ISO 42001. Clause IDs are usable for framework mapping, but clause content is not reproduced — the corresponding Cubelet content is synthesized independently.

## Credentials as provenance

The Passport is the platform's credential surface. It issues **W3C Verifiable Credentials**, and what a credential represents is deliberate: a Passport credential certifies a **proven outcome**, not study activity. Completing a Cubelet in the Library does not, by itself, issue a credential.

A Learner Competency Credential is issued after a Case has been scored. The issuing record requires a mastery-state value, the assessment score, the passing threshold it was scored against, and the timestamp of the scoring evidence, tied to the specific session that produced it. A separate verification path checks a credential's validity, revocation status, issuer, and subject, so a third party can confirm a credential independently rather than trusting it on presentation alone.

## Session-level provenance via governed MCP endpoints

Access to the platform's MCP endpoints is authenticated per session — every tool call happens inside an authenticated session tied to a specific caller, rather than anonymously, and requests are logged server-side (see Auth & access).

Taken together, the platform's provenance story has a consistent shape: content carries the `quality_gate` block, credentials carry scored evidence, and tool calls carry an authenticated session — nothing on the platform is asserted without a record of what verified it.