AoL from Run One

1. Executive Summary

Assurance of Learning (AoL) is the mechanism by which business schools demonstrate that graduates actually acquire the competencies their programs promise. In its current form, AoL is largely a periodic reporting exercise: coordinators sample a small number of artifacts, apply rubrics after the fact, and assemble aggregate evidence at the program level in time for the next accreditation visit. The individual student — the unit that actually learns — is rarely present in the evidence trail.

This white paper proposes an open standard, provisionally titled AoL from Run One, for capturing, structuring and exposing per-student learning evidence from the first execution of any learning activity, whether that activity is a simulation, a case discussion, a written assignment, a peer exercise, or an AI-mediated tutorial. The standard defines a common evidence schema, integrity signals, rubric alignment vocabulary, portability rules and privacy rules, so that evidence produced by any conforming tool can be aggregated, audited and re-analysed across courses, programs and institutions.

The standard is deliberately narrow in scope and permissive in adoption. It borrows structural conventions from 1EdTech Caliper Analytics, xAPI (formerly Tin Can), Open Badges 3.0 and the W3C Verifiable Credentials 2.0 family, and it is designed to be implementable by any vendor or in-house team without licensing fees. Kudzu Partners intends to contribute an initial reference implementation and proposes to convene an open working group, but the specification itself is intended to belong to the community — schools, accreditors, researchers and edtech providers.

Adopting AoL from Run One shifts assurance from a periodic reporting artifact to a continuous, verifiable, per-learner property of the system. It reduces accreditation burden, makes program improvement decisions defensible, and gives learners portable evidence of what they have actually done and demonstrated.

2. The Problem: Assurance of Learning as Theatre

AoL was introduced with the right intent. Accreditation bodies — AACSB, EQUIS, AMBA, ACBSP — asked schools to move beyond input measures (faculty credentials, admissions selectivity, library holdings) and demonstrate that programs actually produce the learning outcomes they claim. Two decades on, the machinery built to satisfy that requirement rarely delivers on it.

The typical AoL cycle in a business school today looks something like this. A committee defines program-level learning goals. Course coordinators map assignments to those goals. Once every few years, a sample of student artifacts — often 20 to 40 per goal — is retrospectively evaluated against a rubric. Results are aggregated into a dashboard, a narrative is written, and the file is closed until the next reaffirmation visit. Between visits, evidence collection is largely dormant.

There are three consequences, each corrosive to the credibility of the process. First, the evidence is retrospective. Rubrics are applied after learning has occurred, often by faculty who were not present when the work was produced, on artifacts stripped of context. A student's essay is scored, but the prompt they answered, the resources they had access to, the number of revisions they made, and the feedback they received along the way are typically absent.

Second, the sampling is aggregate, not per-learner. AoL reports describe cohorts. They rarely allow an accreditor, a program director, or the student themselves to answer the question: what did this specific person actually demonstrate, in what conditions, at what level? The learner disappears into a percentile.

Third, the process is disconnected from the tools that produce the learning. Learning management systems, simulation platforms, discussion tools, AI tutors and assessment engines all generate rich event streams. Almost none of that data is captured in a form that survives the platform, aligns with a program-level outcome, or carries integrity signals a third party could verify. Coordinators end up re-encoding by hand what the systems already knew.

The result is a compliance ritual that consumes hundreds of faculty hours per cycle, produces evidence that is unfalsifiable in practice, and cannot be re-used for the operational purpose it was designed for: helping programs improve, one cohort at a time. Deans know this. Accreditation reviewers know this. Students, if they thought about it, would know it too.

This paper does not propose new pedagogy or a new accreditation regime. It proposes something narrower and more actionable: a shared machine-readable format for the evidence itself, captured from the first time an activity runs, and portable enough that it can serve program improvement, accreditation, learner mobility and independent research from a single source of truth.

3. What "From Run One" Means

Most standardisation efforts in educational analytics have been retrofitted onto systems that were built without them in mind. The result is predictable: partial coverage, brittle mappings, and long implementation timelines. AoL from Run One is designed around a different discipline: any activity that qualifies for AoL evidence must emit compliant evidence the first time it is deployed to real students.

Operationally, "from Run One" means three things.

