Maple AI OS Course

The OS as an authority layer

Why AI-native systems need a deterministic authority layer around probabilistic models.

Domain hubEvaluation snapshot

Learning Objectives

What this lesson should make precise

01

Name the core abstraction and its failure modes.

02

Translate the concept into a Maple/Hermon proposal contract.

03

Define at least one evaluation case that can fail the model safely.

Tutorial Flow

How this lesson becomes a demo and training target

Each tutorial is written as a user education path and a model-improvement artifact. The diagram shows how the idea moves into a lab, a typed contract, an eval gate, and then a Hermon/MapleAI demo route.

01

Concept

From assistant to operating layer

02

Applied Lab

Applied lab: The OS as an authority layer

03

Output Contract

intent, agent_identity, capabilities, authorization_required

04

Eval Gate

Does the answer separate model proposal from deterministic execution?

05

Demo Route

Maple AI OS training and public model checks

01

From assistant to operating layer

A normal assistant answers questions. An operating layer controls consequence. The moment an AI can change files, schedule work, call APIs, spend money, deploy software, or affect users, it needs authority semantics that are stronger than a prompt.

  • Identity must be explicit.
  • Capabilities must be deny-by-default.
  • Every consequence needs a receipt.

02

The Maple split

Maple separates proposal, authorization, execution, and evidence. The LLM produces typed intent; policy and kernel code validate it; deterministic services execute it; WorldLine records it.

  • LLM proposes.
  • Kernel authorizes.
  • WorldLine records.

03

Industrial failure mode

The common enterprise failure is giving the model direct tool authority and then trying to recover by writing longer system prompts. Maple's answer is structural: prompts describe behavior, but kernels enforce behavior.

  • No direct settlement.
  • No direct root access.
  • No hidden policy bypass.

Lab

Applied lab: The OS as an authority layer

Design an OS proposal contract for an agent that may read a project folder, summarize issues, and request deployment approval.

Expected result

  • A typed JSON-style proposal rather than free-form advice.
  • Clear authority boundaries and denied operations.
  • A test or rubric that decides whether the proposal is deployable.

Evaluation

How Maple would grade this work

Rubric

  • Does the answer expose assumptions instead of hiding them?
  • Does the answer separate model proposal from deterministic execution?
  • Does the answer produce artifacts that can be tested, reviewed, and rolled back?

Output contract

intent, agent_identity, capabilities, authorization_required, receipt_required, rollback

Use this lesson as training direction

A strong lesson gives users a mental model and gives Hermon a sharper target for examples, probes, and demo prompts.

View evalsDomain hub