Learnlog Assistance Capture Profile and Optional Event File Representation

Learnlog Assistance Capture Profile and Optional Event File Representation Quantum Learning Machines

kumar@quantumlearningmachines.com

education learning logging integrity redaction This document proposes Learnlog as an assistance capture profile for measuring AI scaffolding, with xAPI and Caliper bindings. Its motivation is Quantum Learning Machines' work on QLM Measure. The profile defines what assistance was requested, generated, transmitted, displayed, or accepted; what an instrument captured; and which facts remain unknown. Existing logging ecosystems can carry these definitions. Their reviewed base specifications do not, by themselves, require this particular combined agreement on assistance, achieved capture, unavailable information, and mapping provenance. Existing AI and tutoring profiles already cover important parts of the domain.The document retains the existing Learnlog event file representation, hash chains, optional signed heads, and verifiable redaction as an optional carrier. An implementation can use the assistance profile without producing that file representation. Experimental companion software constructs importer-observation records in xAPI and Caliper while preserving source assistance assertions separately. The implementation does not establish independent interoperability, truthful or complete capture, independent learning, or scientific equivalence across products. The core file format is unchanged in this revision. Note to Readers This individual Internet-Draft is a working proposal for discussion, not an IETF-approved standard. Revision -02 positions Learnlog primarily as an assistance capture profile with xAPI and Caliper bindings. The existing file representation is optional. The companion implementation is experimental, and its importer-observation mode is not a direct reconstruction of learner actions. All 20 core sourcecode blocks, the core hash algorithm, Appendix A test vectors, and the previously versioned companion definitions are preserved. This revision makes no first-profile, exhaustive-gap, scientific-equivalence, certification, or superiority claim. records changes, lists open questions, and describes implementation limits.

Introduction Learnlog is proposed as an assistance capture profile for measuring AI scaffolding, with xAPI and Caliper bindings. A request for a hint, an answer generated by software, and a hint displayed to a learner are different observations. Combining them under a single count of "help" can change the question an analysis answers. Interpreting a learner's work also requires knowing the instrument's observation boundary: a record from one application does not establish whether the learner used another tool. The profile makes these distinctions explicit so that producers and readers can examine them without reconstructing their meaning separately for every export.The proposal originated in Quantum Learning Machines' internal work on measuring AI scaffolding while building QLM Measure. The company made the assistance contract an internal logging requirement for its products and decided to open the definitions and logging approach for wider review. This origin is the author's account of development motivation, not a community needs survey or evidence that every QLM product conforms. The working repository remains private; the decision to open the work does not establish a completed public release.The profile has two layers: domain definitions and capture requirements (), and versioned bindings to existing logging ecosystems (). xAPI and Caliper supply carrier models; Learnlog specifies the assistance agreement that the proposed bindings carry. The file representation in the remaining sections is an optional compatibility carrier for deployments that need its integrity and redaction behavior. An external product can retain its native log format; a supported transformer adapter can produce the profile representation.The intended use is prospective instrumentation of learning and assessment activity, including AI assistance. Recording a state when the producing system observes it can preserve evidence that a later export cannot recreate. Retrospective transformation can retain source distinctions and disclose missing information, but it cannot manufacture absent display events, model versions, capture windows, or evidence about external AI. A log supports inspection of assisted performance; it does not establish independent ability, a learning effect, or the applicability of a prior study.The existing Learnlog file representation has the following properties:

Events are typed. An event schema defines the event types of one area, such as a prediction committed in a simulation ().
Every event can state who acted and toward whom. A request for help and a scaffold given in reply are events of their own, whether the helper is a person or a program (, ).
Entries are chained by hash, and a producer can sign the latest hash. A reader who trusts the signing key can then detect a change to the signed entries that was made without that key (). states the limits.
An event can be redacted without breaking the chain ().
Records are kept in files. A record can be written, and its hashes checked, without a server.

The structure of files, records, and event schemas follows qlog , which defines structured logging for network protocols. This document adds integrity rules and the members that a record of learning needs.

Scope The proposed assistance requirements are stated in . This working revision does not yet define a complete assistance-profile conformance target; unpublished companion files do not supply normative requirements. The file, event, integrity, serialization, and registration requirements elsewhere apply when the optional Learnlog file representation is used. A carrier binding also needs to satisfy its own ecosystem's requirements. A claim about one layer does not establish conformance to the others.This document defines:

an experimental assistance capture profile specifying assistance states, capture requirements, explicit unavailable information, and versioned ecosystem bindings ();
the structure of files, records, entries, and events ( through );
event schemas for consent, assistance, and dialog, which are not tied to one subject area ();
the canonical form, the hashes, redaction, signed heads, and verification ();
two JSON serializations ();
registries for file schemas and event schemas ().

The following are out of scope:

Event schemas for subject areas. Other documents can define them.
Transport and storage interfaces.
Estimates of what a learner knows, such as scores or mastery values. A record states what the producer recorded. This document leaves conclusions drawn from a record to other formats.
Distribution of the keys that verify signed heads.
The legal basis for collecting data about learners.
Decisions about whether an intervention or research finding applies in a new setting. Such decisions can cite records but are not event facts or core verification results.

Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. Data structures are defined in the Concise Data Definition Language (CDDL) . Examples are in JSON . Some figures wrap long lines as described in . This document uses the following terms:

Learner:: A person whose learning activity is recorded.
Subject:: The learner that a record is about.
Producer:: The software that writes a record.
Holder:: A party that stores a record or passes it on. The producer is the first holder.
Verifier:: Software that checks a record against this document.
Record:: A header and the entries about one subject, written by one producer. A record forms one hash chain.
Entry:: One element of a record. An entry carries one event and the hashes that bind it into the chain.
Event:: A typed description of one action.
Event schema:: A definition of a namespace of event types.
Head:: A statement that names the latest entry of a record at some moment ().

Assistance Capture Profile This section specifies the proposed assistance agreement and its claim boundaries. It is a versioned companion contract, not new required members of the core CDDL. The experimental payload identified as urn:learnlog:proposal:assistance-capture:0.1.0 uses schema_version 0.1.0-draft. It is not an IETF-registered schema. Independent implementation and methodological validation remain pending. The older qlm:assistance-context:0.1.0 companion profile remains a distinct, unchanged definition; this contract does not silently revise its meaning. A producer implementing the proposed assistance requirements MUST preserve the assistance, capture, knowledge-state, and provenance distinctions defined in this section. It MUST identify the payload version and carrier binding. It MUST NOT replace unavailable information with a guessed observed value or silently discard required information during transformation. A binding that cannot preserve required information MUST reject the conversion or report the loss without claiming lossless preservation. Passing these checks establishes structural consistency under the stated rules, not that an asserted event occurred. The supplied companion schema and consistency checker are informative reference-implementation artifacts. They are not unpublished normative dependencies. A future complete conformance target needs a fixed, independently retrievable specification of its schema, consistency rules, and bindings, with version and change control. Until then, implementations can report the particular checks performed but cannot claim complete assistance-profile conformance to this draft. The prepared review package includes the exact reference files and a SHA-256 manifest for inspection; this does not establish public availability.

The Specific Agreement Being Proposed The xAPI Profiles specification already provides controlled vocabularies, statement templates, and patterns . Caliper defines event and entity models with extensibility . Domain work also exists: Rustici Software has proposed an AI xAPI profile , and GIFT documents xAPI statements for tutoring interactions, learner state, and environment adaptations . Learnlog therefore makes no claim that assistance logging, domain profiling, or semantic interoperability is new, or that existing ecosystems cannot represent the necessary information. The retrieved draft version 0.1.0 of the AI-Mediated Learning Interactions Profile from inXsol LLC / TLA Toolbox has direct conceptual overlap: it defines requested AI scaffolds, received AI responses, incorporated AI output, assisted and independent submission concepts, and model-version context. These are existing proposed domain definitions, not an empty vocabulary space for Learnlog to fill. Their presence does not establish that any particular submission was independent; that assertion still needs evidence about its observation boundary. DataShop's Tutor Message format guide also defines paired help-request and tutor-response messages, with hint identifiers and ordering information. Separating a learner's request from a tutor's response therefore predates this proposal. Learnlog's candidate contribution concerns an explicit combined contract for assistance meaning, achieved capture, unavailable information, and mapping provenance; its value needs to be established against such existing work. The bounded gap is that the reviewed base specifications do not by themselves require this particular combined agreement: distinct assistance lifecycle observations; a declared instrument and achieved capture boundary; explicit unavailable-information states; and provenance for mappings used in a proposed combined measurement. Profiles can supply such requirements. The proposal is to make them reusable and inspectable across products, then test their usefulness. A profile-by-profile comparison may reveal overlap, a better existing home, or requirements to remove. A separate file format is not necessary merely to express this agreement.

Separate the Observable Assistance States A contract needs to define the subject of each assertion, its observation unit, the instrument that supplied it, and the evidence for that assertion. The prototype distinguishes these source-supported observations:

Requested:: A learner or other identified actor asked for assistance. The request does not establish that assistance was produced.
Generated:: A producing system generated assistance content. Internal generation does not establish transmission or display.
Transmitted:: The instrument observed assistance being sent to a specified destination. Sending does not establish display or use.
Displayed:: The instrument observed assistance being presented in a specified interface. Display does not establish attention, comprehension, or learning.
Accepted:: The instrument observed the interface action defined by the product as accepting assistance. Its product-specific meaning needs to remain explicit; it does not by itself establish incorporation, agreement, or learning.

For example, a learner requests a hint, the server generates text, and the interface displays it. There are three observed lifecycle actions. A count of requests can be one, a count of generated responses can be one, and a count of displays can be one; adding these counts does not establish three help episodes. A fourth event saying that the learner read or learned from the hint would require its own evidence. If the request and generated text are recorded but display is unobserved, observed display remains unavailable. A later analyst cannot fill that gap using the successful generation alone. These states are proposed companion-contract concepts, not additions to the core event registry. The existing assist:help_requested and assist:scaffold_provided names and CDDL are retained. The meaning of an absent request link was revised in this revision as explicitly described in ; unchanged syntax does not imply unchanged semantics. A new lifecycle state needs an explicit versioned event definition or binding; it cannot be inserted as an undeclared core event or equated with scaffold provision without a justified mapping.

Declare the Instrument and Observation Boundary The proposed contract requires a capture instrument identifier, explicit information about which assistance states that instrument can observe, the systems and event classes inside its boundary, exclusions, an observation window, and achieved coverage. Relevant product and model identity or revision information also needs an explicit knowledge state. Capability and planned capture describe what an instrument could or intended to collect; achieved coverage describes what was captured within the stated boundary and window. One does not establish the other. A claim of complete capture applies only within an explicitly stated boundary and observation window, with supporting evidence. It does not include an uninstrumented browser tab, another device, or external AI unless those are explicitly inside the demonstrated boundary. A source's completeness claim remains a source assertion. Independent checks against actual product behavior are needed to assess its accuracy. The prototype can check required fields and evidence references; it cannot establish that a producer's coverage claim is true. The contract does not require raw conversations, prompts, or assistance content. A deployment should collect the minimum evidence needed for its declared purpose, use scoped identifiers, and control access and retention (). Optional source references and context can support audit without making full learner text mandatory.