It means the evidence schema is part of the activity definition, not an afterthought. When an instructor authors a case discussion, a simulation scenario, a written assignment or an AI-mediated exercise, the outcomes it targets, the rubric dimensions it will surface, and the artifacts it will retain are declared up front — in the same object that describes the activity itself. Instrumentation is not a separate project.

It means every learner run produces a complete evidence envelope, not a sampled one. There is no notion of "evaluating a subset for AoL." The system captures per-student decision events, artifacts, and rubric scores for every run of every activity. Aggregation happens downstream; the primary record is per-learner.

It means integrity signals are captured at emission, not reconstructed later. Timestamps, tool identifiers, prompt versions, model identifiers (where AI is involved), input hashes and authorship signals are attached to each evidence record when it is written. A reviewer three years later can reason about the conditions under which the evidence was produced without relying on the good faith of the reporting institution.

The intent is to make AoL a byproduct of instrumentation rather than a separate reporting activity. If done well, the evidence needed for accreditation, the evidence needed for program improvement, and the evidence a student would want to carry forward all come from the same source, and none of them require a coordinator to reconstruct anything after the fact.

4. The Evidence Model

The standard defines five evidence layers. Each layer has a defined schema, a required set of fields, and rules about what may be extended by implementers. Which layers a record must carry depends on the conformance level it claims (§5.8): context, decision events and artifacts are always present; rubric alignment is added at Level 2 and full integrity signals at Level 3. Within a layer, individual fields may be null when a given activity type does not produce them.

4.1 Contextual metadata

Contextual metadata locates the evidence in time, program and cohort. It identifies the institution, the program and concentration, the course and section, the term, the activity type and its version, and — critically — the specific learning outcomes this activity claims to inform. Learning outcomes are referenced by stable identifiers, not free text, so that mappings survive rewording of the outcome statements themselves.

Contextual metadata also carries the deployment mode: whether the activity was run synchronously in class, asynchronously as homework, proctored, open-book, individual or team. Two runs of the same simulation under different deployment modes produce comparable but not identical evidence, and a downstream analyst must be able to see which was which.

4.2 Decision events

Decision events are the observable moments in which a learner does something the activity is designed to elicit — a choice in a simulation, a submitted answer, a message in a discussion, an accepted or rejected suggestion from an AI counterpart, a peer rating given or received. Each event has a type, a timestamp, an actor, an optional target, and a structured payload.

The decision event vocabulary is intentionally open. The standard specifies the envelope (event_id, event_type, actor_id, timestamp, sequence, payload, context_ref) and reserves a small set of core event types (submit, select, revise, discuss, peer_evaluate, receive_feedback, use_resource), but implementers are expected to extend the type list to describe activity-specific behaviour. Extensions live in a namespaced field so they do not collide across vendors.

4.3 Artifacts

Artifacts are the durable outputs of an activity that a human — instructor, external assessor, the student themselves — might want to inspect. Written submissions, uploaded files, chat transcripts, simulation end-state snapshots, generated media. Each artifact record carries a content hash, a MIME type, a size, an authorship attestation (student, team, AI-assisted with disclosed assistance level), and a storage reference.

Artifact storage itself is out of scope. The standard requires that artifacts be addressable and integrity-verifiable, not that they live in any particular system. A school may host artifacts on institutional storage, a vendor may host them on its own, and a learner wallet may hold copies. What must be true is that the hash in the evidence record matches the artifact retrieved from wherever it lives.

4.4 Integrity signals

Integrity signals let a reviewer reason about the conditions under which evidence was produced. They include tool and version identifiers, prompt or scenario version hashes, AI model identifiers and settings where applicable, session identifiers, rough environmental signals (device class, network reliability indicators, proctoring status if any, within the limits set in §8), and cryptographic signatures over the record itself.

The standard does not require any particular signature scheme. It requires that whichever scheme is used be declared in a proof object on the record envelope (§5.1) with the algorithm, key identifier and signature value, following the same shape adopted by the W3C Verifiable Credentials Data Model. This lets AoL evidence be verified by tools already built for credential verification, without introducing a parallel infrastructure.

4.5 Rubric alignment

Rubric alignment is where the evidence becomes assurance. Each evidence record carries zero or more rubric scores, each of which references (a) the rubric definition by identifier and version, (b) the specific dimension being scored, (c) the numeric or categorical score, (d) the scoring source (automated, instructor, peer, external), and (e) an optional evidence citation — a pointer to the decision event or artifact fragment that the score was based on.

