Skip to content

Process-based assignment design without AI detection

Guide 9 of 22 For instructors 7-minute read

Every writing instructor has now had the conversation. A paper arrives that reads wrong — too smooth, too general, cited to sources that say something slightly different — and there is nothing to point at. The detector says 87%. The student says they wrote it. There is no way to know, and the meeting ends with a warning nobody can enforce and a student who may have been wronged.

This guide is about designing the assignment so that the conversation does not happen, or happens with something concrete on the table. It is not about catching anyone. It is about asking for the one thing an honest process produces and a dishonest one cannot fake cheaply: the work, with dates, in pieces.

Why detection does not work, in two paragraphs

A detector is a classifier that reports how much a text resembles the text a model would produce. Two things follow. First, the models change, and the classifier is always trained on last year's; the resemblance it measures is a moving target it cannot keep up with. Second, and worse, the resemblance is not a property of authorship. Plain, competent, well-organized prose — the kind non-native speakers are taught to write, the kind formal fields require — resembles model output more than idiosyncratic prose does, and the published studies of these tools show the false-positive rate landing on exactly those students. A detector cannot tell you who wrote a paper. It can tell you whose prose is plain.

You also cannot verify it. A detector gives a number and no reason; there is nothing to check, nothing to show a student, nothing to bring to an appeal. An accusation you cannot substantiate is not one you should make, and a policy that depends on making it is a policy that punishes at random. Most institutions that adopted detectors early have quietly stopped relying on them for that reason. The question is what to do instead.

The alternative: ask for the process

An honest research paper leaves a trail. Reading notes accumulate over days. Claims appear partway through the reading and change. An outline is tried and rearranged. A draft is written and its structure revised. Things are cut. All of this happens whether or not anyone records it — and almost nobody records it, because a paper is handed in as a finished document and the trail is thrown away.

If the assignment asks for the trail, the honest student has it, and the dishonest student has to manufacture three weeks of plausible wrong turns, which is more work than writing the paper. That is the whole design. It is not surveillance; nothing is watched. It is a deliverable: hand in the paper, and hand in how you made it.

The card method (instructor guide 1) produces this trail as a side effect, which is why the two go together. A student who works from dated cards has, when the paper is done: the cards in the order they were made; the claims with their evidence; the cut pile; the orders that were tried. That is a record of process, and it took no extra work to keep.

What a record of process is, and is not

Be precise about this in the assignment, because students will ask and because the precision is what makes the design fair.

It is a description. What was made, when; what was cut, and why; what orders were tried. Dates in three kinds, if the record is kept by software: recorded as it happened, recorded offline and verified later, or brought in from a file — and never blurred together, because a date that looks more certain than it is would be a lie in the record.

It is not a measure. A record has no score. It does not say the process was good, or typical, or fast, or suspicious. It has no baseline to compare against and does not compare students with each other. If a record you are handed does any of those things, do not use it; it has stopped being a record.

It documents process, not authorship. A record shows the paper was assembled from pieces over time. It cannot show who held the pen. Nothing can, and a policy that pretends otherwise will be caught out. What the record does is turn how was this written from a question with no answer into a question with a concrete one, which for the honest student is the only thing that was needed.

Designing the assignment

Ask for the trail as a deliverable, not a surveillance feed. Hand in your paper, and hand in a record of how you made it: your cards, or your notes and outlines, with dates. Say what form is acceptable — a stack of cards, a folder of dated files, a record generated by software that works from cards — and say that the form does not matter.

Say what you will do with it. I read it the way I read a draft: as evidence of a process, not a measure of one. It is not graded. It is not compared between students. This sentence is the one that makes the design fair, and it has to be true. If you grade the record, you have built a test of who keeps tidy notes, and you will grade down the student who reads on paper for two weeks and types it all up on a Sunday.

Do not require a particular tool. Require the deliverable. Paper cards are a complete answer. A student who uses software will hand in what the software produces; a student who does not will hand in a stack or a folder. Requiring a tool is requiring a purchase, and it is also beside the point.

Build in one conversation. The record's best use is not at the end. Ten minutes in a conference at the midpoint, with the cards on the table, is worth more than any policy: you can see what they have, ask which claim has nothing under it, and send them back to the reading with a question. A student whose cards are on the table has nothing to fear from the record, and a student with no cards at the midpoint has a problem you can both see in time to fix. Instructor guide 4 is the semester version of this.

Say what you cannot see. If students use software for this, tell them what it does and does not report to you. The honest answer, for software built on these principles, is: nothing. No dashboard, no activity log, no "eleven of thirty have started." You see a paper and a record when a student hands them in, and not before. Students who know this use the tool as a tool rather than as a thing that watches them, and the record they hand in is theirs to hand in.

Reading a record fairly

When the records come in, three rules.

Read for the shape, not the numbers. A research process has a shape: sources before quotations, quotations before claims, claims before thesis, orders tried before the draft. The shape is what a record shows. The numbers — how many cards, how many days, how many sessions — are not evidence of anything, and two honest students will differ on every one of them by a factor of five.

Assume the pattern is a person. The student whose cards all carry the same date read on paper and transferred on Sunday. The student with a two-week gap had a job, or a family, or an illness. The student with one long session works in bursts. The student whose record is thin used a shared computer and could not keep the software open. A record read as a score punishes all four, and all four wrote their papers. A record often carries the student's own sentence about how they work; read that first.

Use it to ask, not to conclude. A record that surprises you is a reason for a conversation, not a finding. Your claims all appear on the last day — tell me about that is a fair question with several honest answers. An accusation is not a question, and a record does not support one on its own.

The policy language

If you are writing this into a syllabus or a department policy, the paragraph that has held up is something like:

Research papers in this course are handed in with a record of how they were written — your cards or notes and outlines, dated, in whatever form you kept them. The record is not graded and is not compared between students; I read it as I would read a draft. The course does not use detection software, because such software cannot tell who wrote a paper and has been shown to misjudge plain, competent prose. If I have a question about a paper, I will ask you, with your record on the table.

Say the last sentence in class as well as in writing. The students it reassures are the ones who were going to write their papers anyway, which is nearly all of them.

What this does not solve

A student determined to cheat can commission a process along with a paper. The design raises the cost of that from an evening to three weeks of someone else's work, which is enough to change most decisions and not all of them. No assignment design catches everyone, and one that claims to has made a false promise to the honest majority in order to threaten a small minority. The point of process-based design is not that it is airtight. It is that it asks for something the honest student already has, reads it fairly, and never puts a student in a meeting with a number nobody can explain.

The same method, on screen

Everything here works with a pack of paper cards. Leyden & Beam does the same steps on screen, keeps every order you try, and never writes a word for you.

Start your 14-day trial

Keep reading

Instructors · Guide 10 A peer-review workflow using shared decks Instructors · Guide 11 Scaffolding a research paper across a semester Instructors · Guide 8 Teaching the card method in one class session