How Keating fits together

Three responsibilities

Keating separates local pedagogy, model execution, and account authority. The pedagogy layer describes and records teaching work. The runtime carries the model conversation and tools. Account services handle capabilities and privileged operations. Changing a teaching procedure should not grant it account authority or broader execution permissions.

Learner interaction
  ├─ Client: browser / terminal / native mobile
  ├─ Teaching: prompts, skills, tools, learner artifacts
  ├─ Execution: Pi and configured model/runtime
  └─ Authority: explicit account capabilities and server boundaries

Local pedagogy and artifacts

src/core/project.ts coordinates project-scoped work. Topic definitions, lesson-plan construction, maps, and policy invariants are locally inspectable. The CLI and Pi extension reuse this layer rather than making separate implementations of every teaching operation.

Deterministic does not describe every operation in src/core. Animation generation, prompt evaluation, and fresh teaching experiments have explicit model boundaries. Tests inject runners, judges, and proposers at those boundaries.

The Pi teaching runtime

src/runtime/ selects and launches Pi. The teaching extension registers Keating's commands and tools, while pi/prompts/ and pi/skills/ supply reusable teaching instructions. The runtime can be selected through standalone-only, prefer-standalone, or embedded-only configuration.

This structure lets Keating evolve teaching workflows without forking every model execution feature. Additional Pi packages are explicit configuration and execute with local system access; they are not isolated lesson data.

Browser execution is a separate adapter

The web client combines its agent hook with browser tool implementations. Browser-safe core types and tools need to stay aligned with root changes, but cannot import Node filesystem behavior. The shared browser runtime package provides capability routing and adapter seams for work that cannot run on a learner's device.

Browser-only mode handles supported work locally. Host mode explicitly executes on a trusted serving machine inside a selected project root. Remote mode proxies to a configured execution service, and cloud mode routes remote-only work through the configured cloud backend. These modes have different trust and availability boundaries.

State belongs to a concrete scope

CLI output normally lives under the current workspace's .keating directory. Selected learner profiles redirect learner artifacts into profile-specific roots. Provider configuration remains project-wide, separate from learner history. Browser stores have their own origin and client boundaries; a file existing in a CLI workspace does not imply it has synchronized into a browser session.

.keating/
  outputs/plans/
  outputs/maps/
  outputs/verifications/
  outputs/benchmarks/
  outputs/traces/
  state/
  sessions/
  pi-config/
  profiles/

Teaching evolution has a fixed outer boundary

shared/evolution/ separates recorded executions, a maintained pattern wiki, immutable teaching revisions, and activation gates. A candidate changes a bounded teaching skill. It cannot rewrite the evaluator, assessment keys, tool permissions, or scoring thresholds.

CLI and browser experiments have different runtimes, base prompts, and local stores. An accepted revision is eligible for subsequent experimental teaching sessions in that scope; it is not a globally synchronized upgrade or proof of improved human learning.