Preserve What Is Unknown and Why The prototype represents important assertions with an explicit knowledge state, an explanation, and evidence references. Its current states are observed, not_collected, not_reported, not_reviewed, unknown, and not_applicable. An observed value needs supporting evidence. An unavailable state must not carry a guessed observed value. These states remain candidates for review and are not asserted to be an exhaustive measurement taxonomy. not_reviewed means the relevant material has not yet been examined for this assertion. not_reported requires a documented review of specified material that did not report the information. not_collected needs evidence about the capture process; silence in an export does not establish that the original system failed to collect it. unknown records an unresolved fact when a narrower supported state is unavailable. not_applicable needs a reason tied to the assertion. Review scope and evidence need to accompany these distinctions. A valid record with zero displayed events therefore supports a zero only for a question whose boundary, capture evidence, inclusion rules, and denominator justify that interpretation. Otherwise, the display count may be unavailable. A missing model version remains unavailable; a transformation must not invent one from a product name or assumed release date. Data availability, a researcher's review status, and whether a study applies to a new setting are separate questions.

Support Existing Logging Ecosystems The experimental bindings carry the full assistance capture payload in documented xAPI and Caliper extension locations. The xAPI materials include a draft profile with a statement template. The Caliper materials identify the applicable event model and extension requirements. The binding identifiers use example.org as unpublished draft identifiers; they are not registered or deployed vocabulary endpoints. These bindings are implementation work within established ecosystems, not a new transport protocol. The draft xAPI profile identifier is https://example.org/learnlog/proposal/assistance-capture-profile, with corrected binding version 0.1.1-draft. The capture payload version remains 0.1.0-draft. It reuses the Activity Streams create verb and defines a template for creating an observation record. The current xAPI encoding targets the legacy 1.0.3 statement shape ; it does not claim conformance to IEEE xAPI 2.0. The Caliper 1.2 encoding uses the General Profile's base Event, a SoftwareApplication actor, Created action, and DigitalResource object, with the profile payload in event extensions. It uses the standard transport envelope without adding custom envelope properties. The xAPI caller supplies an explicit account-system homepage URL and account name separately from the importer software identifier. The bounded implementation supports HTTP(S) homepages; an arbitrary importer URN is not an account homepage. Account ownership is a caller assertion, not an authenticated fact. The constructor omits Statement version. Its reader accepts stable 1.0.x Statement versions, including the 1.0.0 supplied by an LRS when absent. Statement version is distinct from the HTTP X-Experience-API-Version header. These rules follow the legacy Statement specification . The implemented mode records an importer's creation of an observation record for a source record. Its carrier actor identifies the importer, and its carrier time identifies creation of that observation record. The source assistance assertion, its source-scoped subject identifier when available, and its native time and unavailable-information states remain inside the payload. An importing application MUST NOT invent a learner identity or substitute creation time for an unknown source action time. A server generation record does not thereby become a learner's use of a tool. Example source observations are synthetic. Live executions need the actual importer identity and creation time; fixture values do not describe an actual product or learner. An importer-observation binding is useful when a retrospective source lacks the actor or time required by a native-action carrier model. It does not reconstruct a native learner event. An analyst MUST use the source assistance assertions and their evidence when counting assistance; counting carrier import events instead answers a different question. A future native-action binding needs separately justified mappings and adequate source evidence. The companion software constructs complete records and performs local validation, round-trip, and rejection checks for this limited mode. Its verification reports identify the exact records, rules, and tool versions checked. Those checks do not establish certified carrier conformance, live learning-record-store exchange, preservation of original integrity guarantees, or independent cross-product interoperability. The separate evaluation toolkit's experimental encodings concern their own frozen profile and do not establish conformance to this new contract. A binding to the existing Learnlog representation must use declared extension points and versioned event definitions, while preserving the current core CDDL and integrity rules. Existing records keep their original commitments. Transcoding a record does not preserve its original signature by default; a transformation needs to retain the original artifact and state any lost guarantees. Common serialization and matching names do not establish scientific equivalence. Any pooled measurement still needs an operational definition, unit, denominator, capture requirements, and a supported comparability decision.

Design Overview A log file holds one or more records. A record holds a header and a sequence of entries. Each entry holds one event.

Structure of a log file log file +-- record +-- header what the record is about +-- entry 1 one event and its hashes +-- entry 2 +-- ... +-- signed heads signed statements of the latest entry Each entry holds the hash of its event and the hash of the entry before it. The first entry holds the hash of the header, and every entry hash covers that hash as well. A change to the header or to an earlier entry therefore changes every later entry hash. A producer can sign a statement of the latest entry hash, which gives a verifier a fixed point to check against.

The hash chain of a record +--------+ +---------+ +---------+ +---------+ | header |<------| entry 1 |<------| entry 2 |<------| entry 3 | +--------+ prev +---------+ prev +---------+ prev +---------+ hash | hash | hash | event hash event hash event hash | | | event 1 event 2 (redacted) An entry commits to the hash of its event. The event itself can be removed later, and the chain still verifies (). Event types live in namespaces that event schemas define. This document defines schemas for three namespaces that are not tied to one subject area. Other schemas are identified by URI.

Log Files A log file takes one of two forms. A contained file holds one or more records (). A sequential file holds one record and grows by appending (). Both forms hold the members of the log-file group, as in .

LearnlogFile and the members common to all log files LearnlogFile = { log-file, records: [+ Record] } log-file = ( file_schema: text, serialization_format: text, ? title: text, ? description: text )

file_schema:: A URI that identifies the file schema ().
serialization_format:: The media type of the serialization ().
title, description:: Free text about the file. These members SHOULD NOT hold information about a learner.

No hash covers these members. A producer SHOULD write file_schema and serialization_format within the first 256 octets of a file, as also asks, so that a tool can identify the file from its start. The CDDL in this document has two root rules, LearnlogFile and LearnlogFileSeq. A third rule, SeqItem, describes each later element of a sequential file.

Contained Files A LearnlogFile is one JSON text that holds one or more records. It suits export and exchange. Its file schema URI is urn:ietf:params:learnlog:file:contained. The records in a file are verified one at a time. They can come from different producers and describe different subjects.

Sequential Files A LearnlogFileSeq holds one record and grows by appending. It suits a log that is written while the learner works. Its file schema URI is urn:ietf:params:learnlog:file:sequential.

LearnlogFileSeq definition LearnlogFileSeq = { log-file, record: RecordStart } ; every element after the first SeqItem = Entry / SignedHead The first element of a sequential file is the LearnlogFileSeq object. Every later element is a SeqItem. An element with a seq member is an Entry. Any other element with a head member is a SignedHead. Entries appear in order of seq. A producer writes a SignedHead after the entry that it names, and a reader accepts one at any position. The Entry elements, in file order, are the entries of the record, and the SignedHead elements are its signed heads. In a sequential file, event_schemas lists the schemas known when the file is started.

File Schema URIs A registered file schema uses a URN of the form urn:ietf:params:learnlog:file:<identifier> (). Any other file schema uses a URI that its definer controls and MUST NOT use that URN form. Such a URI is not registered.

Records A record holds a header and the entries about one subject, written by one producer.

Record definition record-start = ( header: RecordHeader, event_schemas: [+ text], ? truncated: Truncation ) RecordStart = { record-start } Record = { record-start, entries: [* Entry], ? signed_heads: [+ SignedHead] }

header:: The record header ().
event_schemas:: The URIs of the event schemas used in the record (). As in , the list is a hint to tools about the event namespaces in the record. No hash covers it (), and it can grow with the record. A record MAY hold events from schemas that are not listed.
truncated:: Present when the oldest entries were removed ().
entries:: The entries, in order of seq ().
signed_heads:: Signatures by the producer over heads of this record ().

The CDDL in this document defines what a producer writes. A reader MUST ignore a member that it does not recognize, wherever the member appears. A hash or a signature covers such a member only in a header, an event, or a head. A producer SHOULD NOT add members anywhere else.

Record Header The header states what a record is about and is fixed when the record is created.

RecordHeader definition RecordHeader = { record_id: text, subject: text, hash_alg: HashAlg, created: Timestamp, ? producer: Producer, * text => any } Producer = { name: text, ? version: text, * text => any } HashAlg = "sha-256" / text ; lowercase hexadecimal HashValue = text .regexp "([0-9a-f][0-9a-f])+" ; RFC 3339, UTC only Timestamp = text .regexp "[0-9]{4}(-[0-9]{2}){2}T[0-9]{2}(:[0-9]{2}){2}([.][0-9]{1,9})?Z"

record_id:: An identifier for the record, unique among the records of the producer. A version 4 UUID is RECOMMENDED.
subject:: A pseudonymous identifier for the learner. gives the requirements.
hash_alg:: The hash algorithm used throughout the record. The value is a name from the IANA "Named Information Hash Algorithm Registry" . That registry gives the output length of each algorithm, and the length MUST be at least 256 bits. Implementations MUST support sha-256 .
created:: The time the record was created.
producer:: The name and version of the software that writes the record.

A header MAY hold other members. The record hash () covers every member, so a change to the header changes the record hash and every entry hash. A Timestamp is a date and time in the format of , in UTC, with an uppercase T and the suffix Z. The pattern in admits some impossible values, such as month 13. A Timestamp MUST also be a valid date and time. The second 60 is valid only in the time 23:59:60. A HashValue is the whole output of the hash named by hash_alg, written as two lowercase hexadecimal digits for each octet.

Entries