The rubric definitions themselves are separate objects, versioned and portable. This matters: rubrics evolve. Being able to say that a 2023 cohort was scored against rubric v1.2 while the 2026 cohort was scored against v1.4, and to inspect the diff, is a prerequisite for defensible longitudinal analysis.

5. Technical Specification

This section presents the record structure at a level sufficient to build against. The full specification, including field-level constraints and controlled vocabularies, will be published separately alongside the reference implementation; this paper describes the record only at the level needed to evaluate the approach.

5.1 Envelope

Every AoL from Run One record — regardless of the activity type that produced it — shares a common outer envelope:

{
  "aol_version": "0.1.0",
  "record_id": "urn:example:aol:example-bs:2026:run:8a3f...",
  "issued_at": "2026-09-14T15:22:41Z",
  "issuer": {
    "type": "Institution",
    "id": "https://www.example-bs.edu/",
    "name": "Example Business School"
  },
  "subject": {
    "type": "Learner",
    "id": "urn:example:learner:example-bs:2026:0f2c...",
    "pseudonymised": true
  },
  "context": { "comment": "see 5.2" },
  "events": [ { "comment": "see 5.3" } ],
  "artifacts": [ { "comment": "see 5.4" } ],
  "integrity": { "comment": "see 5.5" },
  "rubric_scores": [ { "comment": "see 5.6" } ],
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "ecdsa-jcs-2019",
    "proofPurpose": "assertionMethod",
    "created": "2026-09-14T15:22:41Z",
    "verificationMethod": "did:web:www.example-bs.edu#aol-key-1",
    "proofValue": "z3M..."
  }
}

Examples in this paper use the urn:example: namespace reserved for documentation (RFC 6963) and example-bs.edu hosts, and truncate identifiers and hashes with ...; they are illustrative, not real records.

The envelope is JSON-LD compatible but does not require JSON-LD tooling to be produced or consumed. Implementers who want the full linked-data semantics can attach an @context block; implementers who want plain JSON can omit it. The core fields are stable across both modes.

5.2 Context block (minimal)

{
  "institution": "urn:example:institution:example-bs",
  "program": "urn:example:program:example-bs:mba-full-time",
  "outcomes": [
    "urn:example:outcome:example-bs:mba:lg2.strategic-thinking",
    "urn:example:outcome:example-bs:mba:lg4.ethical-reasoning"
  ],
  "course": "urn:example:course:example-bs:strat-501",
  "section": "2026F-A",
  "activity": {
    "id": "urn:example:activity:example-vendor:market-entry-sim",
    "version": "2.3.1",
    "type": "simulation"
  },
  "deployment_mode": "in_class_synchronous_teams"
}

5.3 Event block (minimal)

[
  {
    "event_id": "urn:example:event:8a3f:001",
    "event_type": "select",
    "timestamp": "2026-09-14T15:04:12Z",
    "sequence": 1,
    "actor_id": "urn:example:learner:example-bs:2026:0f2c...",
    "context_ref": "urn:example:aol:example-bs:2026:run:8a3f...",
    "payload": {
      "prompt_id": "market-entry.q1",
      "option_selected": "B",
      "options_considered_ms": 47000,
      "reasoning_text_ref": "urn:example:artifact:8a3f:reasoning-001"
    }
  }
]

5.4 Artifact block (minimal)

[
  {
    "artifact_id": "urn:example:artifact:8a3f:reasoning-001",
    "mime_type": "text/markdown",
    "size_bytes": 2184,
    "content_hash": "sha256-9b1c...",
    "authorship": {
      "type": "ai_assisted",
      "assistance_level": "feedback_only",
      "disclosed_by": "learner"
    },
    "storage_ref": "https://evidence.example-bs.edu/artifacts/8a3f/reasoning-001"
  }
]

5.5 Integrity block (minimal)

{
  "tool": { "id": "urn:example:tool:example-vendor:simulator", "version": "4.12.0" },
  "scenario_hash": "sha256-41de...",
  "ai": [
    {
      "role": "counterpart",
      "model_id": "example-model-2026-06",
      "settings_hash": "sha256-77a0..."
    }
  ],
  "session_id": "urn:example:session:8a3f...",
  "environment": {
    "device_class": "desktop",
    "proctoring": "none"
  }
}

