App Boundary - Governed runtime for LMS-connected learning apps

Why this needs to exist

Without App Boundary

Every course app starts to look like a separate LMS integration.
Review evidence lives in screenshots, tickets, and vendor promises.
Generated code can drift toward backend, storage, and grading power.
Autograders become custom tools with unclear evidence paths.
Incident response depends on each tool having the right controls.

With App Boundary

The LMS launches one trusted boundary.
Apps become reviewed, versioned browser packages.
Storage, grading, evidence, and audit stay behind the gateway.
Browser autograders use the same import, review, and runtime path.
Operators inspect launches, grades, reports, and verification in one place.

The category only works if institutions can say yes without turning every classroom idea into a new trusted integration.

The runtime is no longer just a boundary. It is an operating model.

The latest work turns the security promise into visible product surfaces: authors can build, reviewers can inspect, instructors can launch, and operators can prove what happened.

App Writer creates package candidates, not rogue apps.

Prompts and revisions flow into a narrow generated-app contract. The package is validated, previewed, and saved for review before it can be pinned to an LMS placement.

Browser autograders have a governed package shape.

Grader specs, preview fixtures, tests, and example evidence travel with the reviewed app. The grader runs through Lantern, not as a separate external tool with its own trust story.

Reviewers can see diffs, test launches, and runtime activity.

Package changes, preview launches, content reads, attempt events, finalized attempts, evidence artifacts, and score proposals become product records instead of buried implementation details.

Operations can verify LMS setup instead of hoping it works.

Managed setup records, roster checks, grade smoke checks, retry histories, and certification evidence help teams understand exactly which deployment path is ready.

Three enforced boundaries

The runtime

Apps do not run on the LMS and they do not bring their own backend. They run as reviewed browser packages on an isolated runtime origin, behind a trusted edge gateway.

Each launch crosses the same control path before an app can read context or submit activity.

01 Launch boundary

Edge gateway

Lantern validates launch state, creates runtime sessions, signs a scoped bootstrap payload, and owns LMS service calls. Apps never see raw credentials.

02 Execution boundary

Reviewed browser package

The learner experience is immutable app HTML, CSS, JavaScript, and content. It receives only the GatewayApp capabilities approved for that package version.

03 Evidence boundary

Durable records

Review, launch, attempt events, evidence artifacts, scoring, grade publication, retries, and verification stay in the platform record.

Product surfaces

Real screens, not a pitch deck.

Admin view showing managed app packages with approval status, capabilities, and metadata — Package inventory shows what an app is, where it runs, and what it can access.

Preview runtime launching a flashcard app inside the governed browser container — Reviewed packages launch through the runtime, not through one-off LMS tools.

Terminal showing the app package file tree and validation output — The app contract is small enough to inspect and strict enough to govern.

What institutions can inspect

Approval evidence should be a product feature.

The important questions are operational: what changed, what capabilities are requested, how the app behaved in preview, whether grading works, and which LMS setup was verified.

Read the evidence model or the IT approval case.

Package review: Manifest, capabilities, accessibility notes, version status, and snapshot diff.
Runtime trail: Test launch, content read, attempt event, finalize, evidence artifact, and scoring records.
Teaching signal: Attempt events normalize into instructor reports without giving apps a class-wide database.
LMS verification: Roster checks, grade smoke checks, retry history, and certification evidence stay with the deployment.

How apps enter the boundary

Authoring is narrow on purpose.

A learning app is a small web app plus a manifest, content files, preview fixtures, and optional reviewed grading specs. The app owns the learning experience. Lantern owns the LMS integration, storage, grading, evidence, and audit path.

Package shape

app/
  manifest.json
  dist/
    index.html
    app.js
    app.css
  content/
    activity.json
  preview/
    fixtures.json
    tests.json

Browser autograder shape

grading/
  specs/
    checks.spec.js
evidence/
  example-output.json

deno task app:test-preview path/to/app
deno task app:validate path/to/app

Authors build the learner experience.
App Writer and local tools produce reviewed package candidates.
Reviewers approve versions before they reach students.
Apps do not get raw LMS tokens, direct storage, or arbitrary network power.

Start with the authoring guide, then use the browser autograder guide or the Web Checkup example.

Design principles

One trusted LMS boundary: The institution connects once. Every app runs through that single reviewed integration instead of managing its own LMS plumbing.
Evidence before approval: Package diffs, preview behavior, capability requests, accessibility notes, and deployment checks are visible before student launch.
Small reviewable app packages: Every app is a static package with a manifest, content, preview fixtures, and optional reviewed grader specs.
Useful for humans and LLMs: App Writer works because the contract is narrow, typed, and explicit. Generated apps still have to pass the same review path.