The instructor path
Once per assignment sequence, on a card-based form. No JSON appears at any point, and nothing installs.
- 1
Build the sequence: each step names who seals it, the kind of work, and its AI policy.
Open the Journey builder - 2
Seal your own steps (a reading, the assignment spec) when Studio offers it, so student work chains to them exactly.
- 3
Post the journey file and its description to the Canvas assignment.
Read the one-page quick-start - 4
Want to see a finished sequence first? Load a complete example into Studio.
Open an example journey
Posting to Canvas
- 1
Attach the sealed journey file and paste its description into the assignment.
- 2
Set the submission type to File Uploads.
If you restrict allowed file types, the list must includemd, or Canvas rejects every submission. This is the most common setup failure. - 3
Collect with Download Submissions: one zip of every student's file.
- 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
Download the journey file attached to the Canvas assignment (it ends in
.knobe.md). - 2
Load it in Studio, pick your step, write, and seal.
Open Create - 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
Use Download Submissions in Canvas and unzip the batch.
- 2
Load the journey as the expectation, then drag the unzipped folder in.
Open Cohort check - 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
Optional: run the same checks from an AI agent with
About the MCP serverknobe-mcp; it runs locally, so the privacy posture is unchanged.
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
Get the sealed source file you are adapting.
- 2
Produce the adaptation, then seal it with its lineage and credit.
Open Adapt - 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
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.
- Instructordesigns and seals the sequence
- Studentsseal their steps against it
- TAchecks the batch in one table
- 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.
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.
| File | What it is |
|---|---|
| Instructor quick-start | One page: build a journey, seal the spec, post to Canvas. |
| TA guide | One page: download, unzip, drag, read the table, export the CSV. |
| Student handout | One page to attach to the assignment: load the journey, seal your step, upload one file. |
| Accessibility guide | One page: seal a plain-language version, translation, transcript, or description with lineage and credit. |
| The loop on one page | A printable visual guide: the cycle, the three paths, the file-type gotcha, and the file anatomy. |
| Example journey: AI disclosed | A sealed three-step sequence for a course that allows AI with disclosure. Open it in Studio. |
| Example journey: AI prohibited | The same sequence for a course that prohibits AI. Open it in Studio. |
| Everything as a zip | All 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.