The proof that signs the whole record sits on the envelope (§5.1), not inside this block, so that a verifier can check it without understanding the rest of the schema.

5.6 Rubric scores (minimal)

[
  {
    "rubric_id": "urn:example:rubric:example-bs:strategic-thinking",
    "rubric_version": "1.4",
    "dimension": "problem_framing",
    "score": 3,
    "scale_max": 4,
    "source": "instructor",
    "evidence_ref": ["urn:example:event:8a3f:001", "urn:example:artifact:8a3f:reasoning-001"],
    "scored_at": "2026-09-16T09:11:00Z",
    "scorer_id": "urn:example:scorer:example-bs:faculty:jsmith"
  }
]

5.7 Versioning strategy

The standard follows semantic versioning. MAJOR.MINOR.PATCH versions are declared in the aol_version field of every record. Until 1.0.0, versions are numbered 0.x and are drafts: any of them may change the envelope, and the compatibility rules below take effect from 1.0.0.

A MAJOR increment signals a breaking change to the required envelope shape or to the semantics of a reserved field. Implementations are expected to support at most two adjacent major versions concurrently, and migration paths must be documented in the release notes.

A MINOR increment adds new optional fields, new reserved event types or new controlled vocabulary entries. Existing conforming implementations remain conforming; they simply do not populate the new fields.

A PATCH increment is reserved for editorial corrections, non-normative clarifications and typo fixes. It does not change what an implementation must do.

Namespaced extensions — vendor-specific event types, custom payloads, institution-specific rubric identifiers — are permitted at any version and do not participate in version compatibility guarantees. They are the escape hatch that keeps the core small.

5.8 Conformance levels

Three conformance levels are defined so that adoption can proceed incrementally.

• Level 1DescriptiveThe implementation emits envelope, context, events and artifacts. Rubric scores may be attached out of band. This is the level a legacy LMS can reach with a modest export adapter.
• Level 2AssuredAll Level 1 requirements, plus rubric alignment records emitted at the time of scoring. This is the level a working AoL program needs.
• Level 3VerifiableAll Level 2 requirements, plus integrity signals and cryptographic proofs sufficient for third-party verification without contacting the issuer. This is the level accreditors and mobility use cases require.

6. Implementation Patterns

The standard is designed to be reachable from three characteristic starting points. Each pattern below sketches the minimum changes required to reach at least Level 1 conformance.

6.1 Existing simulation platform

Simulation platforms already model decisions, timing, and end states internally. Adopting the standard is primarily a schema-mapping and export exercise, not a rewrite. The typical work items are: (i) declare which learning outcomes each scenario claims to inform and record them in the scenario definition; (ii) map internal decision types to the standard's event vocabulary, using namespaced extensions where the internal semantics have no direct equivalent; (iii) emit a per-learner record at run completion, signed with an institutional or vendor key.

The rubric alignment layer typically requires the most conversation with the school. Simulations often produce numeric outputs — market share achieved, budget adherence, decision cycle time — that must be translated into rubric dimensions the program actually recognises. The standard does not prescribe this mapping; it requires only that whatever mapping is chosen be declared explicitly and versioned.

6.2 Existing LMS

Learning management systems are the harder case because their event models are shallower and their artifact stores are more heterogeneous. A practical path to Level 1 conformance runs through the LMS's existing analytics export — most current platforms speak either Caliper or xAPI at some level — and transforms those streams into AoL envelopes on the way out.

Where the LMS already speaks Caliper, the event mapping is largely one-to-one: AssignableEvent, AssessmentEvent, MessageEvent and AnnotationEvent all have natural counterparts in the standard's core event types. The gap is usually in artifact addressability (many LMSes do not expose stable artifact URIs across course archival) and in rubric alignment (few LMS rubric tools currently emit versioned rubric identifiers). An institutional adapter typically closes both.

6.3 New content authoring

For a school or vendor building new content — a new AI tutor, a new experiential activity, a new assessment — the pattern is inverted: the evidence schema is declared first, and the content is designed around what it must emit. This is the "from Run One" case in its strict form. Authoring tools that adopt the standard as a first-class output surface it as fields the author fills in during authoring, not as a compliance checklist reviewed at deployment.

