Exporting a portable recording
A .red.md is a markdown file with your full writing recording baked in — every session, every keystroke summary, the signed chain that proves nothing's been altered. Hand it to a client, publisher, or admissions reader; they verify it on their own machine with no Red Stet account.
The file looks like ordinary markdown, opens in any text editor, and carries its own proof.
What a .red.md is red-stet:v1
Open one in TextEdit, VS Code, or any markdown viewer and you see your finished piece — clean markdown, the same text you'd paste anywhere. At the bottom, an HTML comment:
<!-- red-stet:v1 { "version": 1, "marks": […], "provenanceBundle": {…}, "__signature__": {…} } -->
Invisible to readers and renderers. Inside: every session manifest, the chain head, a body hash, an ES256 signature over the payload. Body and evidence travel as one file — email attachments, Dropbox, Google Drive all preserve it.
When to export one
Most days you don't. Red Stet records in the background; the recording is safe in your Writing Profile. The export is for when someone else has reason to look.
Concrete moments
- Freelance client questions whether you wrote the deliverable. Attach the
.red.mdand point them at /verify/. - Publisher requests provenance with the submission. Magazines and journals are starting to ask.
.red.mdalongside the manuscript answers it. - College or graduate program wants a writing sample with assurance. Personal statement, supplementary essay, portfolio piece — the recording goes with it.
- Public portfolio. Each piece has a sibling
.red.mdon the same server, linked from the piece, available on demand. - Priority claim. Two people claim authorship. The deeper, earlier recording wins.
- Personal archive. No recipient — you finished something you're proud of and want a sealed copy on your own drive.
The export is how the recording leaves Red Stet.
How to export downloadAnnotatedMdForSlug
Two surfaces produce a .red.md:
From the open document
The export menu has a Download annotated .md action. Bundles the current body + live recording + fresh signature. Filename: <slug>.red.md.
From the Writing Profile · Archive tab
Every recorded document shows up in the Archive tab. Each row has a .red.md download button. Use this when the doc isn't open, when sending last quarter's portfolio piece, or for a batch.
Both paths produce the same file.
.red.md next to it on every change. Click "Download" only when you need to send, not to keep a copy.
What recipients see when they open it
Depends on the tool:
In any text editor or markdown viewer
The piece. Headings, paragraphs, italics, links — the document as you wrote it. The trailing <!-- red-stet:v1 … --> renders as nothing in Marked, Bear, Obsidian, GitHub. The recipient reads your work without knowing the recording is there.
At redstet.com/verify/
The standalone verifier — drop the file, get a four-row verdict in under a second (see below). No login, no network call.
Re-opened in Red Stet
If your recipient is also a Red Stet user, they drop the .red.md into the app and the recording rehydrates — the full timeline plays back, every session, every gap. For a co-author or editor who wants the process, not just the verdict.
The signature chain __signature__
Two mechanisms make a .red.md hard to forge:
1. Internal chain — tamper-evidence
Each session produces a manifest with a chainHead. Every new manifest includes the previous session's chainHead in its inputs, forming a linked list. Edit a session's contents after the fact and its chainHead stops matching — and so does every later prevChainHead. One pass surfaces the break.
Around the whole bundle sits a bundleSeal — one final hash over the packaged recording. Edit the file at all (a keystroke count, a date, anything) and the seal stops matching.
2. External signature — authenticity
On export, Red Stet's server signs the manifest with an ES256 JWT — elliptic-curve, the algorithm used by Apple Pay and modern OAuth. The signature is over the SHA-256 of the canonical (RFC-8785) JSON. The verifier holds the public key, checks the signature, and confirms both: Red Stet signed this, and nothing's been altered since.
The standalone verifier — /verify/
Live at redstet.com/verify/. A single static HTML page with inline JavaScript. Drag a .red.md onto the drop zone, get a verdict in under half a second.
Four checks:
- Bundle seal — re-hash the recording (minus the seal field) and compare. Catches any post-export edit to events, manifests, or metadata.
- Session chain — walk the manifests; each
prevChainHeadmust match the previouschainHead. Catches inserted, removed, or altered sessions. - Document body hash — hash the body, compare to the recorded hash. Catches post-export edits to the text.
- Manifest integrity — recompute each session's
chainHeadfrom its contents and confirm. Catches tampering inside a session manifest.
All four pass: Verified — file integrity intact. Any failure produces a "what broke and where" message. Nothing is uploaded; it works offline.
Updating an exported recording
You exported a piece, sent it, then revised.
Re-export. Same path.
The new export contains every session, old and new, chained in order. Body hash reflects the revised text. chainHead advances. The old sessions haven't changed; they're still verifiable, just no longer at the end of the chain.
Send the new file and tell the recipient which version to trust. Both still verify — each is a true snapshot of what existed when it was exported.
external-edit event into the chain. The gap is visible and labeled, not hidden.
What travels with the file, what doesn't
The recording proves this piece. It doesn't unlock your account, your other documents, or your private metadata.
In the file
- The document body
- The full provenance bundle — every session manifest, every event in the local ledger, the chain head, body hash, bundle seal
- Marks and notes you applied (editors who reopen in Red Stet see them)
- The ES256 signature attesting the manifest came from Red Stet's signing pipeline
NOT in the file
- Your other documents
- Your Writing Profile
- Your account email, full name, or any credential
- Discarded drafts of this document — only the body-as-of-export, not every intermediate save
- Anything from a classroom (assignments, peer reviews, grades) — those live in their own scope
The author identity attached is the display identity you chose. If you wrote pseudonymously, the pseudonym is what gets signed. The signature attests "this recording came from a Red Stet pipeline with this author label", not "this is the writer's legal identity."
.red.md in Red Stet sees them. Read them back before you send.
Case: a freelance client wants proof
You delivered a piece; the client (or their editor, or their legal) wants assurance the writing is yours. Their AI-detector pinged, their guidelines require it, or they're nervous.
Two sentences and an attachment:
"Attached is a portable recording of the piece. Drop it at redstet.com/verify/ — it shows every session of writing plus a four-check integrity verdict. No login, runs in your browser."
What you've given them:
- A signed, sealed record of every keystroke summary across every session
- A tool to verify it themselves, offline, without learning anything else about you
- A standing offer — open it in Red Stet and watch the writing happen
Stronger than "I promise I wrote it." Verification takes under a minute.
Case: a college admissions reader
A reader at a competitive college sees thousands of essays a season, suspects AI in many, and doesn't want to play forensic analyst on each.
A .red.md sidecar gives them a five-second-to-five-minute option:
- Five seconds: verdict — "Verified, 9 sessions, 24h 02m." Move on.
- One minute: session count and total time. Does it look like a 17-year-old wrote this? A long, distributed recording with revisions matches the human shape. A 12-minute single-session sprint to perfect prose does not.
- Five minutes: open in Red Stet, scrub the timeline, watch the piece take shape. Rare but available.
The recording isn't graded. Long isn't proof of quality; short isn't proof of cheating. What the recording answers: did this person actually write this?
Related
→ What's recorded — and what isn't — exactly which keystrokes, pauses, and metadata the session ledger captures.
→ Reading a Red Stet recording — for a recipient, what the four checks mean and how to read the rhythm of a session.
→ Data retention & deletion — how long the recording survives, what's deleted on request, where the file copy lives.
→ Back to the help library for the full index.
Missing something? Email feedback — this doc grows by use.