Entry definition Entry = { seq: Seq, time: Timestamp, event_hash: HashValue, prev_hash: HashValue, entry_hash: HashValue, ( event: Event // redacted: true ) } ; a position in a record, from 1 to (2^53)-1 Seq = 1..9007199254740991

seq:: The position of the entry in the record. The first entry of a record has seq 1. Each later entry has the seq of its predecessor plus 1. A Seq is an integer of at least 1 and below 2^53.
time:: The time the event occurred, as observed by the producer. Order within a record is given by seq. Values of time SHOULD NOT decrease from one entry to the next.
event_hash:: The hash of the event ().
prev_hash:: The hash that links the entry to what precedes it ().
entry_hash:: The hash of the entry ().
event:: The event ().
redacted:: Present with the value true, in place of event, when the event was removed ().

An entry holds exactly one of event and redacted. A producer appends an entry when the event occurs, or as soon after as it can. A written entry keeps its position and its hashes. This document permits two changes to the entries of a record. Redaction removes an event, and a party that kept the event can put it back (). Truncation removes the oldest entries (). A historical import needs to identify the action that the new event actually records. When a profile records an importer observing a source row, time is the time of that import observation, not an invented date for the original classroom action. The source timestamp, its precision, its clock basis, and any relative offset belong in the profile-defined provenance. An unavailable absolute source time remains unknown. The importer is the actor of an import-observation event; a quoted speaker is a separately identified source participant. A profile that instead represents the original action needs sufficient source evidence for the original actor and occurrence time and needs to state how that evidence was obtained. Neither construction turns a retrospective import into a contemporaneous observation by the original system.

Truncation A holder can remove the oldest entries of a record, for example to meet a retention limit. The truncated member then holds the seq and entry_hash of the last entry that was removed.

Truncation definition Truncation = { seq: Seq, entry_hash: HashValue } The first remaining entry has a seq of truncated.seq plus 1 and a prev_hash equal to truncated.entry_hash. A record can be truncated more than once. The truncated member then names the last entry removed overall. A holder can remove every entry, which leaves entries empty. A signed head that names an entry before truncated.seq can no longer be compared with an entry, and a holder MAY remove it. A holder SHOULD keep every other signed head. A verifier cannot check the entries that were removed. A change to the header still shows in the remaining entries, because every entry hash covers the record hash (). states what such a check establishes.

Events An event describes one action: something the learner did, or something another party did that bears on the learner's work.

Event definition Event = $Event event-type<Name, Data> = { name: Name, salt: Salt, data: Data, ? actor: Party, ? to: Party, ? session: text, ? activity: Activity, ? instrument: Instrument, * text => any } ; 22 or more characters of the base64url alphabet Salt = text .regexp "[A-Za-z0-9_-]{22,}" The event-type rule is a CDDL generic. An event type is an instance of the rule that fixes the name and the type of data. The $Event socket collects the instances ().

name:: The event type, written as a namespace, a colon, and a type identifier ().
salt:: A random value that keeps a removed event from being guessed from its hash (). For each event, a producer MUST generate at least 16 octets from a cryptographically secure source and encode them in base64url without padding .
data:: An object with the members that the event type defines.
actor:: The party that performed the action (). When absent, the actor is the subject.
to:: The party the action was directed at (). When absent, an action by another party was directed at the subject. An action by the subject then has no stated addressee.
session:: An identifier that groups the events of one continuous period of use.
activity:: The task in which the action took place ().
instrument:: How the data of the event was produced ().

An event MAY hold other members. The event hash covers every member of the event.

Parties A Party describes who acted or who was addressed.

Party definition Party = { role: Role, ? kind: "human" / "software", ? id: text, * text => any } Role = "learner" / "instructor" / "assistant" / "peer" / "guardian" / "system" / text The role member has one of these values:

learner:: A person who is learning. A learner without an id is the subject of the record.
instructor:: A party responsible for teaching the subject in this activity.
assistant:: A party that responds to requests and has no teaching responsibility.
peer:: Another learner.
guardian:: A person who acts for the subject, such as a parent.
system:: The producer acting in none of the roles above, for example a simulation that reveals an outcome.

Other values MAY be used. The kind member states whether the party is a person (human) or a program (software). When the member is absent, a learner, peer, or guardian is a person, and a system is a program. The member is REQUIRED with any other role. The CDDL in does not express this rule. The id member identifies a party other than the subject. For a person, the value is pseudonymous and follows . For a program, the value names the program. shows how some common parties are described. Examples of parties

Party	role	kind
A teacher working with the learner	instructor	human
An intelligent tutoring system	instructor	software
A general AI chat assistant	assistant	software
A classmate	peer	human

When the actor is a program, the instrument member () describes the model or the version that produced the data.

Activities The meaning of an event can depend on the task it belongs to. A producer SHOULD include activity in every event that belongs to a task.

Activity definition Activity = { id: text, ? version: text, ? variant: text, * text => any }

id:: An identifier for the task, such as a URI.
version:: The version of the task content.
variant:: The form of the task that this learner received, when forms differ. A random seed is one example.

Instruments The instrument member states how the data of an event came to be. A reader needs it to weigh an event that a model wrote or judged.

Instrument definition Instrument = { source: "deterministic" / "model" / "human" / text, ? model: text, ? config_hash: HashValue, ? parameters: { * text => any }, ? validated: bool, * text => any } The source member has one of these values:

deterministic:: Fixed program logic produced the data.
model:: A statistical or generative model produced the data. A hint written by a language model and a transcript of speech are examples.
human:: A person entered or judged the data.

Other values MAY be used. The remaining members are:

model:: The identifier and version of the model or program.
config_hash:: The hash of the configuration that governed the output, such as a prompt (). The producer chooses the octets that are hashed and needs to keep them for the hash to be of use.
parameters:: Settings that affect the output, such as a sampling temperature.
validated:: True when a deterministic check accepted the output of a model before it was used.

An event without an instrument member makes no statement about how its data was produced. The producer.version member identifies recording software; instrument.model identifies the model or program that produced the event data. Keeping these identifiers distinct lets a reader inspect changes in either. A configuration hash identifies retained octets; it does not make those octets available, show that the named configuration was executed, or make a probabilistic output reproducible. The validated member reports a deterministic acceptance check, not empirical validation of educational effectiveness or a learner's knowledge.

Event Names and Event Schemas Event types are grouped in namespaces, as in . An event schema is a document that defines a namespace or extends one. The name of an event is the namespace identifier, a colon, and the type identifier. Each identifier starts with a letter from a to z and continues with such letters, digits, or underscores. Each event schema has a URI. A registered schema uses the form urn:ietf:params:learnlog:events:<namespace> (). A schema that extends a namespace adds a fragment identifier to the URI of that namespace. Any other schema uses a URI that its definer controls and MUST NOT use that URN form. A URI that contains a domain name SHOULD include a month and year in the form mmyyyy. gives the same rule, to avoid problems when a domain name changes ownership. A record can hold an event whose schema a tool does not know. Such an event does not match the CDDL that the tool has. Verification () checks its hashes like any others and does not depend on its schema.

Defining and Extending Event Types An event schema adds each of its event types to the $Event socket. The lines below, taken from the example schema in , define the event type sim:prediction_committed. $Event /= event-type<"sim:prediction_committed", SimPredictionCommitted> Each data type in this document ends with a group socket named after the type, such as $$dialog-message-extension. A later schema can add members to the data type through that socket.

Guidance for Schema Designers The points below apply to any event schema.

Define events for actions that have meaning in the subject area, such as a prediction committed before an experiment or a claim filed with its evidence. Interface activity, such as clicks and page views, does not belong in a record unless a schema gives it that kind of meaning.
Record what happened and leave conclusions out. A detected misconception is a judgment about the learner. An event that holds one SHOULD carry an instrument member.
Refer to an earlier entry of the same record by its seq.
Allow text written by a learner to be left out. Free text can hold personal data. A hash can stand in for the text, within the limits that describes.
State which members can identify a person.
Prefer integers and strings to fractional numbers where exact values matter ().

Companion Profiles for AI Use This subsection gives non-normative guidance. It adds no core fields or event types. A companion profile can use the extension points of the header and events to state context needed by a particular deployment. The profile needs its own identifier, version, and public specification. Event-schema URIs follow . A profile identifier is not a registration in the registries requested by this document. A profile can distinguish practice, assessment, and other activity stages; identify the policy that permitted or prohibited specified assistance; and bind that policy to the relevant actor, task, stage, and period. Permission to use assistance in an activity is separate from consent to collect, use, or disclose data (). Neither can be inferred from the other. A policy assertion also does not establish compliance. A profile can state which channels, sessions, activities, and periods the producer planned to observe, which it asserts it captured, and which it excluded. Planned capture and achieved capture are different assertions. A missing assistance event does not demonstrate that no assistance occurred. Outside applications, other devices, between-session use, a capture interruption, and unavailable content can leave relevant exposure unknown. Describing a gap does not establish that AI was used in that gap. The header is fixed when a record is created (). A plan stated there is not a later completion report. A change in stage, applicable policy, model, configuration, or observation coverage can be represented by starting another record with the new context, or by an explicitly defined extension carried in a hashed event. A profile using such an extension needs to define its effective scope and how events refer to the context. This document defines no runtime context-update or capture-completion event, and modifying an existing header changes the hash commitments. A profile can require the existing actor, activity, session, and instrument members in particular events. It can also identify where retained content or configuration is available to an authorized reviewer. A hash or content reference alone does not give that reviewer the semantic content needed to classify a scaffold, and access can be limited by . Profiles need to distinguish missing information from information that has not been reviewed. Conditions such as whether AI changed practice, comparison-group exposure, or grading usually require evidence beyond one record. Condition assessments and judgments about the applicability of educational research belong in separately specified analytical records. Those records can refer to the relevant learnlog record and entries, state the reviewed scope and comparators, and preserve unresolved questions. The core verifier does not endorse those judgments or decide whether a study needs to be repeated. A concrete assistance or import profile needs to publish the following as versioned, machine-readable definitions with examples and validation rules:

Assistance states, such as requested, generated, delivered, or displayed, each with its source evidence and unit. These are distinct observations; a profile cannot assume that a generated response was delivered or displayed.
The scope of a context assertion: actor, activity, session, stage, period, applicable assistance policy, producing instrument, planned capture, achieved capture, and gaps. Unknown, unavailable, and not yet reviewed information need distinct representations. Context changes and completion claims need effective-scope and precedence rules.
Import provenance: source identifier and release, source row or event identity, original time or relative offset, importer identity and version, import time, and the relation between source speakers and event actors.
Mapping definitions: the source concept and unit, target concept and unit, transformation rule, preserved distinctions, omitted or lost information, assumptions, reviewer and review status. Mapping identity and a digest show which mapping was used, not that it is substantively correct.
Annotation provenance: target source spans or entry references, coding scheme and version, annotating person or instrument, review status, and the distinction between an observed action and a later classification. Overlapping annotations need explicit counting rules.
For a proposed combined measurement, the operational definition, observation unit, denominator, missingness and coverage requirements, coding procedure, inclusion and exclusion rules, and review decision. Shared event names do not establish that measurements can be pooled.

The separate experimental companion profile qlm:assistance-context:0.1.0, version 0.1.0, is distributed with the revision -02 preparation materials. Its machine-readable definition is assistance-context-v0.1.0.json, with event schemas research-import-v2.json and assistance-lifecycle-v1.json. It defines importer observations of source-declared assistance states, per-event context with unknown defaults, and explicit mapping limits. It does not implement a capture-completion event. It is not an IETF-registered schema, is not a normative dependency of this document, and has not received independent semantic validation. Its identifier and version must accompany data that claim to use it. A deployment should publish an immutable specification and schema location before asking unrelated implementations to interoperate. A local file path or unpublished identifier does not establish public availability.The informative inventory below contains 16 candidate AI-related conditions for reviewing a study and a target setting. The labels come from the project's proposed condition crosswalk version 0.1.0; they are not core event types. It is optional analytical guidance, not a validated exhaustive taxonomy, a required set of event fields, or evidence that any condition occurred. A condition needs its own supporting evidence and explicit uncertainty. Research applicability assessments and recommendations to repeat a study remain outside core verification.

C01:: Answer before retrieval
C02:: Explanation or reflection supplied
C03:: Feedback or scaffolding changed
C04:: Practice sequence or dose changed
C05:: Extra exposure between sessions
C06:: AI permitted on assessment
C07:: Prohibited assessment assistance
C08:: Comparison condition changed
C09:: Teacher or peer delivery changed
C10:: Baseline or preparation changed
C11:: Scoring or grading changed
C12:: Motivation or metacognitive signals
C13:: Task novelty or difficulty changed
C14:: Model or policy version changed
C15:: Access and use differ
C16:: Relevant exposure unobserved

This inventory reproduces candidate labels only. The earlier crosswalk targets an older draft, so its field selectors are not incorporated here as current requirements. Applying a condition requires a documented task, observation boundary, and supporting evidence; the label alone cannot establish occurrence, a learning effect, or a need to repeat a study.

Generic Event Schemas This section defines event schemas for three namespaces that are not tied to one subject area: consent, assist, and dialog.

The consent Namespace The schema URI is urn:ietf:params:learnlog:events:consent. The namespace has two event types, consent:granted and consent:withdrawn. Both carry the same data.

Events of the consent namespace ConsentChange = { scopes: [+ ConsentScope], ? ref: text, * $$consent-change-extension } ConsentScope = "instruction" / "research" / "export" / text $Event /= event-type<"consent:granted", ConsentChange> $Event /= event-type<"consent:withdrawn", ConsentChange>

scopes:: The uses that the consent covers.
ref:: A reference to the consent that the producer holds, such as the identifier of a signed form.

This document defines three scopes. Other values MAY be used.

instruction:: Use of the record to support the instruction of the subject.
research:: Use of the record in research.
export:: Disclosure of the record outside the organization that operates the producer.

The actor of a consent event is the party that gave or withdrew consent, for example a guardian. A consent event records that consent was given or withdrawn, as the producer observed it. This document does not define how consent is obtained or how a producer acts on it. A scope is in effect from a consent:granted event that names it until a later consent:withdrawn event that names it. A reader cannot tell which scopes are in effect when a consent event may be among the entries that were redacted or removed. For that reason, a holder SHOULD NOT redact a consent event.

The assist Namespace The schema URI is urn:ietf:params:learnlog:events:assist. The namespace records the help that the producer observed. A reader can treat an action by the learner that follows a scaffold in the same activity as possibly assisted.

assist:help_requested:: The actor asked for help. The to member of the event names the party that was asked.
assist:scaffold_provided:: The actor gave the learner a scaffold, which is support meant to help the learner make progress. The actor can be an instructor, an assistant, a peer, or the system. The event MUST hold the actor member, because an absent actor would mean the subject.

The core assist:scaffold_provided event asserts that the producer observed support being given to the learner; it does not establish that the learner read, heard, used, understood, or learned from it. Content generated internally but not given to the learner is not, on that fact alone, a provided scaffold. Profiles can define separate observations for generation, transmission, delivery, and display, and state which evidence supports each. Those stages cannot be inferred from one another or counted as separate help episodes without a measurement rule. A provider's source label such as "hint" remains a source assertion unless its meaning and mapping have been reviewed.The change to the interpretation of an absent request is a semantic revision, even though the CDDL and hash computations are unchanged. Consumers of historical records need to consult the source's applicable schema or profile revision and retain any explicit original assertion that a scaffold was unsolicited. They must not treat a revision -01 producer's missing link as an independently established observation of request origin, nor silently rewrite old records to add a new commitment.

Events of the assist namespace AssistHelpRequested = { ? type: ScaffoldType, * $$assist-help-requested-extension } AssistScaffoldProvided = { type: ScaffoldType, ? request: Seq, ? level: uint .ge 1, ? reveals_answer: bool, ? modality: "text" / "speech" / text, ? content: text, ? content_ref: text, ? content_hash: HashValue, * $$assist-scaffold-provided-extension } ScaffoldType = "socratic" / "probing" / "metacognitive" / "scaffolding" / "explain" / "hint" / "demonstrate" / text $Event /= event-type<"assist:help_requested", AssistHelpRequested> $Event /= event-type<"assist:scaffold_provided", AssistScaffoldProvided> In AssistHelpRequested, type is the kind of help that was asked for, when the interface distinguishes kinds. The members of AssistScaffoldProvided are:

type:: The kind of scaffold ().
request:: The seq of the entry that this scaffold answers, such as an assist:help_requested entry or a dialog:message entry. An absent value means that this event contains no request link. It does not by itself distinguish unsolicited assistance from a request that was not observed, imported, or linked. A profile can record those cases explicitly. This clarification supersedes the inference from an absent link in revision -01.
level:: The delivery-order position of the scaffold among those given for the current activity, starting at 1. This is not automatically the source product's authored hint depth, pedagogical difficulty, or amount of support. A source-native hint index needs a separate profile-defined field unless a documented mapping establishes that the meanings coincide. If the delivery position is unknown, omit level.
reveals_answer:: True when the scaffold discloses the answer that the activity asks for.
modality:: How the scaffold was expressed. The default is text.
content:: The words of the scaffold.
content_ref:: An identifier for authored scaffold content.
content_hash:: The hash of the scaffold as shown to the learner (), for use when content is left out. An event MUST NOT hold both content and content_hash.

Values of ScaffoldType

Value	Meaning
socratic	An open question that leads the learner toward an idea
probing	A question about an assumption the learner made
metacognitive	A prompt about the learner's own approach
scaffolding	The problem broken into parts
explain	A direct explanation
hint	A hint
demonstrate	A worked example

Other values MAY be used. A producer SHOULD record every scaffold given to the learner, requested or not. The actor member identifies the provider. Help can arrive as a turn in a conversation. A producer that knows a turn to be help records it as assist:scaffold_provided, with the words in content or their hash in content_hash, and writes no dialog:message for that turn. When a producer cannot tell whether a turn is help, it records the turn as dialog:message (). The replies of a general chat assistant are an example.

Hypothetical AI Assistance Example Consider a task that asks a learner to solve 2x + 3 = 11 and explain the approach. An AI assistant might say, "Before calculating, describe your plan and how you will check whether it worked." An assist:scaffold_provided event could describe this as type equal to metacognitive, with reveals_answer equal to false and the words in content. The actor identifies a software assistant, and the activity, session, and instrument identify the task and producing model. In a different hypothetical history, the assistant says, "Subtract 3 from both sides to get 2x = 8, then divide both sides by 2, so x = 4." The event could instead use type equal to explain and reveals_answer equal to true. These examples illustrate existing members; they are not measurements of learning and introduce no new event type. If a subject-area schema records a learner response after either scaffold, the sequence can distinguish the two recorded assistance histories. It cannot establish the learner's internal reasoning, when internal retrieval took place, whether another source was used, or which assistance caused a later outcome. A declaration of type or reveals_answer remains a producer assertion. A reviewer needs the relevant content and task to inspect it. An applicability assessment comparing this activity with a classroom intervention needs additional evidence and separately stated assumptions.

The dialog Namespace The schema URI is urn:ietf:params:learnlog:events:dialog. The namespace has one event type, dialog:message, which is one turn in an exchange between the subject and another party. The actor is the party that produced the turn, and to names the party addressed.

Events of the dialog namespace DialogMessage = { ? modality: "text" / "speech" / text, ? content: text, ? content_hash: HashValue, ? reply_to: Seq, * $$dialog-message-extension } $Event /= event-type<"dialog:message", DialogMessage>

modality:: How the turn was expressed. The default is text.
content:: The words of the turn.
content_hash:: The hash of the words (), for use when content is left out. An event MUST NOT hold both content and content_hash.
reply_to:: The seq of the entry that this turn answers.

A producer SHOULD include activity when the exchange takes place during a task. A reader can then treat a turn by another party as possible help. The words of a turn can hold personal data, and applies. When software transcribes speech, the event SHOULD carry an instrument member that identifies the transcriber.

Integrity

Canonical Form Hashes are computed over a canonical form, so that two implementations produce the same octets for the same value. The canonical form of a JSON value is its serialization under the JSON Canonicalization Scheme (JCS) , encoded in UTF-8. The following rules apply to a whole log file, including the parts that no hash covers:

A log file MUST conform to I-JSON . In particular, no object holds two members with the same name, and no string holds a noncharacter or a surrogate without its pair.
A number is hashed as the IEEE 754 double nearest to its value, in the form that gives that double. A file MUST NOT hold a number too large for a double. A number written without a fraction or an exponent MUST have an absolute value below 2^53. A larger integer is carried as a string.
A string is hashed as the characters it denotes. An escape sequence and the character it stands for give the same hash. A holder MUST NOT apply Unicode normalization.
A holder MUST preserve every member of a header, an event, and a head, including members it does not recognize.

A serialization other than JSON () is mapped to the JSON data model first. Hashes are always computed over the canonical JSON form.

Hashes In this section, H(x) is the hash named by hash_alg, applied to the octets x and written in lowercase hexadecimal. C(v) is the canonical form of the JSON value v.

Hash computation record hash = H(C(header)) event_hash = H(C(event)) prev_hash = record hash in the entry with seq 1 = entry_hash of the preceding entry, otherwise entry_hash = H(C({ "record_hash": record hash, "seq": seq, "time": time, "event_hash": event_hash, "prev_hash": prev_hash }))

The record hash is the hash of the header object.
event_hash is the hash of the event object with all its members.
prev_hash of the entry with seq 1 is the record hash. In every other entry, it is the entry_hash of the entry before it.
entry_hash is the hash of an object with exactly five members. The member record_hash holds the record hash. The other four are the seq, time, event_hash, and prev_hash of the entry.
A member named content_hash or config_hash holds the hash of a string of octets. For text, the octets are its UTF-8 encoding. For other content, the producer chooses the octets.

Every entry hash covers the record hash. An entry that is moved to a record with another header therefore fails step 4e of , even after the entries before it are removed (). A header and an event each require members that the object hashed for an entry lacks. The canonical form of that object therefore differs from the canonical form of any header or event.

Redaction A holder redacts an entry by removing its event member and adding the member redacted with the value true. No other member changes. The entry hash is computed from event_hash, without the event itself. Every hash in the record therefore still verifies, and so does every signed head. The salt is removed with the event. A party that does not have the salt cannot confirm a guess at the event from event_hash (). Redaction leaves seq, time, and the hashes of the entry in place. A holder that needs to remove those as well truncates the record () or deletes it. A verifier reports which entries are redacted. Redaction does not cause a check to fail. Only a party that kept the event can restore it. A restored event is checked against event_hash like any other.

Signed Heads A head names the latest entry of a record at some moment. A producer signs a head so that a verifier can authenticate the record up to that entry.

SignedHead definition SignedHead = { head: Head, signature: text } Head = { record_hash: HashValue, seq: Seq, entry_hash: HashValue, time: Timestamp, * text => any }

record_hash:: The record hash ().
seq, entry_hash:: The seq and entry_hash of the entry that the head names.
time:: The time of signing, as observed by the producer.

The signature member is a JSON Web Signature (JWS) in the compact serialization with detached content (). The JWS payload is the canonical form of the head object. The value of signature is therefore the encoded protected header, two periods, and the encoded signature.

The protected header MUST contain alg and kid and MUST NOT contain crit.
The value of alg MUST name a digital signature algorithm that uses a public key. The value none and MAC algorithms such as HS256 MUST NOT be used. Implementations MUST support ES256 .
The value of kid MUST be the JWK Thumbprint of the public key, computed with SHA-256 and encoded in base64url without padding.

To check a signature, a verifier computes the canonical form of head, encodes it in base64url, places it between the two periods, and verifies the result as a JWS. A verifier uses each key it trusts with exactly one algorithm (). A producer SHOULD sign a head at the end of each session and whenever a record leaves its control. This document does not define how a verifier obtains the public key or decides to trust it. A key that travels in the file itself shows nothing about who signed.

Verification A verifier is configured with the public keys it trusts and, for each key, the one signature algorithm it accepts. A verifier MUST report the result that the steps below define. Any procedure that gives the same result is acceptable.

Read the file.
1. Read a file that begins with the octet 0x1E as a JSON text sequence (). Read any other file as one JSON text ().
2. Check that each JSON text conforms to I-JSON and to the rules for numbers in .
3. Check that file_schema names a file schema that the verifier knows and that fits the serialization. Check that a contained file holds a records array with at least one element, and that the first element of a sequential file holds a record object.
A verifier MUST reject a file when its JSON text fails this step, or when the first element of a sequential file does. None of its records is verified. A later element of a sequential file that fails step 1b is discarded (). Steps 2 to 5 apply to each record of a file that passes.
Check the header.
1. Check that header is an object, that record_id, subject, and hash_alg are strings, and that created is a Timestamp.
2. If step 2a passed and the verifier does not support hash_alg, the outcome for the record is "unsupported" and no further step applies. A verifier MUST NOT support an algorithm whose output is shorter than 256 bits.
3. Compute the record hash.
Set the expected seq to 1 and the expected link to the record hash. If truncated is present, check that truncated.seq is a Seq and that truncated.entry_hash is a HashValue. The expected seq is then truncated.seq plus 1, and the expected link is truncated.entry_hash.
Check that entries is an array. For each entry, in order:
1. Check that seq is a Seq, that time is a Timestamp, and that event_hash, prev_hash, and entry_hash are HashValues. Check that the entry holds exactly one of event and redacted.
2. Check that seq equals the expected seq.
3. Check that prev_hash equals the expected link.
4. If event is present, check that it is an object, that its name has the form given in , that its salt matches the Salt pattern of , and that its data is an object. Then check that the hash of the event equals event_hash. If redacted is present, check that its value is true.
5. Compute the entry hash and check that it equals entry_hash.
6. Set the expected link to entry_hash and add 1 to the expected seq.
If signed_heads is present, check that it is an array. For each signed head:
1. Check that head is an object in which record_hash and entry_hash are HashValues, seq is a Seq, and time is a Timestamp. Check that signature consists of two base64url strings, neither of them empty, joined by two periods. Check that the first string decodes to a JSON object that conforms to I-JSON. Check that this object holds the strings alg and kid, that alg is not none, and that crit is absent.
2. Check that head.record_hash equals the record hash.
3. Check that head.seq is no greater than the seq of the last entry. A greater value shows that entries are missing from the end of the record. For a record without entries, the comparison uses truncated.seq, or 0 when the record is not truncated.
4. If an entry has the seq that the head names, check that head.entry_hash equals its entry_hash. If head.seq equals truncated.seq, check that head.entry_hash equals truncated.entry_hash. A head with a lower seq names an entry that was removed, and this check does not apply to it.
5. If the verifier trusts a key whose JWK Thumbprint equals kid, check that alg is the algorithm it accepts for that key, and verify the signature with that key as describes. If the verifier trusts no such key, the signature is not checked.

and define the terms Timestamp, HashValue, and Seq. A member that this document does not define is ignored in every step, apart from its part in a hash or a signature. Once a check in steps 2 to 5 fails, the outcome is settled, and a verifier MAY stop. The result for a record has these parts:

Outcome:: "consistent" when every check in steps 2 to 5 passed, "inconsistent" when a check failed, or "unsupported" as step 2 describes.
Authenticated through:: For a consistent record, the highest seq among the heads that had an entry hash to compare in step 5d and a signature that verified in step 5e, together with the kid of a head that names it. This part is absent when no head qualifies. Entries up to that seq were in the record when the holder of that key signed. Later entries are consistent and unauthenticated.
Redacted:: The seq of each redacted entry.
Truncated:: The value of truncated.seq, when the record is truncated. The entries up to that seq were not checked.

A verifier reports the following conditions, and they leave the outcome unchanged:

a time that is earlier than the one before it, with the two compared as instants;
a signed head whose signature was not checked;
an element of a sequential file that was discarded ().

Verification does not use title, description, serialization_format, or event_schemas. The data of an event is not checked against an event schema, and an event of an unknown type is handled like any other. A tool MAY validate events against the schemas it knows and report the result separately. A consistent record agrees with itself. A verified head ties the entries up to its seq to a key. states what these results establish and what they leave open.

Serialization The structures in this document are defined in CDDL. takes the same approach and maps its structures to JSON and to JSON text sequences. This document defines the same two serializations. Hashes always use the canonical JSON form (). Where this document defines a member as an integer, a producer writes the number without a fraction or an exponent. A reader compares numbers by value.

JSON A LearnlogFile is serialized as a JSON text in UTF-8. The media type is application/learnlog+json, which is also the value of serialization_format. The file extension is .learnlog.

JSON Text Sequences A LearnlogFileSeq is serialized as a JSON text sequence . Each element is preceded by a record separator (0x1E) and followed by a line feed (0x0A). The media type is application/learnlog+json-seq, which is also the value of serialization_format. The file extension is .slearnlog. A producer can add an entry or a signed head to a sequential file without rewriting what came before. Redaction and truncation rewrite the file. In , <RS> stands for the record separator and most values are left out.

Outline of a sequential file <RS>{"file_schema":"urn:ietf:params:learnlog:file:sequential", "serialization_format":"application/learnlog+json-seq", "record":{"header":{...},"event_schemas":[...]}} <RS>{"seq":1,"time":"2026-10-07T14:00:05Z","event":{...}, "event_hash":"...","prev_hash":"...","entry_hash":"..."} <RS>{"seq":2,"time":"2026-10-07T14:01:10Z","event":{...}, "event_hash":"...","prev_hash":"...","entry_hash":"..."} <RS>{"head":{...},"signature":"..."} A crash can leave the last element of a file cut off. A reader MUST discard an element that is cut off () or that fails step 1b of . The same applies to a parsed element that has neither the seq nor the head discriminator. An object containing seq is recognized as an Entry; otherwise an object containing head is recognized as a SignedHead (). A recognized object that passes step 1b but fails the structural checks in step 4 or 5 MUST make the record inconsistent; it MUST NOT be discarded as an unrecognized element. When the first element is unusable, the file is rejected. When an entry is discarded, the entries after it fail verification.

Other Serializations Other serializations MAY be defined, for example one in CBOR. A serialization MUST map every structure to the JSON data model without loss, because hashes are computed over the canonical JSON form ().

Relationship to Existing Work The file structure and the event schema model come from qlog . A learnlog record corresponds to a qlog trace (). This document adds hashes, redaction, and signed heads. The Experience API (xAPI) defines a JSON data model and a web service for communication between activities and a Learning Record Store. The assistance capture profile uses that ecosystem through the experimental binding in . The optional Learnlog file representation defines no web service. This document does not define a lossless generic conversion of every Learnlog file into xAPI.xAPI Profiles already provides controlled vocabularies, statement templates, and patterns to address inconsistent representations and semantic interoperability. ISO/IEC TS 20748-3 addresses syntactic and semantic mappings between learning-analytics data representations, using xAPI and Caliper as references. Learnlog does not originate this problem or supply a replacement for these approaches.LearnLab's DataShop is established infrastructure for sharing and analyzing student interactions with educational software. Reusable interaction data and secondary analysis predate this proposal. Learnlog adds a candidate assistance and capture agreement and retains a file representation with the integrity and redaction behavior specified here. Whether either improves interoperability, measurement, or implementation effort remains an empirical question.Caliper Analytics defines events and entities, and an envelope that carries them to an endpoint. This document defines no transport. Existing ecosystems are the primary implementation paths for the assistance capture profile. describes the implemented importer-observation mode and its limits. Neither a new format nor a shared profile eliminates the need to justify mappings and proposed combined measurements. Local software checks are not an independent interoperability result.Redaction relies on salted hashes, an approach that Selective Disclosure for JSON Web Tokens also uses (). A signed head is similar to the Signed Tree Head of Certificate Transparency (), applied to a chain in place of a tree.

Security Considerations

What Verification Shows A record that verifies as consistent has entries that agree with one another and with the header. Consistency alone does not show who wrote the record or that nothing was replaced. Anyone who holds a record without a signed head can change an event and recompute every later hash. A signed head limits this. Take a party without the signing key that changes the seq, time, or event of an entry at or before the head. The head stays valid only when the change is a redaction, the restoring of a redacted event, or a truncation (). After any other such change, a verifier that trusts the key reports the record as inconsistent, or as unauthenticated when the head was removed as well. Neither property shows that events took place as recorded. A producer can write an event that is false. Verification establishes at most that the signed entries were not changed by a party without the key. No hash covers title, description, or event_schemas. The same holds for a member that this document does not define, unless it sits in a header, an event, or a head. A reader cannot rely on those values.

Removal of Recent Entries A holder can remove the latest entries of a record together with any signed head that covers them. What remains verifies. A verifier detects the removal only if it knows a later head from another source. This document defines no way to exchange heads.

Redaction and Truncation by a Holder Any holder can redact an event or truncate a record, and the result still verifies. A verifier reports which entries are redacted and whether the record is truncated. What the missing events said, and who removed them, stays unknown to the verifier. A reader that draws a conclusion from the absence of an event SHOULD treat each redacted or removed entry as a possible instance of that event. A redacted entry inside an activity may have been a scaffold. A redacted or removed entry may have been a withdrawal of consent.

Rewriting by the Producer The producer holds the signing key, so it can rewrite a record and sign a new head. Detection requires that another party received a head before the rewrite. A time stamping authority can provide evidence that a head existed before a given time. This document does not define how to use one. The time of a head is a statement by the signer and proves nothing about when the head was signed.

Trusted Keys A signature that verifies shows that the holder of a trusted key signed a head. Any trusted key authenticates any record. A verifier that trusts the keys of several producers needs to know which producer each key belongs to. The result of verification names the key for that purpose.

Where the Producer Runs A signature shows that the holder of a key signed a head. When the producer runs on a device that the learner controls, the learner may control the key. A verifier needs to know where signing took place before it treats a record as evidence about that learner.

Guessing Redacted Events An event can have few possible values. Without a salt, a party could hash each candidate and compare the result with event_hash. The salt prevents this only if it is unpredictable and is deleted with the event. A producer MUST NOT reuse a salt and MUST NOT derive one from the content of the event. The position and time of a redacted entry stay visible, as do the entries around it. Together they can suggest what was removed. Members named content_hash and config_hash carry no salt. A party can test a guess at a short or predictable text against such a hash. Redaction of the event removes these members with it.

Meaning of Event Names A hash covers the name of an event. No hash covers event_schemas, the list that ties a namespace to a schema URI. For a registered namespace (), the name alone identifies the schema. For any other namespace, a holder can replace the URI in the list, and with it the apparent meaning of the events. A reader that depends on such events needs to know the schemas of the producer from another source. For a private vocabulary or companion profile, a producer SHOULD place the schema or profile identifier, version, digest algorithm, and digest of the exact specification or schema bytes in a header extension before creating entries. The header hash already covers such an extension; no change to is needed. The profile needs to define the digest scope and retrieval rules. A reader should check the protected binding rather than rely only on the unprotected event_schemas list. A digest commits to bytes, not to the correctness, availability, or equivalence of their meaning. Existing records without such bindings remain unchanged and require external knowledge; this revision does not retrofit commitments into old records.

Hash Algorithms The integrity of a record rests on the collision resistance of the hash algorithm. A checksum or any other function that is not a cryptographic hash MUST NOT be used. All hashes in a record use one algorithm, so a record cannot move to another. A producer that needs a new algorithm starts a new record.

Canonical Form Two parsers that read the same text differently can disagree about a hash, or agree about a hash while they hold different values. Sections 4, 6, and 8.2 of describe three such cases: member names that are not unique, numbers beyond the range or precision of a double, and strings with unpaired surrogates. The rules in address these cases, and step 1 of applies them before any hash is computed.

Untrusted Input A log file can come from a source that is not trusted. Implementations need limits on file size, nesting depth, and string length.

Privacy Considerations A record describes the behavior of a person in detail, and that person can be a child. The considerations of apply. This section covers points that are specific to this format.

Identifiers The subject member, and the id member of a party that is a person, MUST NOT hold a name, an email address, or an identifier taken from another system, such as a student number. A RECOMMENDED construction is HMAC with SHA-256 over the internal identifier, under a secret key that the producer keeps, with at least 128 bits of the output retained. A hash without a key is not sufficient, because identifiers can be guessed and hashed. The subject identifier is part of the header and stays fixed for the life of a record. Every party that receives the record sees the same identifier and can link the record to other copies.

People Other Than the Subject A record can describe instructors, peers, and guardians, and a dialog event can hold their words. The data is then about them as well. Their identifiers follow .

Data Minimization

A producer SHOULD record an event only if the event has a use.
A producer SHOULD use no more precision in time than its purpose needs. Precision cannot be reduced later, because time is hashed.
Text written by a learner SHOULD be left out unless it is needed.

Limits of Redaction Redaction removes the content of an event. The entry retains a commitment and a producer-reported time. It does not establish that an action occurred or that the time is accurate. Copies of the content in other events, or outside the record, are not affected. The event_hash of a redacted entry remains as well. A party that kept a copy of the event can still show that the event belonged to the record. Truncation or deletion of the record removes that hash. Redaction may not be enough after consent is withdrawn. Truncation or deletion of the record removes more. Unless it is redacted or removed, the consent:withdrawn event remains in the record as the trace of the withdrawal.

Correlation and Identification The actions and times in a record can be combined with other data about a person. Sections 5.2.1 and 5.2.2 of describe how such correlation can lead to identification. A record SHOULD be treated as personal data whatever identifiers it carries.

Signing Keys The kid of a signed head is the same in every record signed with one key. A key used only for one learner can link that learner's records despite different subject identifiers. A device-specific key groups that device's records and may cover several learners. A deployment-wide key groups the deployment's records but does not by itself distinguish one learner from another. Other metadata can still support linkage.

Storage and Transfer Records SHOULD be encrypted in transit and at rest. Access to them SHOULD be controlled and logged. A holder SHOULD set a retention period.

Children A learner can be a child. This document does not address compliance with any law.

IANA Considerations

URN Sub-namespace IANA is requested to register the following in the "IETF URN Sub-namespace for Registered Protocol Parameter Identifiers" registry :

Registry name:: learnlog
Specification:: This document
Repository:: https://www.iana.org/assignments/learnlog
Index value:: The part of a URN that follows urn:ietf:params:learnlog:, which has the form file:<identifier> or events:<namespace>. No transformation is needed.

File Schema URIs IANA is requested to create the "learnlog File Schema URIs" registry at https://www.iana.org/assignments/learnlog. The registration policy is Expert Review . The expert checks that the URI has the form given in and that a public specification defines the file schema. An entry holds a file schema URI, a description, and a reference. The initial entries are:

File Schema URI:: urn:ietf:params:learnlog:file:contained
Description:: A file that holds one or more records
Reference:

File Schema URI:: urn:ietf:params:learnlog:file:sequential
Description:: A file that holds one record and grows by appending
Reference:

Event Schema URIs IANA is requested to create the "learnlog Event Schema URIs" registry at the same location. The registration policy is Expert Review . The expert checks the following:

The URI has the form given in .
A public specification defines the event types, with CDDL for the data of each.
A schema for a new namespace uses a namespace identifier that is not yet registered.
A schema that extends a registered namespace uses the URI of that namespace with a fragment identifier, and leaves the registered event types unchanged.

An entry holds an event schema URI, a namespace, the event types, a description, and a reference. The initial entries are:

Event Schema URI:: urn:ietf:params:learnlog:events:consent
Namespace:: consent
Event Types:: granted, withdrawn
Description:: Consent given or withdrawn
Reference:

Event Schema URI:: urn:ietf:params:learnlog:events:assist
Namespace:: assist
Event Types:: help_requested, scaffold_provided
Description:: Help requested and scaffolds provided
Reference:

Event Schema URI:: urn:ietf:params:learnlog:events:dialog
Namespace:: dialog
Event Types:: message
Description:: Turns in an exchange with another party
Reference:

Media Types IANA is requested to register the following media types .

application/learnlog+json

Type name:

application

Subtype name:

learnlog+json

Required parameters:

N/A

Optional parameters:

N/A

Encoding considerations:

binary; see

Security considerations:

See and

Interoperability considerations:

See

Published specification:

This document

Applications that use this media type:

Software that writes, verifies, or analyzes learnlog records

Fragment identifier considerations:

As for application/json

Additional information:

Deprecated alias names for this type:: N/A
Magic number(s):: N/A
File extension(s):: .learnlog
Macintosh file type code(s):: N/A

Person & email address to contact for further information:

See the Author's Address section

Intended usage:

COMMON

Restrictions on usage:

N/A

Author:

See the Author's Address section

Change controller:

IETF

Provisional registration? (standards tree only):

application/learnlog+json-seq

Type name:

application

Subtype name:

learnlog+json-seq

Required parameters:

N/A

Optional parameters:

N/A

Encoding considerations:

binary; see

Security considerations:

See and

Interoperability considerations:

See

Published specification:

This document

Applications that use this media type:

Software that writes, verifies, or analyzes learnlog records

Fragment identifier considerations:

As for application/json-seq

Additional information:

Deprecated alias names for this type:: N/A
Magic number(s):: N/A
File extension(s):: .slearnlog
Macintosh file type code(s):: N/A

Person & email address to contact for further information:

See the Author's Address section

Intended usage:

COMMON

Restrictions on usage:

N/A

Author:

See the Author's Address section

Change controller:

IETF

Provisional registration? (standards tree only):

References Normative References Key words for use in RFCs to Indicate Requirement Levels Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words Date and Time on the Internet: Timestamps Uniform Resource Identifier (URI): Generic Syntax The Base16, Base32, and Base64 Data Encodings Naming Things with Hashes JavaScript Object Notation (JSON) Text Sequences The I-JSON Message Format JSON Web Signature (JWS) JSON Web Algorithms (JWA) The JavaScript Object Notation (JSON) Data Interchange Format Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures JSON Canonicalization Scheme (JCS) HMAC: Keyed-Hashing for Message Authentication JSON Web Key (JWK) Thumbprint Guidelines for Writing an IANA Considerations Section in RFCs Universally Unique IDentifiers (UUIDs) Secure Hash Standard (SHS) National Institute of Standards and Technology Informative References Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP) An IETF URN Sub-namespace for Registered Protocol Parameters Media Type Specifications and Registration Procedures Additional Media Type Structured Syntax Suffixes Privacy Considerations for Internet Protocols Improving Awareness of Running Code: The Implementation Status Section A Media Type Structured Syntax Suffix for JSON Text Sequences JSON Web Token Best Current Practices Handling Long Lines in Content of Internet-Drafts and RFCs Certificate Transparency Version 2.0 Selective Disclosure for JSON Web Tokens qlog: Structured Logging for Network Protocols Work in Progress IEEE Standard for Learning Technology--JavaScript Object Notation (JSON) Data Model Format and Representational State Transfer (RESTful) Web Service for Learner Experience Data Tracking and Access IEEE Experience API Specification Version 1.0.3 Part Two Experience API DataAdvanced Distributed Learning Initiative Caliper Analytics Specification, Version 1.2 1EdTech Consortium xAPI ProfilesAdvanced Distributed Learning InitiativeInformation technology for learning, education and training -- Learning analytics interoperability -- Part 3: Guidelines for data interoperabilityISO/IECLearnLab's DataShop: A Data Repository and Analytics Tool Set for Cognitive ScienceYou Can't Spell xAPI Without AIRustici SoftwarexAPI Statements 2025-1GIFTAI-Mediated Learning Interactions ProfileinXsol LLC / TLA ToolboxVersion 0.1.0; the source metadata gives a generatedAtTime value of 2026-03-19T00:00:00Z, not a publication date. Retrieved 20 October 2026.Guide to the Tutor Message format (v4)DataShop

Example This appendix shows one record in full. Every hash in it can be recomputed from the text of this document.

An Example Event Schema The example uses a private event schema with the namespace sim and the URI https://example.org/102026/sim. It defines two event types for a simulation.

Event schema of the example SimPredictionCommitted = { prediction: text, ? confidence: "guess" / "fairly_sure" / "certain", * $$sim-prediction-committed-extension } SimExplanationFiled = { explanation: text, * $$sim-explanation-filed-extension } $Event /= event-type<"sim:prediction_committed", SimPredictionCommitted> $Event /= event-type<"sim:explanation_filed", SimExplanationFiled>

A Complete File The file in holds one record with eight entries and one signed head. Entry 4 is a hint from a tutoring system. Entries 5 and 6 are an exchange with an AI chat assistant. Entry 7 is a spoken hint from a teacher, transcribed by software. The content_hash and config_hash values are hashes of the texts in . Each text is one line, with single spaces between words and no line ending. Texts behind the content and configuration hashes

Entry	Member	Text
4	content_hash	Look for a number that divides both 12 and 16.
4	config_hash	example tutor configuration 7
6	content_hash	Simplifying a ratio means dividing both parts by the same number.
6	config_hash	example chat configuration 3

The explanation in entry 8 holds the character U+00BE, written in the figure as an escape. In the canonical form, that character is the two octets C2 BE.

A complete contained file =============== NOTE: '\' line wrapping per RFC 8792 ================ { "file_schema": "urn:ietf:params:learnlog:file:contained", "serialization_format": "application/learnlog+json", "title": "Example record", "records": [ { "header": { "record_id": "66a921d7-55be-4589-afcc-84ea4d2c26ef", "subject": "L-fdda6e0e3413590a303a3737d4176389", "hash_alg": "sha-256", "created": "2026-10-07T14:00:00Z", "producer": {"name": "example-sim", "version": "1.4.0"} }, "event_schemas": [ "urn:ietf:params:learnlog:events:consent", "urn:ietf:params:learnlog:events:assist", "urn:ietf:params:learnlog:events:dialog", "https://example.org/102026/sim" ], "entries": [ { "seq": 1, "time": "2026-10-07T14:00:05Z", "event": { "name": "consent:granted", "salt": "SUe3daeuE7ZsSfKRHA9RkQ", "actor": {"role": "guardian", "kind": "human"}, "data": {"scopes": ["instruction", "research"]} }, "event_hash": "0e144a6edfb39ded22fab2dba4f60a69dc9fc72cdfe\ 7006ab78001e5ac11deef", "prev_hash": "dcfc869849b6088bb8cba0761987f4fa90a181335e20\ a95b120bb0e8dfcd5556", "entry_hash": "ff3f6b48ed7a77379e68a08f6a0c2bfa71bdc757671\ ceb88d905e5d307638433" }, { "seq": 2, "time": "2026-10-07T14:01:10Z", "event": { "name": "sim:prediction_committed", "salt": "yqUo0sZAN2gYAhADsPJjKw", "session": "s-01", "activity": { "id": "https://example.org/activities/ratio-mixing", "version": "2.0", "variant": "seed-8675309" }, "data": { "prediction": "3:4", "confidence": "fairly_sure" } }, "event_hash": "1b878146c3e51d20d0411979dc7fbac81da5fd08846\ 9a725b9afcf8395c2a518", "prev_hash": "ff3f6b48ed7a77379e68a08f6a0c2bfa71bdc757671c\ eb88d905e5d307638433", "entry_hash": "ac64c6867336279286d1837e60312b56b106978d648\ db62360f211306d65b6e5" }, { "seq": 3, "time": "2026-10-07T14:01:42Z", "event": { "name": "assist:help_requested", "salt": "eKmBaP2uRROEiC4HVbWZfA", "to": { "role": "instructor", "kind": "software", "id": "example-tutor" }, "session": "s-01", "activity": { "id": "https://example.org/activities/ratio-mixing", "version": "2.0", "variant": "seed-8675309" }, "data": {"type": "hint"} }, "event_hash": "5485100233e98c7bca12183cf9f9da23ee91f8bb029\ d82e46ddab320661cc51b", "prev_hash": "ac64c6867336279286d1837e60312b56b106978d648d\ b62360f211306d65b6e5", "entry_hash": "afa914e1952ca0d6878b901e32279a09f1462f252df\ b3f289ea846c63b048e06" }, { "seq": 4, "time": "2026-10-07T14:01:43.200Z", "event": { "name": "assist:scaffold_provided", "salt": "DgQiQwSuZLoHwnBLIox60g", "actor": { "role": "instructor", "kind": "software", "id": "example-tutor" }, "session": "s-01", "activity": { "id": "https://example.org/activities/ratio-mixing", "version": "2.0", "variant": "seed-8675309" }, "instrument": { "source": "model", "model": "example-tutor-2026-09", "config_hash": "c9f3b7ca43165de9e1df7bc7ec6cff14e7498d\ a4250a6df8e8f1885a9b4aeea8", "parameters": {"temperature": 0.2} }, "data": { "type": "hint", "request": 3, "level": 1, "reveals_answer": false, "content_hash": "86c2216ed616d2d0097475056db432d1f9f76\ e1ac5e712742157a3fe64ded70d" } }, "event_hash": "b4bd1e82ee9019fb8ece8ab96192a64fdc953fc9ab2\ 7b2d046664ac8525cc789", "prev_hash": "afa914e1952ca0d6878b901e32279a09f1462f252dfb\ 3f289ea846c63b048e06", "entry_hash": "3b8fb5a69bc9701329888b081538f1cc243a2fadb14\ 8f6fc2f619de4f7671f61" }, { "seq": 5, "time": "2026-10-07T14:02:30Z", "event": { "name": "dialog:message", "salt": "HySIGmOXiD_e0G3jppGMVg", "to": { "role": "assistant", "kind": "software", "id": "example-chat" }, "session": "s-01", "activity": { "id": "https://example.org/activities/ratio-mixing", "version": "2.0", "variant": "seed-8675309" }, "data": { "modality": "text", "content": "What does simplifying a ratio mean?" } }, "event_hash": "a83a6d085d8ae61dfe3b3783ecaea3c51d52588d7a4\ c2182245236b2b0b7d2dd", "prev_hash": "3b8fb5a69bc9701329888b081538f1cc243a2fadb148\ f6fc2f619de4f7671f61", "entry_hash": "4cf6025ac1e0aa85ed8a9f1e3c678f544a73319d1e0\ 8eecb3fbe6ae695b65a2d" }, { "seq": 6, "time": "2026-10-07T14:02:33.500Z", "event": { "name": "dialog:message", "salt": "wf_VFXE_2WNouptIJguFuQ", "actor": { "role": "assistant", "kind": "software", "id": "example-chat" }, "session": "s-01", "activity": { "id": "https://example.org/activities/ratio-mixing", "version": "2.0", "variant": "seed-8675309" }, "instrument": { "source": "model", "model": "example-chat-2026-08", "config_hash": "fcfd5153bc5c0d1f52417f66ab078c749eb21f\ 4cebb5504cf274821a79a17aa5" }, "data": { "modality": "text", "reply_to": 5, "content_hash": "fb4ede48d160a985aeca77af68fcc7abdc3af\ cdbff6781574146ecd02c2b45ed" } }, "event_hash": "0d8d14d15cb3a606a857e86fc4fbe838a9ec11dfa3e\ bdb73a5eef53bbb96d4c9", "prev_hash": "4cf6025ac1e0aa85ed8a9f1e3c678f544a73319d1e08\ eecb3fbe6ae695b65a2d", "entry_hash": "43f068599a10f02217bc7287ca082d99818aa1fd92f\ a3e12115cf1a7d5bfc23b" }, { "seq": 7, "time": "2026-10-07T14:03:05Z", "event": { "name": "assist:scaffold_provided", "salt": "lMgpY68f-AMZ-mEMbfR3cg", "actor": { "role": "instructor", "kind": "human", "id": "T-c1a8a3a416c9098d21b2baf451464304" }, "session": "s-01", "activity": { "id": "https://example.org/activities/ratio-mixing", "version": "2.0", "variant": "seed-8675309" }, "instrument": { "source": "model", "model": "example-transcriber-1" }, "data": { "type": "hint", "level": 2, "reveals_answer": false, "modality": "speech", "content": "Try it with the smaller numbers first." } }, "event_hash": "3e305baf5a3fad47f1e9c3d412d799fdd18926ff159\ 169a26034af74e6214f91", "prev_hash": "43f068599a10f02217bc7287ca082d99818aa1fd92fa\ 3e12115cf1a7d5bfc23b", "entry_hash": "4a0646f97bb877a347b7ba98eb6d1a7d9e0e3e0978e\ d5706b0e07b7ef6ec4668" }, { "seq": 8, "time": "2026-10-07T14:04:20Z", "event": { "name": "sim:explanation_filed", "salt": "y0_vEXCW8JNMCBA0MnLr2w", "session": "s-01", "activity": { "id": "https://example.org/activities/ratio-mixing", "version": "2.0", "variant": "seed-8675309" }, "data": { "explanation": "12 out of 16 is \u00be. Both divide b\ y 4." } }, "event_hash": "3689aa3e1f8fdea9494f10a9607ffd84db805ad0475\ f57077129a34cd8ebb5d0", "prev_hash": "4a0646f97bb877a347b7ba98eb6d1a7d9e0e3e0978ed\ 5706b0e07b7ef6ec4668", "entry_hash": "d2b47063f53bcce905ef687c5f7f1c3f008078d0a3e\ ece78d2bc54bf8c1ca5b5" } ], "signed_heads": [ { "head": { "record_hash": "dcfc869849b6088bb8cba0761987f4fa90a18133\ 5e20a95b120bb0e8dfcd5556", "seq": 8, "entry_hash": "d2b47063f53bcce905ef687c5f7f1c3f008078d0a\ 3eece78d2bc54bf8c1ca5b5", "time": "2026-10-07T14:04:21Z" }, "signature": "eyJhbGciOiJFUzI1NiIsImtpZCI6IkNPSWFUYTctOFoz\ VElOYmhBOFJjczZmcjAyWlRERzExMzM3MVQzR01aUlUifQ..9SbLqNvt-_gfXkz4sYqC\ znBecvxy1YojXXOujGN2pdy5jJ7IZOOw37pxBsrdjr7K4p52Rqlo4va5MGFbP5vVWg" } ] } ] }

Intermediate Values The canonical form of the header is: =============== NOTE: '\' line wrapping per RFC 8792 ================ {"created":"2026-10-07T14:00:00Z","hash_alg":"sha-256","producer":{"\ name":"example-sim","version":"1.4.0"},"record_id":"66a921d7-55be-45\ 89-afcc-84ea4d2c26ef","subject":"L-fdda6e0e3413590a303a3737d4176389"} Its SHA-256 hash is the record hash, which is also the prev_hash of entry 1: dcfc869849b6088bb8cba0761987f4fa90a181335e20a95b120bb0e8dfcd5556 The canonical form of the event in entry 2 is: =============== NOTE: '\' line wrapping per RFC 8792 ================ {"activity":{"id":"https://example.org/activities/ratio-mixing","var\ iant":"seed-8675309","version":"2.0"},"data":{"confidence":"fairly_s\ ure","prediction":"3:4"},"name":"sim:prediction_committed","salt":"y\ qUo0sZAN2gYAhADsPJjKw","session":"s-01"} Its hash is the event_hash of entry 2: 1b878146c3e51d20d0411979dc7fbac81da5fd088469a725b9afcf8395c2a518 The canonical form of the object that is hashed for entry 2 is: =============== NOTE: '\' line wrapping per RFC 8792 ================ {"event_hash":"1b878146c3e51d20d0411979dc7fbac81da5fd088469a725b9afc\ f8395c2a518","prev_hash":"ff3f6b48ed7a77379e68a08f6a0c2bfa71bdc75767\ 1ceb88d905e5d307638433","record_hash":"dcfc869849b6088bb8cba0761987f\ 4fa90a181335e20a95b120bb0e8dfcd5556","seq":2,"time":"2026-10-07T14:0\ 1:10Z"} Its hash is the entry_hash of entry 2: ac64c6867336279286d1837e60312b56b106978d648db62360f211306d65b6e5

The Signed Head The head was signed with the private key that matches this public key: { "kty": "EC", "crv": "P-256", "x": "hLOF5epJKOENr_YLdw3iuvlSeuuUdVewL1BqcNtOKYw", "y": "PwQdWqmdT3_EOKIQvttI8kFeZLUePMifTFD5CpM-1WY" } The JWK Thumbprint of the key, used as kid, is: COIaTa7-8Z3TINbhA8Rcs6fr02ZTDG113371T3GMZRU The protected header is: {"alg":"ES256","kid":"COIaTa7-8Z3TINbhA8Rcs6fr02ZTDG113371T3GMZRU"} The JWS payload is the canonical form of the head: =============== NOTE: '\' line wrapping per RFC 8792 ================ {"entry_hash":"d2b47063f53bcce905ef687c5f7f1c3f008078d0a3eece78d2bc5\ 4bf8c1ca5b5","record_hash":"dcfc869849b6088bb8cba0761987f4fa90a18133\ 5e20a95b120bb0e8dfcd5556","seq":8,"time":"2026-10-07T14:04:21Z"} The value of signature in the file is: =============== NOTE: '\' line wrapping per RFC 8792 ================ eyJhbGciOiJFUzI1NiIsImtpZCI6IkNPSWFUYTctOFozVElOYmhBOFJjczZmcjAyWlRE\ RzExMzM3MVQzR01aUlUifQ..9SbLqNvt-_gfXkz4sYqCznBecvxy1YojXXOujGN2pdy5\ jJ7IZOOw37pxBsrdjr7K4p52Rqlo4va5MGFbP5vVWg The private key is not given here, so an implementation cannot reproduce this value. The value can be verified with the public key above.

Redaction and Truncation After entry 8 is redacted, it reads as shown below. Every hash in the record and the signed head verify as before. =============== NOTE: '\' line wrapping per RFC 8792 ================ { "seq": 8, "time": "2026-10-07T14:04:20Z", "redacted": true, "event_hash": "3689aa3e1f8fdea9494f10a9607ffd84db805ad0475f5707712\ 9a34cd8ebb5d0", "prev_hash": "4a0646f97bb877a347b7ba98eb6d1a7d9e0e3e0978ed5706b0e0\ 7b7ef6ec4668", "entry_hash": "d2b47063f53bcce905ef687c5f7f1c3f008078d0a3eece78d2b\ c54bf8c1ca5b5" } If entries 1 to 5 are removed from the original record instead, the record gains the member shown below and its first remaining entry is entry 6. The signed head still verifies. =============== NOTE: '\' line wrapping per RFC 8792 ================ { "truncated": { "seq": 5, "entry_hash": "4cf6025ac1e0aa85ed8a9f1e3c678f544a73319d1e08eecb3\ fbe6ae695b65a2d" } }

Canonical Form Check The record above has few values that separate the canonical form of from other compact JSON output with sorted member names. The JSON text in has more of them. It holds numbers in several spellings, a control character, and two member names whose order by UTF-16 code unit differs from their order by code point.

A JSON text for checking the canonical form { "numbers": [1e21, 1.0, 0.000001, 1e-7, -0, 0.2, 4.50, 2E-3, 333333333.33333329], "string": "\u000f\u00be/\"\\\n", "\ud83d\ude00": 1, "\ufb33": 2, "a": null, "A": true } In the canonical form, the member names appear in the order A, a, numbers, string, U+1F600, U+FB33. The numbers appear as 1e+21, 1, 0.000001, 1e-7, 0, 0.2, 4.5, 0.002, and 333333333.3333333. The canonical form has 131 octets, shown here in hexadecimal: 7b 22 41 22 3a 74 72 75 65 2c 22 61 22 3a 6e 75 6c 6c 2c 22 6e 75 6d 62 65 72 73 22 3a 5b 31 65 2b 32 31 2c 31 2c 30 2e 30 30 30 30 30 31 2c 31 65 2d 37 2c 30 2c 30 2e 32 2c 34 2e 35 2c 30 2e 30 30 32 2c 33 33 33 33 33 33 33 33 33 2e 33 33 33 33 33 33 33 5d 2c 22 73 74 72 69 6e 67 22 3a 22 5c 75 30 30 30 66 c2 be 2f 5c 22 5c 5c 5c 6e 22 2c 22 f0 9f 98 80 22 3a 31 2c 22 ef ac b3 22 3a 32 7d The SHA-256 hash of those octets is: afbc268398163c4f856a4d881d1eb85ba85b85e609c8473a11ebaf56cf28a0d1

Implementation Status This section records the status of known implementations at the time of writing, as described in . The following description of qlm-measure version 0.7.0 is retained from revision -00. It is an earlier implementation and does not establish conformance to this revision. qlm-measure version 0.7.0 (Quantum Learning Machines; TypeScript and Python; Apache 2.0 license; https://github.com/QuantumLearningMachines/qlm-measure) writes and verifies records that it labels schema 0.3. This document was derived from that format. Both chain entries by hash and allow an event to be redacted. Both place consent events in the chain. The differences are:

The recorder of qlm-measure serializes hashed values with sorted member names. Its documentation lists for schema 0.3 as planned.
A record has no header. The first entry links to an empty string. No hash covers the studentScopeId member, which names the learner of the record.
Events carry no salt.
A record can hold attestations that refer to an entry by version or by hash. The verifier checks that reference and a payload hash. No signature is verified.
Member names differ. For example, qlm-measure uses version and prevHash where this document uses seq and prev_hash.
The kind of scaffold is a member of an observation event. No event type exists for a request for help or for a scaffold.

Quantum Learning Machines plans to extend qlm-measure so that it writes records in the format of this document. A local Learnlog AI Use Profile v0.1.0 prototype adds proposed context fields, condition-assessment sidecars, two entirely synthetic examples, and a Python reference checker. It checks a subset consisting of contained, unsigned SHA-256 records without redaction or truncation and the example-profile constraints. It does not verify signatures, establish full CDDL conformance, or implement runtime context-update and capture-completion events. The examples contain no participant observations or learning-effect measurements. The prototype is not an independent implementation or an interoperability result. No public publication location is specified in this revision. The revision -02 preparation materials add an experimental assistance and import profile, together with source-specific transformer mappings and a downloadable pipeline. The profile distinguishes source-declared lifecycle observations and binds its definitions through existing header extension points. Released transcript turns and participant summaries remain different observation units; synthetic lifecycle fixtures are labeled as such. These materials do not demonstrate independently reviewed cross-product scaffolding measurement, full core conformance, or an improvement in research decisions. Their execution and source-fidelity checks are implementation evidence, not semantic or educational-effect validation.The 18 October working materials add the assistance capture profile identified in , a JSON Schema, local Python validation, synthetic examples, a draft xAPI profile, and complete experimental xAPI and Caliper importer-observation encodings. Their executable checks concern the stated encoding mode and record the exact scope of validation. They do not establish that a carrier record is a native learner action. These additions leave the previously versioned companion profile and the core Learnlog representation unchanged. Structural, round-trip, and negative-case checks do not establish truthful capture, independent implementation, fewer measurement errors, lower integration effort, certification, or adoption.The intended adoption path is through the transformer. External products can retain their native formats and need not adopt Learnlog, xAPI, or Caliper. An adapter can produce profile records when available source facts and a documented mapping support those assertions; an optional carrier binding packages the result. QLM's internal logging requirement for its own products is separate. The research adapters supplied with the existing demo use their earlier frozen profile; the new carrier encodings do not make those adapters conform to this assistance capture profile. A supported adapter for the new profile needs its own source-fidelity and mapping tests. The transformer cannot recover assistance or capture facts that the source did not record. Additional instrumentation is needed when a proposed measure requires missing observations.

Changes in Revision -02

Position Learnlog as an assistance capture profile with xAPI and Caliper bindings, motivated by QLM Measure. Make the existing file representation optional. Specify assistance, achieved capture, explicit unknowns, and mapping requirements while acknowledging existing AI and tutoring profiles. Add experimental complete importer-observation encodings without changing core sourcecode or existing versioned profiles.
Clarify that provision does not establish reading, use, understanding, or learning, and distinguish provision from internal generation.
Clarify absent request linkage and separate delivery position from source-native hint depth. No CDDL field is changed.
Add guidance for historical import observations, original timestamps, relative offsets, importer actors, and source speakers.
Specify what concrete companion profiles need to define for assistance states, context changes, coverage, mappings, annotation provenance, and measurement compatibility.
Keep candidate AI conditions optional, unvalidated analytical prompts and applicability judgments outside the core format.
Add xAPI Profiles, ISO/IEC TS 20748-3:2020, and DataShop as related work; make no first-standard or absent-infrastructure claim.
Recommend protected schema and profile bindings through existing header extensions. Preserve the core hash algorithm and test vectors; do not rewrite historical records.
Omit an explicit submission stream attribute because the existing Datatracker record has no assigned stream. No stream assignment is requested by this editorial change.
Correct the reference binding to version 0.1.1-draft with separate xAPI account-system identity and legacy Statement-version handling; preserve the capture payload version. Preserve visible verification substep labels in reading copies. Qualify optional event context and producer-time assertions, clarify malformed recognized sequential entries, remove unpublished normative dependencies, and enumerate the informative candidate-condition labels.

Changes in Revision -01

Add prospective motivation for interpretable learning and assessment records when AI supplies assistance.
Clarify that judgments about research applicability are outside the core format.
Add non-normative companion-profile guidance for activity stage, scoped pedagogical permission, planned and asserted observation coverage, capture gaps, context changes, and review status.
Add a hypothetical metacognitive prompt versus supplied-explanation example using the existing assist members.
Clarify the distinction between recorder and producing-model provenance and the limits of configuration hashes and deterministic validation.
Identify the need for explicit xAPI and Caliper mappings and describe the limited local synthetic profile prototype.
Leave all existing CDDL, sourcecode examples, integrity rules, registries, and test vectors unchanged.

Open Issues

The name of the format is open.
is an Informational RFC from the Independent Submission stream. A normative reference to it from a Standards Track document is a downward reference. The alternative is to define the canonical form in this document. is Informational as well.
JSON text sequences follow . JSON objects separated by line feeds are an alternative.
Signed heads use JWS with ES256. Open points are explicit typing of the JWS, a second algorithm, key discovery, and whether COSE would serve better.
A defined way to lodge heads with a third party would address and .
A sequential file holds one record. A server that writes for many learners may want to mix records in one file.
When supplied, session and activity are carried on each applicable event; both members are optional in the base Event definition. lets a trace state such values once, as common fields. An equivalent here would have to fit the rule that each event is hashed by itself.
The assist and dialog namespaces are small. Feedback on a response and questions put to the learner are candidates for generic event types. The values of ScaffoldType may belong in a registry.
The roles instructor and assistant separate parties by teaching responsibility. Deployments may need finer roles.
The consent scopes are a starting point.
A reader ignores members that this document does not define, and outside a header, an event, or a head no hash covers them. A stricter rule may be safer.
The content_hash and config_hash members carry no salt ().
A producer cannot yet state in the chain which entries it redacted. Such a statement would let a reader tell a redaction by the producer from one by a later holder ().
The unprotected event_schemas list remains unchanged. Independent review is needed for private profile binding conventions, immutable publication, digest scope, and behavior when a required definition is unavailable.
A subject identifier cannot differ by recipient ().
A record cannot change its hash algorithm. A way to continue a record in a new one may be needed.
Mappings between learnlog events and xAPI statements or Caliper events, including assistance semantics, provenance, and information loss.
Independent review and implementation of companion-profile requirements for scoped assistance permission and observation coverage, including explicit context changes and completion claims.
A companion format for estimates that refer to entries.
Independent evaluation of assistance-state definitions, source mappings, annotation agreement, measurement compatibility, and two-product interoperability. Successful structural validation or a matching digest is not semantic validation.
Independent research is needed to test whether applicability records improve decisions. This format cannot establish that AI invalidates a prior trial or that a trial needs repeating.
Independent comparison against existing AI and tutoring profiles, including overlap, hosting and governance options; whether a separate representation is justified; and validation of the proposed capture and knowledge-state distinctions.
Test the experimental importer-observation bindings with independent producers and carrier implementations; finalize controlled identifiers, publication and governance; and define native-action bindings only when source evidence supports required actor and time semantics. Publish any information loss and keep the separate evaluation toolkit's frozen encodings distinct.