In this pattern, activity authors are asked, at design time, which learning outcomes the activity will inform, which decision events it will elicit, what artifacts it will retain, and against which rubric dimensions the resulting evidence should be scorable. The activity cannot be deployed until those declarations are complete. In return, no post-hoc AoL work is required: the evidence is available from the first cohort.

7. Accreditation Alignment

The standard is deliberately accreditor-neutral. It does not implement any accreditation body's rubric or reporting template. It does, however, aim to produce evidence that is straightforwardly usable in the reporting formats each major body already accepts. The mapping below is indicative, not exhaustive, and will be maintained as a living annex to the specification.

The intent of the mapping is not to reduce accreditation to a data-export exercise. Judgement, narrative and program culture will always be part of accreditation. The intent is to remove the reconstruction burden — to let the narrative be about what the program did with the evidence, not about how the evidence was assembled.

8. Privacy and Learner Rights

A standard whose primary record is the individual learner is, unavoidably, a standard for processing personal data at scale. Every conforming record describes what a person did, when, under what conditions and how well it was judged. Timing data, AI-use disclosures and environmental signals are behavioural data in the full legal sense. The standard therefore treats privacy as a constraint on the format itself, not as a deployment detail left to implementers.

The standard cannot make a deployment lawful on its own. That remains the responsibility of the institution and its processors under whichever regime applies to them, whether the GDPR in Europe, FERPA in the United States, Colombia's Ley Estatutaria 1581 de 2012 or comparable law. What the standard can do is make sure that nothing in the format stands in the way of operating lawfully under any of them. Seven rules serve that end.

Pseudonymous by design. The subject of a record is a pseudonym issued by the institution, never a name, student number or email address. The table that maps pseudonyms to people is held by the institution, outside the evidence store, and never travels with the records. Vendors and other processors work on pseudonymised records only. Pseudonymised data is still personal data: the rule reduces exposure, it does not take the records outside the scope of data protection law.

The institution is the controller. Conforming records name the institution as issuer, and the institution decides the purposes, the legal basis and the retention period of the evidence. A vendor that emits records does so on the institution's behalf. The record's context may carry a privacy block that declares the controller, the purposes the evidence may serve and its retention class. The block is optional in this draft; the working group is expected to make it required at Level 2 before 1.0.

{
  "privacy": {
    "controller": "https://www.example-bs.edu/",
    "purposes": ["assurance_of_learning", "program_improvement", "learner_portability"],
    "retention_class": "accreditation_cycle",
    "policy_ref": "https://www.example-bs.edu/privacy/aol-evidence"
  }
}

Minimal integrity signals. Integrity signals are limited to what a reviewer needs in order to reason about the conditions under which evidence was produced: tool and version identifiers, scenario and prompt hashes, AI model identifiers, and coarse environmental classes such as device type or proctoring status. The standard reserves no field for IP addresses, precise location, keystroke or mouse dynamics, webcam or screen recordings, or biometric data, and conforming records must not carry them in extensions either. Where a proctoring system produces such material, the record may state that proctoring took place; it never contains or references the material itself.

Purpose limitation. Evidence is captured for three declared purposes: assurance of learning, program improvement and the learner's own portability. Using it for anything else, such as admissions, employment screening or disciplinary proceedings, needs a separate legal basis that the standard cannot supply. A rubric score whose source is automated, including a score proposed by an AI rater, must not on its own decide an outcome that affects an individual learner; a human reviews it first. In the European Union, the AI Act classifies AI systems intended to evaluate learning outcomes as high-risk, which brings obligations of its own.

Erasure without breaking integrity. Signed and hash-linked records are deliberately hard to change, which sits uneasily with a learner's right to have their data erased. The standard resolves the tension by keeping personal data out of everything that has to stay immutable. A record is erased by deleting the learner's artifacts and the pseudonym mapping, then replacing the record with a signed tombstone that keeps its identifier and the fact and date of erasure, but no evidence. Aggregate results that were already reported are not recalculated. Anything anchored outside the institution, for example in a public ledger, must be a hash over a batch of records, never a hash of or a pointer to one learner's record.

