The main paper makes the architectural case for TeacherAware and walks a worked classroom example. This appendix sits next to it and answers the specific question every teacher will have read the Goldstein NYT article and asked: does this actually work against the specific tools the article said are impossible to defeat?
The structure: verdicts up top so you can read the at-a-glance answer in two minutes; tool-by-tool depth in the middle for the specific cheating products you've heard of; the broader concerns the article raises after that (cognitive offloading, the shame pattern, the pen-and-paper retreat); the America-market-gap observation as one paragraph; the "How it works" deep-mechanism section at the end for readers who want to know how the structural defense is actually built; the article summary as reference material at the very end so the original source is at hand without taking the lead position.
The headline. Almost everything dies at Tier 0 [i mean... why are we even still talking about tier 0... this is a full thing] — the totally-free version of TeacherAware that requires no API key, no school account, and no recurring cost. The structural defenses (OS-hook injected-event flag, GitHub-routed submission channel, paste source signatures, USB device enumeration polling) handle the entire Goldstein-article roster locally on the teacher's and students' own machines. Tiers 1, 2, and 3 add AI verification and visual evidence that confirm what the structural layer already caught, and close the small residual cases (voice-via-earbud, external-tutor dictation). The free version is not a teaser; it's the load-bearing defense.
| Cheating tool / class | What it does | At Tier 0 (free) | Tier 1+ adds |
|---|---|---|---|
| Grubby AI | Humanizer — rewrites AI text to evade classifier-based detection | Dies. Architecture does not classify text. | — |
| Dripwriter | Autotyper — simulates human keystroke pacing, typos, fixes | Dies at OS hook layer. Injected keystrokes are OS-flagged structurally. | Tier 2 webcam screenshot also shows no hands at keyboard. |
| Duey.ai | End-to-end document generation marketed as "looks like you wrote it" | Dies at GitHub channel. Output is external; paste flags as S-PASTED-EXTERNAL. | Tier 1 screen screenshot can show source window if open. |
| Typeflo | Autotyper (defunct after NYT inquiry) | Same as Dripwriter — dies at OS hook layer. | Tier 2 webcam confirms. |
| Perplexity Comet | End-to-end agent — completes multi-page assignment from a prompt | Same as Duey. No commit credential to the student's signed branch. | Tier 1 screen screenshot shows Comet window if open. |
| Grammarly authorship | OS-level "help" that drafts substantial passages | In-app editor sandboxed against OS suggestion injection. Out-of-app paste flags. | — |
| GPTZero (detection side) | Classifier service for finished text | Different architecture; not in competition. | — |
| GPTZero (evasion side) | Tools to bypass GPTZero detection | Same as Grubby — no classifier to bypass. | — |
| Hardware HID injectors (Rubber Ducky class) | USB devices that present as keyboards and type pre-programmed content | USB device enumeration polling flags structurally on new-device-appeared. | Tier 2 webcam screenshot directly shows the plugged-in device + no hands typing. |
| External-tutor-with-AI | Parent or paid tutor runs Comet, hands result to student | Tutor cannot push to branch. Student handoff via paste flags; copy-typing flags via IKI mismatch. | Tier 2 webcam screenshot shows the tutor in frame or shows screen-share. |
| Voice-via-earbud + manual transcription | Student listens to AI via TTS, types what they hear | Transcription-signature keystrokes + zero in-app AI events — surfaceable structurally but not blockable. | Tier 3 audio-environment proctoring + continuous webcam closes it for high-stakes contexts. |
The pattern. Eight of the eleven named attack classes die outright at Tier 0 — the free version — via two structural boundaries that need no AI: the OS-hook injected-event flag (catches every autotyper that uses documented OS input APIs) and the GitHub-routed submission channel (catches every tool that produces a finished document). The remaining three — hardware HID injectors, external-tutor-with-AI, voice-via-earbud transcription — are flagged structurally at Tier 0 but only fully closed at Tier 1+ where visual evidence and the AI verifier add direct confirmation. For routine K–12 writing assignments, Tier 0 alone is sufficient defense against the entire consumer-software cheating-tool industry the Goldstein article documents.
Each named product or class at medium depth — what it does, why the architecture answers it, what residual risk remains. The deep mechanism (how the OS hook actually works, what the USB polling looks like, how the IKI baseline is built) is in the "How it works" section at the end of this appendix.
S-PASTED-EXTERNAL with a paste signature, and the certificate refuses to export.LLKHF_INJECTED set on synthetic input from SendInput(). On macOS the event source is inspectable via Quartz Event Services. On Linux uinput-injected events appear on a distinct evdev device. TeacherAware installs the hook at first run (with admin permissions); every chain entry records whether the keystroke was OS-flagged as injected. The certificate refuses to export if any non-trivial percentage of keystrokes is flagged — not as a statistical judgment, but as a structural rail. See "How it works" §6.b for the platform-by-platform mechanism.S-PASTED-EXTERNAL) or copy-type from Comet (produces an external-transcription keystroke pattern, missing the in-app AI events that would explain LLM-shaped prose).The article surfaces several concerns that are not attack modes per se but are part of the landscape that determines whether teachers can adopt the product. Each one is a place where the architecture has a specific answer.
The rubric distinguishes S-AI-RESEARCH (cognitive engagement — the student asked, learned, then composed) from S-AI-DRAFT (cognitive offload — the AI produced text the student edited). The dashboard shows per-student trend across the semester. A student trending heavy on S-AI-DRAFT flags structurally, which lets the teacher intervene before a habit ossifies.
Pedagogically: assignment specifications can require minimum percentages by tag — "this essay must be at least 70 percent S-ORIG with no S-AI-DRAFT paragraphs" is an enforceable rule because the certificate-export rail can refuse violations. The offloading concern becomes a tunable design parameter rather than a vague worry.
Honest framing: this surfaces and bounds the risk; it does not eliminate it. Teachers choose policies that match their pedagogical goals, and the system enforces them structurally instead of leaving them to honor-code wishful thinking.
The shame stems from a binary frame ("did you cheat or didn't you?") with AI use treated as cheating-by-default. The rubric replaces the binary with structured disclosure: what kind of AI use, to what extent, with what attestation. Diego the ELL student using AI as a translation partner is not confessing — he is describing what happened, and the rubric supports the use case. Honest answers stop being shameful because the framework makes appropriate use first-class.
TeacherAware preserves take-home writing as viable. The teacher does not have to give up the take-home essay to keep integrity intact, because the chain provides the integrity rail the format historically lacked. Pen-and-paper stays available for what warrants it; take-home writing comes back as a legitimate vehicle for the multi-day iterative work that builds composition skill.
The product framing line: TeacherAware exists so you don't have to choose.
TeacherAware is that surface. The in-app AI is the partner; the editor is where human discernment composes; the rubric is the legibility layer between them; the certificate is the structured artifact of the partnership. The major-vendor education head and TeacherAware agree on the destination; the architecture is what ships.
TeacherAware's positioning is congruent. The product is marketed as "make your AI use legible," not "make your AI use invisible." The framing is the architecture. The only ethical product position in this category is one that requires disclosure as a feature, not as a marketing afterthought.
Agreed and operationalized. Bans force students into dishonesty; structural disclosure invites them into legitimate use. TeacherAware enables responsible inclusion, not exclusion. The pedagogical claim for the paper: responsible inclusion is the only ethical option in 2026, and structural infrastructure is what makes it work in practice.
America has built a cheating-evasion industry; nobody has built a cheating-prevention industry that doesn't lose the arms race. Grubby, Dripwriter, Duey, Typeflo, Comet, Grammarly's authorship tool, GPTZero's evasion side — well-funded, slickly marketed, distributed through TikTok influencers including Harvard sophomores. The detection side is GPTZero and a few competitors, all stuck in the losing race the article documents. The structural alternative — source-constraint via sanctioned environment — does not exist as a commercial product. The gap exists because the obvious move requires giving up on the classify-finished-text paradigm, and that is a bigger psychological pivot than most ed-tech vendors will make. Detection vendors built the business; the business prevents them from seeing the architectural alternative even when their own market analysis says it is required. The teacher in the trenches today does not care about market analysis; the principal, curriculum coordinator, district CTO, and bar-association attorneys reviewing the school's AI policy do. Naming the gap gives them the frame they need to defend deploying TeacherAware against the obvious "have you considered detection-vendor-X?" pushback.
Everything above is the verdict. Everything in this section is the mechanism — for readers who want to understand exactly why the verdicts are correct, and for the principal-CTO-attorney audience that will need to read it before signing a contract.
The defense is layered, and the layers are not equal. The weakest layer is the one the previous version of this analysis led with (statistical signal); the strongest is the one the architecture actually depends on (OS-enforced injection-flag inspection). Honest framing matters here because the layered structure is what makes the defense robust against attacker creativity.
| Layer | What it catches | Defense type |
|---|---|---|
| Application event handler only | Naive autotypers via IKI / semantic-pause / revision-pattern statistics | Statistical — degrees, not absolutes |
| OS keyboard hook with injected-event flag | Every software autotyper that uses documented OS input APIs (SendInput, CGEventPost, uinput) — Dripwriter, Typeflo, AutoHotkey, Puppeteer, Selenium | Structural — binary, OS-enforced |
| USB device enumeration polling + co-event consistency | Hardware HID injectors (Rubber Ducky class); headless automation; missing co-events (mouse, scroll, focus) | Structural — direct observation |
| Webcam tier trigger + MDM USB whitelisting | Hardware HID attacks at the policy layer; voice-via-earbud at the proctored tier | Policy + proctoring |
The crucial thing about this table: the structural layers (2, 3, 4) do not depend on statistical confidence. An autotyper either has the OS-injection flag set on its keystrokes or it doesn't. A USB device either appears in the device-enumeration log or it doesn't. The webcam trigger either fires or it doesn't. The statistical layer (1) is the secondary catch for cases where structural layers miss; it is not the primary defense.
Every major desktop OS has a privileged hook layer above the application event queue. This is the layer at which anti-cheat systems for online games operate (BattlEye, EasyAntiCheat, Vanguard), password managers store and inject credentials, and accessibility tools mediate input for assistive technology. TeacherAware installs a keyboard hook at this layer at first run, requesting admin permissions if not already running as administrator. The hook captures every keystroke before it reaches any application, including the TeacherAware editor itself.
At this layer, the OS itself tells us whether an event came from a real keyboard or from a software API. The flag is not app-settable; it cannot be spoofed from user-space.
SetWindowsHookEx(WH_KEYBOARD_LL) installs a low-level keyboard hook. Each event carries a KBDLLHOOKSTRUCT with flags including LLKHF_INJECTED (set by the OS on synthetic events) and LLKHF_LOWER_IL_INJECTED (set when the injection came from a lower-integrity-level process). Both flags are set by the kernel; user-space cannot clear them. SendInput()-injected events from AutoHotkey, Dripwriter, Puppeteer, and similar all leave these flags set.
Quartz Event Services exposes the event source via CGEventGetIntegerValueField with kCGEventSourceUserData and kCGEventSourceUnixProcessID. A process with Accessibility permission can see which process emitted each synthetic event. CGEventPost calls leave a process trace. The Accessibility permission is the gate; managed deployments grant it via MDM profile.
Software-injected events arrive on a uinput-backed virtual evdev device, distinct from the real keyboard's evdev device. Monitoring at the evdev layer distinguishes them trivially. Less commonly the threat model for student devices but identical mechanism.
The chain records, per keystroke, whether the OS flagged it as injected. The certificate refuses to export if any non-trivial percentage of keystrokes (default threshold: above 1 percent) is flagged. The teacher dashboard shows the row with an "injection detected" status. There is no statistical inference here — it is a direct readout of the OS's own injection flag.
The OS-hook layer cannot distinguish a USB HID device pretending to be a keyboard (Rubber Ducky class) from a real keyboard, because at the OS level it is a real keyboard. The defense moves to enumerating connected HID devices.
SetupDi* APIs enumerate the HID device list. On macOS, IOKit's IOHIDManagerCreate. On Linux, /dev/input/by-id/ or libudev. All return device VID/PID and product strings.For managed school deployments, the MDM layer above this is the institutional defense — district IT pushes a policy that whitelists which USB HID devices the student's machine accepts. This is standard practice for school-issued Chromebooks and laptops; not a new ask.
The OS-hook layer requires elevated permissions to install. This is the cost of the defense, and it has two paths depending on the deployment context.
The admin-permission requirement is the same boundary that legitimate anti-cheat systems, password managers, and accessibility tools cross. It is a known consumer software pattern, not a novel ask. The privacy implication — TeacherAware can see every keystroke while the hook is installed — is bounded by the app's explicit policy: keystrokes are recorded only into the chain for the active TeacherAware writing session; nothing is logged when TeacherAware is not the active writing surface, and nothing is transmitted off-device beyond what gets sealed into the certificate.
The other structural defense, separate from the OS-hook layer: the teacher receives student input only via the student's signed branch in the teacher's class repo. There is no other submission path.
The repo-as-inbox model is also the reason the teacher does not need to babysit the LMS during the school day. When she opens her dashboard, it pulls from every student branch and reconciles. No real-time anything. The git architecture handles distributed-update reconciliation as a native primitive.
For completeness: the statistical signals at the application event layer remain useful as confirmation, even though they are not the primary defense.
These signals confirm what the OS-hook layer already caught. If the layers ever disagree — OS hook says "no injection" but statistics say "suspicious pattern" — the disagreement itself is informative. The teacher reviews; the system does not adjudicate.
What the article documents. By mid-2026, the student AI-cheating ecosystem has matured into a distinct consumer-software category. TikTok and YouTube tutorials promote a class of "humanizers" (rewrite AI text to evade detection) and "autotypers" (drip-feed AI text into documents with simulated typos and pauses). Roughly two-thirds of American students use AI regularly for schoolwork; about 9 percent admit outright cheating in surveys; three-quarters of College-Board-surveyed professors report student AI use, with more than 90 percent expressing plagiarism concern.
The named products. Grubby AI, Dripwriter, Duey.ai, Typeflo (deleted after NYT inquiry), Perplexity's Comet, Grammarly's authorship tool, GPTZero (which claims 99 percent detection accuracy and also markets cheating-evasion under the same brand).
The named voices.
The cognitive-offloading concern appears late in the article and is framed as orthogonal to cheating-detection: "Several studies have shown that people who rely on A.I. can experience cognitive offloading, a process in which they fail to build new skills, or their existing skills degrade."
What the article does not propose is a structural alternative. It documents the detection race as failing, names a few mitigations (heavier in-class assessment, partner-not-replace framing) and stops. The space where TeacherAware speaks is exactly the structural alternative the article gestures at but does not fill in.
teacheraware/notes/teacheraware-product-scope.md (internal scoping)x-parent, x-relation, x-artifact-type) and visible callouts; intended to surface in the Workbench artifact picker as a related sub-artifact of the parent paper.