Instructor toolkit

A sealed record of coursework, from syllabus to submission.

An instructor defines the assignment sequence once, students seal their work against it, and a TA checks the whole batch. Every file records who made it, what it builds on, and the AI policy it was made under.

Every tool on this page runs inside the browser page. Student work is never transmitted anywhere, to us or anyone else. That matters under FERPA: no third party processes the submissions.
Pick your role

The instructor path

Once per assignment sequence, on a card-based form. No JSON appears at any point, and nothing installs.

  1. 1

    Build the sequence: each step names who seals it, the kind of work, and its AI policy.

    Open the Journey builder
  2. 2

    Seal your own steps (a reading, the assignment spec) when Studio offers it, so student work chains to them exactly.

  3. 3

    Post the journey file and its description to the Canvas assignment.

    Read the one-page quick-start
  4. 4

    Want to see a finished sequence first? Load a complete example into Studio.

    Open an example journey

Posting to Canvas

  1. 1

    Attach the sealed journey file and paste its description into the assignment.

  2. 2

    Set the submission type to File Uploads.

    If you restrict allowed file types, the list must include md, or Canvas rejects every submission. This is the most common setup failure.
  3. 3

    Collect with Download Submissions: one zip of every student's file.

  4. 4

    Grade in SpeedGrader as usual; a sealed file is plain text and displays there.

The student path

About two minutes of overhead per assignment: the form fills itself from the journey, and the AI question matches the policy your instructor set.

  1. 1

    Download the journey file attached to the Canvas assignment (it ends in .knobe.md).

  2. 2

    Load it in Studio, pick your step, write, and seal.

    Open Create
  3. 3

    Upload the downloaded sealed file to Canvas like any other file.

The student handout covers this on one page, including how to write a specific AI disclosure.

The TA path

One table for the whole batch; anomalies sort to the top, and the clean majority needs no attention. Grading itself stays in SpeedGrader.

  1. 1

    Use Download Submissions in Canvas and unzip the batch.

  2. 2

    Load the journey as the expectation, then drag the unzipped folder in.

    Open Cohort check
  3. 3

    Read the table, then export the CSV for gradebook cross-reference. For one student's history across the term, use the chain view.

  4. 4

    Optional: run the same checks from an AI agent with knobe-mcp; it runs locally, so the privacy posture is unchanged.

    About the MCP server

The TA guide explains each table column and what an anomaly row means.

The accessibility path

A plain-language version, translation, transcript, or description seals as its own file: bound to the exact source by hash, credited to the adapter and any reviewer, and honest about what it preserves and omits.

  1. 1

    Get the sealed source file you are adapting.

  2. 2

    Produce the adaptation, then seal it with its lineage and credit.

    Open Adapt
  3. 3

    Distribute the sealed file the way you distribute any accommodation document.

One page for disability-services staff and TAs: the accessibility guide. The design behind it is on the accessibility page.

A week in the loop

Monday. Dr. Alvarez seals the journey and posts it to the Canvas assignment.
Wednesday. Sam loads it in Studio, writes, seals, and uploads one file.
Friday. The TA drags the folder into Cohort check; anomalies float to the top.
Later. A regrade works from the sealed record, not memory.

The loop

The cycle: the instructor designs and seals the sequence; students seal their steps against it; the TA checks the batch in one table; disputes return to the instructor and work from the sealed record; the loop repeats each assignment.

  1. Instructordesigns and seals the sequence
  2. Studentsseal their steps against it
  3. TAchecks the batch in one table
  4. Back to the instructordisputes work from the sealed record ⟲

Each assignment runs the same cycle, and every artifact in it verifies against the ones before.

What the file is

One plain-text file, three layers. Open it in any editor and all three are right there.

Readable headertitle, date, license: scannable by anyone
The work itselfthe student's own writing, readable anywhere, no app needed
Sealed recordwho made it, what it builds on, the AI declaration, and the hash that proves nothing changed

AI policy, in either direction