Aggregation thresholds. Program-level roll-ups shared outside the institution, including with accreditors and with the working group, suppress any figure that describes fewer learners than a declared minimum. This draft proposes a default of 20, which an institution may raise, and should lower only with a documented reason. Small cohorts, narrow concentrations and rare combinations of attributes are where re-identification usually happens.

The learner's own access. A learner can obtain every record of which they are the subject, in the standard's own format, together with the rubric definitions they were scored against. This is the same property that makes evidence portable to a learner wallet, and it also serves the right of access. A learner can contest a score. A contested score is never edited in place: it is superseded by a new rubric record that references the original, so that both the challenge and its outcome remain auditable.

9. Open Standard Governance

An open standard is not the same as a published document. It requires an editorial process, a decision procedure, a licence, and a body of implementers who can rely on it staying open. This section describes the governance model proposed for AoL from Run One.

Licensing. The specification text is released under Creative Commons Attribution 4.0 (CC BY 4.0). Reference implementations contributed by any party are released under the Apache License 2.0. Both licences are chosen for compatibility with existing edtech open source ecosystems and for the absence of copyleft obligations that would deter commercial implementers.

Working group. A steering working group will be convened with three seat categories: business schools (deans, provosts, AoL coordinators), accreditation body representatives (observer or full member as each body prefers), and implementers (edtech vendors, in-house engineering teams, researchers). Seat balance is deliberately weighted toward schools and accreditors, not implementers, to keep the specification aligned with the reporting needs it exists to serve.

Editorial process. Changes to the specification follow a public change-proposal process in the spirit of the IETF and W3C processes. A proposed change is filed as a numbered proposal, receives a mandatory public comment period, and is then either merged, deferred or rejected by working group vote. Editorial decisions and minority opinions are recorded in the specification's release notes.

Versioning cadence. Minor versions are cut on a predictable cadence (initially every six months). Major versions require both a working group supermajority and evidence of at least two independent implementations of the proposed changes. This is intended to prevent the specification from moving faster than its implementers can follow.

Reference implementation posture. Kudzu Partners will contribute the initial reference implementation and commits to maintaining it under Apache 2.0 for the first two major versions. The reference implementation is not the specification. If it diverges from the specification, the specification is authoritative and the implementation is treated as a bug.

Precedent. The governance model draws directly on prior work by 1EdTech, formerly IMS Global (Caliper Analytics, and Open Badges 3.0 since the Open Badges community joined it), by ADL and IEEE (xAPI, standardised as IEEE 9274.1.1), and by the W3C Verifiable Credentials working group. It is not novel; it is deliberately conventional, because conventional governance is what enables trust to accumulate over multiple versions.

10. Adoption Roadmap

The specification is meaningful only if it moves from document to deployment. Four phases are proposed.

Phase 0 — Specification (2026 Q4 to 2027 Q1). This draft is published for public comment and the working group is convened. The reference implementation is developed in parallel against the draft, with the explicit purpose of surfacing ambiguity in the text before ratification.

Phase 1 — Reference implementation and open source tooling (2027 Q1 to 2027 Q3). The reference implementation is released under Apache 2.0. It covers record emission, verification, rubric alignment storage, and a minimal viewer suitable for coordinators and external reviewers. Companion libraries in Python, TypeScript and Java are released for embedding in existing platforms. Conformance test suites are published so that any implementation can self-check without contacting the working group. The first stable version (1.0.0) is ratified at the end of this phase, once the reference implementation and at least one independent implementation pass the conformance suite: the same two-implementation rule that later major versions must meet.

Phase 2 — Early adopters (2027 Q3 to 2028 Q2). A small cohort of business schools — targeting five to ten in the first wave, geographically distributed — deploys the specification in production. The commitment is not to standardise their entire AoL program overnight, but to instrument at least one course per program at Level 2 conformance and share the resulting evidence, aggregated and thresholded as described in §8, with the working group for review. Early-adopter feedback drives the 1.x minor-version releases.

Phase 3 — Accreditation body integration (2028 Q3 onwards). With production evidence from Phase 2 in hand, the working group opens formal conversations with AACSB, EQUIS, AMBA and ACBSP about recognising conformant evidence within their existing reporting frameworks. The ambition is not to change what accreditors evaluate, but to reduce the reporting burden on schools that already produce evidence in the standard form. Recognition may proceed at different speeds with each body; the specification does not depend on any single body's endorsement.

