Proofnote

From a proof format to a document engine

Proofnote began with a very ordinary problem: email is a poor place to present long mathematical explanations. Gmail does not render Markdown, so formulas, arguments, caveats, and supporting details quickly turn into dense blocks of text, and I often simplified an explanation just to keep the message readable.

That origin produced Solution Note 1.0, which remains supported through an explicit compatibility import/export path. Its proof-oriented presentation ideas survive in the modern Proof Note workflow, but it is no longer Proofnote's underlying document model.

Documents are built from blocks

A document is assembled from designed blocks such as title, heading, paragraph, equation, code, table, image, semantic block, and list. Authoring means choosing the meaning of each piece of content, not fighting free-form CSS.

Proofnote itself controls typography, spacing, and print rules, so documents stay consistent across notes and read the same on screen, in print, and in PDF. The block editor keeps that structure visible and editable, and reusable templates turn a recurring document shape into something that can be applied in one step.

Designed for AI-assisted authoring

AI-generated content is treated as input to verify, not output to trust blindly. Models can generate Proofnote Document Format JSON, while Proofnote checks syntax, schema, document limits, LaTeX, and structural consistency before the content reaches the editor.

Proofnote Editable HTML extends that workflow beyond one-way generation. A document can be exported as human- and AI-editable semantic HTML, changed outside the application, and imported again. Proofnote recovers explicit semantic edits such as text changes, block insertion, deletion, movement, tables, headings, and LaTeX source while treating CSS, classes, wrappers, and rendered previews as presentation only.

The importer does not guess when the protocol becomes ambiguous. Duplicate block identities, damaged baselines, conflicting fields, stale revisions, and other unsafe states are diagnosed and rejected rather than silently converted into a different document.

Local-first documents, Projects, and templates

Multiple documents live in a local library backed primarily by IndexedDB, so normal use needs no account or application backend. Built-in templates cover Blank, Proof Note, Research Note, Lab Report, and Essay / Report, and any document can be saved as a personal template.

Local Project containers provide a lightweight way to organise related documents without turning Proofnote into a filesystem or IDE. A Project can collect independent proofs, experiments, audits, and notes behind one overview and navigation tree, while membership remains local library metadata rather than part of the portable document itself.

Moving a document between Projects therefore does not change its canonical content, Editable HTML identity, revision lineage, or exported file. Deleting a Project removes only the local container; its documents remain available as unfiled documents.

Portable by design

Proofnote JSON is the canonical form: a complete backup and migration artifact that carries the document model rather than a rendering of it. Presentation HTML is the shareable, archivable, readable form of a document, with its rendering assets embedded, and print or PDF output extends that same line to final presentation.

Proofnote Editable HTML is a separate promise from Presentation HTML: it is a human- and AI-editable semantic representation that can be changed outside the application and round-tripped back into the canonical document, checked against a recorded baseline. Keeping the two formats distinct is what lets one prioritise faithful presentation while the other prioritises safe semantic editing.

Current state

Proofnote is currently at v3.1.0-rc.1, with the current workspace revision at v1.48. The core document model, block editor, local library, Project navigation, and Editable HTML round-trip protocol are now in a release-candidate state. Recent work has concentrated less on adding new document concepts and more on hardening persistence, revision conflicts, import boundaries, semantic recovery, and failure behaviour.

Project activity