Evidence model

Every learning app needs a record, not just a launch.

App Boundary turns the approval question into product evidence: what was reviewed, what ran, what the learner did, what was graded, what was reported, and which LMS path was verified.

The durable trail

Evidence starts before approval and continues through runtime.

  1. Package candidate Manifest, content, preview fixtures, tests, optional browser-grader specs, and example evidence.
  2. Review record Capabilities, accessibility notes, review notes, approval state, immutable version, and snapshot digest.
  3. Test launch Reviewer preview launches create bounded records for launch, content reads, attempt events, and finalization.
  4. Learner runtime Progress, answers, completion, score proposals, evidence artifacts, and finalization stay behind the gateway.
  5. LMS operation Roster checks, grade smoke checks, retry events, deployment history, and certification evidence remain inspectable.

Institutional questions

The product keeps answers close to the work.

What changed?

Package snapshot diffs show what is different before a new version is approved.

What can it access?

Manifest capabilities make storage, events, evidence, scoring, and runtime requests reviewable.

Did it behave in preview?

Test launches record runtime activity so reviewers can inspect behavior before students see it.

Can instructors see learning progress?

Attempt events normalize into reports without giving app code a class-wide database.

Can grading be trusted?

Browser grader specs and score proposals run through the same reviewed package and server-owned grading path.

Is the LMS path ready?

Deployment setup, roster verification, grade smoke checks, retry state, and certification evidence stay together.

Reviewer surface

Evidence has to be visible to be useful.

App Boundary keeps the record where the decision happens: package pages, deployment pages, placement audit, preview logs, instructor reports, and verification pages.

Package diff Reviewers compare the pending version against the approved baseline.
Recent test activity Launch, content-read, attempt-event, and finalize records survive reloads.
Instructor reports Learner progress is derived from governed attempt events.
Certification evidence Internal workflow evidence and official directory evidence stay separate.
Terminal showing the app package file tree and validation output
Small packages make the evidence concrete: the files, checks, and runtime behavior are inspectable.

Buying criterion

The evidence model is the product moat.

Institutions do not just need more learning apps. They need a way to let those apps exist without losing the ability to review, explain, verify, and recover from what happens at runtime.