Throughout all phases, the specification's success metric is deliberately narrow: how many student records were produced against a conformant schema in the preceding twelve months, across how many institutions and how many implementers. Governance conversations, endorsements and press are secondary. If the evidence is not being produced, the standard has failed regardless of its reception.

11. Call to Action

Business education has spent two decades building the vocabulary of learning outcomes and the ritual of assurance without ever building the evidentiary infrastructure that would make either of them meaningful at the level of the individual learner. The gap is now large enough to be a credibility problem for accreditation itself, and it is closable with tools already available to us.

Three parties can move this forward, and each has a specific first step.

Deans and provosts can commit at least one course per program to Level 2 conformance in the 2027–2028 academic year, using any implementation of the specification. The commitment is small, the evidence produced is immediately usable in the next accreditation cycle, and the operational cost is bounded because the specification is designed to attach to activities schools are already running.

Accreditation bodies can appoint an observer to the working group, without committing to endorse the standard. Observation costs nothing and gives the working group direct signal about what evidence formats would reduce, rather than increase, the burden on the schools each body accredits.

Edtech vendors, in-house engineering teams and researchers can implement Level 1 conformance in at least one product surface during 2027, publish the conformance report, and contribute at least one improvement back to the specification. A single non-trivial implementation contributes more to the specification's maturity than any amount of committee time.

Kudzu Partners has published this draft, will release the reference implementation under Apache 2.0, and will host the working group's initial meetings. The working group, the specification and the reference implementation will be open. Institutions and individuals who would like to be founding participants are invited to contact the author.

Assurance of learning was never meant to be theatre. It was meant to be evidence — evidence that programs deliver what they promise, at the level of the person the promise was made to. The tools to make that true exist. What is missing is the shared format that lets them talk to each other, and the discipline to capture the evidence from the first time an activity runs, not the last time before the accreditation visit.

That is what this standard is for.

Appendix A — Related Work

The specification is built in conscious continuity with several prior open initiatives, and readers evaluating it should read it alongside them.

1EdTech Caliper Analytics (developed when 1EdTech was still named IMS Global) defines an event vocabulary and sensor API for learning analytics. AoL from Run One reuses Caliper event shapes where they exist and treats Caliper-instrumented systems as first-class sources.

xAPI (Experience API, formerly Tin Can), stewarded by ADL and standardised as IEEE 9274.1.1, defines the actor–verb–object statement structure for learning experience records. The standard's decision-event layer is structurally compatible with xAPI and can be lossily projected into an xAPI Learning Record Store when required.

Open Badges 3.0 / 1EdTech Comprehensive Learner Record define portable credential structures and verification models. AoL from Run One does not compete with credentialing standards; a conformant evidence record can be referenced from an Open Badge or CLR credential as its underlying evidence.

W3C Verifiable Credentials Data Model provides the cryptographic proof structures adopted for the standard's integrity block, so that AoL evidence can be verified by existing credential tooling without a parallel infrastructure.

Learner-held, independently verifiable credentials (Blockcerts, originally developed at the MIT Media Lab with blockchain anchoring, and the Digital Credentials Consortium's work on learner wallets) provide precedent for durable, learner-held evidence portability. The standard does not require blockchain anchoring, but its proof structure is compatible with it for institutions that want that guarantee.

Appendix B — Glossary (selected)

Activity. A defined unit of learning experience — a simulation scenario, an assignment, a discussion, a tutorial session — that emits at least one evidence record per learner run.

Assurance of Learning (AoL). The systematic process by which an institution demonstrates that students achieve stated learning outcomes.

Conformance level. One of three declared levels (Descriptive, Assured, Verifiable) that an implementation may claim, corresponding to increasing evidence completeness.

Decision event. An observable moment in a learner's interaction with an activity that the activity was designed to elicit.

From Run One. The requirement that a conforming activity produce complete evidence the first time it is deployed to real learners, not retrofitted after the fact.

Integrity signals. The metadata and cryptographic proofs that let a reviewer verify the conditions under which evidence was produced without contacting the issuer.

Pseudonym. The identifier a record uses for its learner, issued by the institution and meaningless without the mapping the institution holds separately. Pseudonymised records remain personal data.

Rubric alignment. The layer of the evidence model in which observed events and artifacts are scored against a versioned rubric on named dimensions.