How we prove it
How Loam verifies writing-process evidence
Loam verifies actual submission records inside the product by rebuilding the document and checking its linked evidence and server checkpoints. Its public browser verifier currently supports one versioned synthetic demonstration PDF only; author-issued portable PDFs remain in development. Neither check proves legal identity, authorship, originality, truth, quality or the absence of outside help.
Your PDF stays in this browser. It is not uploaded to Loam.
Inspection runs on this device. Download the sample to try it.
Preparing the verifier…
This takes a moment.
Try the verifier
Download the sample, then choose it in the verifier.
Synthetic walkthrough
What does the synthetic sample verify?
The sample demonstrates that this browser verifier can validate the sealed bytes and reconstruct the evidence included in a known synthetic Loam PDF. The result applies to this generated fixture. It is not student work or a production authorship proof.
Download the versioned synthetic sample PDFVersion 1 demonstration file. Select this file in the verifier above; its contents stay on this device.
- 01
Recognise the exact demonstration
The browser compares the complete file with the published sample digest and accepts its explicitly demo-only purpose and trust entry. The demonstration key cannot satisfy the separate trust policy required for an author-issued production export.
- 02
Check the sealed record
The verifier validates the signed PDF byte range, its ECDSA and SHA-256 seal, the embedded manifest, and the hashes of the disclosed payloads. It then recomputes the linked replay hashes and rebuilds the final title and document.
- 03
Show what the file discloses
This synthetic sample includes Level 3 evidence, so a successful check can show its fictional account label, sealing metadata, session summary, and full replay. The planned author-issued format may disclose less, according to the level selected when it is exported.
What can this result not prove?
A valid sample result does not establish a person’s legal or physical identity, who originated the ideas, whether AI or outside help was used, or whether the writing is true, original or good. It also does not turn the public demo key into a production Loam signing key.
The evidence chain, end to end.
prev 6b2f…
head a1b2f7
prev a1b2f7
head c48d10
prev c48d10
head 9f0e33
each edit carries the previous head, so changing, removing or reordering a block breaks every hash after it
- 01
The sealed editor
Assignments are written in a dedicated editor that blocks pasted prose. Students can paste a single link and attach reference files. Changes made inside the editor join the evidence record in order.
- 02
A SHA-256 hash chain
As the document changes, each edit is captured as a delta and hashed with SHA-256 together with the hash of the edit before it. That linkage is what makes the record tamper-evident: change, remove, or reorder any single edit and every hash downstream stops matching.
- 03
Server countersignatures
At regular checkpoints the client sends its current chain head to our server, which returns an HMAC countersignature bound to server time. The student's device cannot create that server receipt without access to the server-held key. In-product verification checks whether the recorded checkpoints are valid and tied to the server times shown.
- 04
Verify: byte for byte
Inside the product, Loam replays every delta from the chain and re-derives the finished document byte for byte, then validates each hash link and server countersignature against the service's records and keys. If the rebuilt document matches and the checks pass, Loam has established facts about the evidence record. It has not made a finding about the student. A failed check is shown for review.
- 05
Replay
Beyond the result of verification, a teacher can press play and watch the assignment being written: the pauses, the revisions, and how the writing changed. That replay is evidence a human can read and use in a conversation.
What we deliberately never collect.
This is the part most integrity tools bury. We put it up front, because collecting less is the entire design. Loam watches the document, never the student.
No camera or microphone
We never request webcam or mic access. There is no room to watch and no audio to record.
No screen or activity recording
No screenshots, no screen capture, no lockdown browser, no watching other tabs or applications.
No keystrokes outside the editor
We record edits to the assignment document only. What you type anywhere else on your device is none of our business.
No biometrics
No keystroke-dynamics fingerprinting of a person, no typing-rhythm identity profiles, no behavioural biometrics of any kind.
No hidden profiling
We don't build a shadow profile, sell data, or feed student writing to third-party advertising or model training.
And what we do keep.
Honesty cuts both ways. To provide and verify the evidence record, Loam keeps the items below. The Privacy Policy lists the account, document, evidence and technical data in full.
- Account and class information: name, school email, role, school, class membership and the authentication records needed to secure the account.
- The assignment document, including any images, links or files the student adds, and the edit history that makes up the chain.
- The SHA-256 hash links and our server HMAC countersignatures and their server timestamps.
- Counts, events and session signals the editor produces, including word and keystroke counts, blocked-paste events and timing information.
- Standard technical logs such as IP address, browser type and timestamps, used for security and troubleshooting.
Portable proof format in development
The planned format keeps proof with one readable PDF.
Loam is developing an author-issued format designed to keep a normal, readable PDF and its signed evidence in one file. The verifier on this page currently demonstrates that design with the synthetic sample only. Copying its text into a new PDF, DOCX, email, or web page does not carry the demonstration seal.
The signed account-name claim records which Loam account exported the file. It does not, by itself, establish a person’s legal identity. Current in-product checkpoints use server HMACs; portable offline verification requires a separate asymmetric export seal and public trust bundle.
- 01
Verified document
The signed document binding, Loam issuer, sealing time, evidence root and the account name recorded at export.
- 02
Writing evidence
includes Levels 1Everything in Level 1, plus a signed, session-specific report about timing, pauses and revisions. It is not a typing identity profile.
- 03
Full replay
includes Levels 1 and 2Everything in Levels 1 and 2, plus the event record needed to reconstruct the writing session, including deleted and replaced text where captured.
Evidence embedded in a shared PDF cannot be withdrawn from copies already distributed. Level 3 is the most revealing: anyone with the file may be able to extract deleted text, timestamps, false starts and the complete revision history.
Source ledger
Which primary sources support this methodology?
These sources define the public sample and the cryptographic primitives described on this page. The standards do not certify Loam’s product, implementation or evidentiary claims.
- 01Loam — versioned synthetic portable-proof sample
The exact public demonstration artifact used by the local walkthrough. It is visibly and cryptographically scoped to demo use and is not student work or an author-issued production proof.
- 02NIST — FIPS 180-4 Secure Hash Standard
Primary technical standard for the SHA-2 family, including SHA-256. It defines the hash primitive; it does not validate Loam’s surrounding record format or implementation.
- 03NIST — FIPS 186-5 Digital Signature Standard
Primary technical standard covering ECDSA, the signature algorithm used by the portable sample. It does not certify Loam’s keys, trust policy or implementation.
- 04IETF — RFC 2104 HMAC
Primary specification for HMAC, used for Loam’s server checkpoints. The portable verifier checks the sealed checkpoint record; it does not expose the server secret or independently recompute an HMAC.
- 05W3C — Web Cryptography API
Primary browser specification for cryptographic operations used by the local checker. The standard defines the API; it is not an audit of this verifier.
Methodology and sources last reviewed .
Questions IT and integrity offices ask.
- What can the public portable-proof verifier check today?
- Today it checks the versioned synthetic demonstration PDF on this page. A valid result shows that the demo's signed document and included evidence match its recognised demo seal. Author-issued portable PDFs remain in development. The demonstration does not prove identity, authorship, originality or the absence of outside help.
- What proves a submission wasn't tampered with?
- Every edit is captured as a delta and hashed with SHA-256 together with the hash of the edit before it. That linkage is what makes the record tamper-evident: change, remove or reorder any single edit and every hash downstream stops matching.
- Can a student's device mint a server checkpoint by itself?
- Not without access to Loam's server-held key. At regular checkpoints the client sends its current chain head to the service, which returns an HMAC countersignature bound to server time. The receipt can show that Loam issued that checkpoint; it does not prove who was using the device or rule out compromised service credentials.
- What does in-product verification actually check?
- Inside Loam, verification replays every delta, re-derives the finished document byte for byte, and validates each hash link and server countersignature. The public demo instead checks its outer ECDSA seal and the consistency of the included checkpoint record; it cannot independently recompute the server HMACs. Neither result is a finding about the student.
- Does Loam record the student's screen or camera?
- No. Loam never requests webcam or microphone access, never takes screenshots or screen captures, and records edits to the assignment document only. What a student types anywhere else on their device is not part of the record.
- What data does Loam actually keep?
- Account and class information, the assignment document and its edit history, the SHA-256 hash links and server countersignatures with their timestamps, editor-generated counts and events (word/keystroke counts, blocked-paste events, timing), and standard technical logs for security and troubleshooting. The Privacy Policy lists this in full.
- Can our privacy or IT team review this before we sign?
- Yes. Data-processing agreements, published subprocessors and security-review support come with the School plan. Send your reviewer's questions our way and we'll walk the whole chain with them.
Bring your reviewer. We’ll walk the whole chain.
Data-processing agreements, published subprocessors and security-review support come with the School plan. If your privacy office has questions, send them our way. We’d rather answer them before you sign than after.