The toolkit takes no position on whether AI belongs in your course. It records the position you take. A step sealed under a prohibition carries the student's sole-authorship declaration. A step sealed under a disclosure policy carries a named AI contributor, marked non-rights-bearing, with the student's own account of what the AI did and what they did. The seal does not detect AI use, and nothing here is a detector. It replaces detection with declaration: a signed, hash-anchored statement the student makes at submission time, against the policy you set.

Time and identity, without a server

The seal proves content, not wall-clock time or legal identity; the threat model states both limits and the application-layer paths that close them. Three patterns give a course most of what it needs with nothing installed.

The time sandwich

A journey-linked submission carries the journey and spec hashes inside its sealed record, so it provably was sealed after the assignment existed. The Canvas submission receipt bounds the other side. A file resealed after the deadline is a different file, byte for byte, from what Canvas holds, and Cohort check shows the mismatch. Not proved: the wall-clock moment of sealing between those two bounds.

The cohort receipt

After a batch check, Cohort check can seal a receipt: one KNOBE attesting that the listed files, with the listed payload hashes, produced the listed verdicts at seal time. Canvas timestamps rot when the course shell is deleted; the receipt is a plain file that survives. Anchor its single hash anywhere with an independent timestamp (an email, a gradebook note) and every listed submission is timestamped at once. Not proved: anything about files it does not list.

The signet, designed and arriving next

Continuity of authorship: Studio will generate a keypair that lives in a file the student keeps, and each submission will carry a signature made with it. One anchoring event (in person, or recorded in an enrollment receipt) binds the key fingerprint to the roster; from then on, every signed submission proves the same key holder authored the chain, across a term or a dissertation. The specification reserves identity_status: "signed" for exactly this. Not proved: legal identity; a shared key fails the same way a shared Canvas login does. The signet is for settings that need high-assurance continuity (comprehensive exams, dissertations, certifications), not a default for every section: students lose key files, and each re-enrollment costs real staff time. Most courses get what they need from the sandwich and the receipt. The design charter is public in the repository, and the hardware-credential direction explored with Joshua Hori is the institutional-grade extension of the same path.

The kit

One page per role, an accessibility guide, and two complete example journeys you can load into Studio unchanged. The examples are sealed KNOBEs and verify like any other.

The kit
FileWhat it is
Instructor quick-startOne page: build a journey, seal the spec, post to Canvas.
TA guideOne page: download, unzip, drag, read the table, export the CSV.
Student handoutOne page to attach to the assignment: load the journey, seal your step, upload one file.
Accessibility guideOne page: seal a plain-language version, translation, transcript, or description with lineage and credit.
The loop on one pageA printable visual guide: the cycle, the three paths, the file-type gotcha, and the file anatomy.
Example journey: AI disclosedA sealed three-step sequence for a course that allows AI with disclosure. Open it in Studio.
Example journey: AI prohibitedThe same sequence for a course that prohibits AI. Open it in Studio.
Everything as a zipAll seven files, for posting to a course shell.

The field shapes these tools write are the ones published in the education profile, and the profile's sealed corpus examples (a reading, an assignment spec, a student submission) are the reference implementations of the same loop.

Limits, stated plainly
  • It does not detect AI writing, plagiarism, or contract cheating. It records declarations and verifies integrity; a false declaration remains a conduct matter, now with a signed record of exactly what was declared.
  • It does not enforce anything inside Canvas. A student can still upload a plain file with no seal; the Cohort check table shows that as an unreadable row, and your syllabus decides what that means.
  • It does not integrate with Canvas beyond files. An LTI 1.3 tool with one-click seal-and-submit would need a server and a Canvas administrator's install. The protocol supports building one; this site does not ship one.
  • If you reseal a journey mid-term, earlier submissions still chain to the spec hash that was actually assigned to them. That is the record working correctly, not drifting.
Hosting a journey at a link

Studio can load a journey from a link (/studio/?journey=<url>) when the journey file is hosted openly, as the kit examples are. Canvas attachments require a login, so a browser page cannot fetch them directly; for Canvas-hosted journeys, downloading and dragging the file in is the path that works, and it is the one the student handout teaches.