SUM: source review and checkable transformations

SUM helps people reshape text, inspect changes against the original source, and share a checkable review. Its long-term aim is a knowledge distiller with useful levels of detail and perspective over retained sources. Today the browser workbench (sum-demo.ototao.workers.dev) supports source/rewrite review and receipt-aware export; the CLI and MCP add model-based research measurements and offline verification.

A signed receipt identifies the bytes and measurements an issuer attested. It does not prove that meaning survived or that the issuer is a trusted organization. Keep source review, model measurements, statistical assumptions and cryptographic checks separate.

See what an AI transform silently dropped. sum meaning-diff reads out, per document, which source claims survived a rewrite and which vanished. Here it is on a shipped fixture — a four-clause lease notice rewritten as verse:

$ sum meaning-diff examples/poetry_frontier/source.txt examples/poetry_frontier/sonnet.txt --scorer nli
Meaning readout — measured for THIS document (not a certified bound)
  judge: nli:MoritzLaurer/DeBERTa-v3-base-mnli-fever-anli v1
  preservation: 55%   (loss 0.450)
  source claims: 4 — 1 preserved, 3 DROPPED:
     ✗ Late payment after the fifth day incurs a 50 dollar fee.
     ✗ The landlord must give 24 hours notice before entering the unit.
     ✗ Either party may terminate this lease with 30 days written notice.
  added / unsupported claims: none ✓

  → 3 dropped — review before relying on this rendering.
  (measured for THIS document under the named judge — a per-document MEASUREMENT, not a certified bound or a guarantee; for a (1-δ) bound use a meaning_risk receipt over a named corpus.)

To run that exact command: pip install 'sum-engine[research,judge]' (meaning-diff needs [research]; the --scorer nli judge needs [judge]) from a git checkout — examples/ ships in the repo, not in the wheel. The zero-clone path is the receipt replay in Verify it yourself in 60 seconds below.

Receipt-producing operations can sign their declared inputs, outputs and metadata. Offline verification checks those signed fields against supplied keys. Extraction, unsigned local bundles and human review decisions must not be described as signed when no signature is present. Historical per-axis benchmarks are measurements on their named corpora, not a measurement of the current browser result.

Live trust loop: https://sum-demo.ototao.workers.dev — the Worker and the Python package sign Ed25519 over JCS-canonical bytes; Python, Node and browser verifiers check those bytes offline against /.well-known/jwks.json. CI runs the Python and Node paths on every PR (the JS verifiers under Node, the workbench tests under jsdom); no browser engine runs in CI.

Use cases to evaluate: editors reviewing rewrites, researchers tracking source evidence, and AI teams exchanging checkable artifacts. Real recurring use and willingness to pay remain to be established. Audit-log validators check specific data structures; they do not certify organizational or legal compliance.

The cryptographic side is mechanically checked — the Python and Node verifiers agree on the K-matrix (valid) and A-matrix (invalid) fixture bundles in CI on every PR; the browser verifier implements the same checks but no browser engine runs in CI. The semantic side (extraction quality, slider fact preservation) is empirically measured with explicit per-corpus numbers and explicit per-corpus boundaries. docs/PROOF_BOUNDARY.md is the arbiter.

Headline supporting numbers (each links to its source of truth):

Claim	Status	Source
Python ↔ Node agreement on Ed25519 over JCS bytes (the browser verifier is not run in CI)	provable; locked by make xruntime (K1–K4) + make xruntime-adversarial (A1–A8)	docs/PROOF_BOUNDARY.md §1.2, §1.3.1
Canonical round-trip reconstruct(parse(canonical_tome(S))) == S	provable; 0.00% drift on every CI run	docs/PROOF_BOUNDARY.md §1.1
Render receipt — sum.render_receipt.v1, Ed25519 / JCS / detached JWS	shipped; verifier in three runtimes	docs/RENDER_RECEIPT_FORMAT.md
Slider fact preservation, two runs with the current render prompts (v0.7, v0.8; 16 long documents; SUM's Python renderer with OpenAI gpt-4o-mini): median 1.000 in both, lowest cell 0.700 and 0.545, p10 0.750 (v0.7; none reported for v0.8); the Worker's renders (Claude Haiku 4.5 by default, or OpenAI) are not benchmarked	empirical-benchmark: measured; same-commit replay receipt still pending (bench-hardening T2/T3)	docs/SLIDER_CONTRACT.md
Extraction F1 = 1.000 (seed_v1), 0.762 with precision 1.000 (seed_v2)	empirical-benchmark	docs/PROOF_BOUNDARY.md §2.1

A render receipt verifies the render attestation (issuer signed this tome, these triples, this slider position, this model, at this time). It does not verify the truth of the tome's content. The slider bench measures a named preservation proxy on a particular corpus; it does not establish factual truth either. See docs/RENDER_RECEIPT_FORMAT.md §5 for the explicit trust scope.

---

This is the beginning of the README. Read the rest at the original. Read the full README ↗