Exporting a portable recording

What a .red.md actually 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.md, point them at /verify/, walk away.
• Publisher requests provenance with the submission. Magazines and journals are starting to ask. .red.md alongside 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.md on 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 the artifact that lets your evidence leave Red Stet. Inside the app, the recording is always there. Outside, it travels as a file.

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.

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 red-stet.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 — what makes this evidence-grade __signature__

Two interlocking 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.

Internal chain: the recording is internally consistent. External signature: it came from the real Red Stet pipeline.

The standalone verifier — /verify/

Live at red-stet.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:

1. Bundle seal — re-hash the recording (minus the seal field) and compare. Catches any post-export edit to events, manifests, or metadata.
2. Session chain — walk the manifests; each prevChainHead must match the previous chainHead. Catches inserted, removed, or altered sessions.
3. Document body hash — hash the body, compare to the recorded hash. Catches post-export edits to the text.
4. Manifest integrity — recompute each session's chainHead from 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; works offline, works on a plane.

Updating an exported recording

You finished a piece, exported it, sent it — and now you've revised. What happens to the old .red.md?

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. Tell the recipient which version to trust. Verify the old and the new — each passes on its own terms. Two valid snapshots of the same evolving recording. There's no "invalidation" — the earlier export remains a true snapshot of what existed then.

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."

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 red-stet.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

Admissions essays are where provenance is starting to matter most. 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.