papers: design sketch outline for arxiv position paper (#67)

CHANGELOG.md

@@ -6,6 +6,11 @@ Prose references a version as `v0.X.Y`; headings stay bare `[0.X.Y]`.
 
 ## [Unreleased]
 
+### Added
+
+- `papers/` directory for external-audience writeups (researchers, engineers at competing chains, funders). Distinct from `spec/rfcs/` (proposals) and `spec/protocols/` (stable specs). Has its own lifecycle: outline → draft → review → published → superseded.
+- `papers/design-sketch.md` outline. Position paper structure covering 12 sections + appendices: chain manifest as the central abstraction, multi-VM execution, effect-typed contracts, multi-dimensional gas, sampling-first data availability, implementation status, related work. Each section has 2-5 bullets sketching what the final prose will argue, citations to assemble, and open questions for the drafting phase. Target: 10-15 pages typeset, arxiv + project website, 3-6 months from outline to published. Lands the scaffolding for issue #67.
+
 ### Changed
 
 - `spec/rfcs/0004-cross-engine-state.md` expanded to decision-ready proposal. Commits to **option (b)** from the original 4 design candidates: unified KV addressed by `(engine, identity, key)` triples with a single Merkle root. Concrete byte-level key encoding (1-byte engine tag + 20-byte identity + variable engine-specific key), synthetic WASM module addresses (keccak256 of chain_id + module_name + version), cross-engine reads via host functions (WASM->EVM) and a reserved precompile (EVM->WASM), no cross-engine writes in v0. 4-phase implementation roadmap (~850 LoC total). Open questions reduced from 6 to 1 (perf-bench validation of <10% prefix-encoding overhead).

papers/README.md

@@ -0,0 +1,42 @@
+# Cleave papers
+
+This directory holds writeups about Cleave's design and implementation that are intended for an external audience: researchers, engineers at competing chain projects, funders, future contributors deciding whether the design is interesting.
+
+Distinct from:
+
+- [`spec/rfcs/`](../spec/rfcs/) — RFCs are proposals for changes. Audience: maintainers + active contributors.
+- [`spec/protocols/`](../spec/protocols/) — stable specs for shipped interfaces. Audience: implementers.
+- This repo's `README.md` — the project's surface-level story. Audience: anyone landing on GitHub.
+
+Papers here are longer than READMEs and more deliberate than blog posts. They're meant to be citeable.
+
+## Lifecycle
+
+Each paper has a status header:
+
+| Status | Meaning |
+|---|---|
+| `outline` | Section structure + bullet-level descriptions. Not a draft. |
+| `draft` | Full prose, but unreviewed and likely to change. |
+| `review` | Out for review with named reviewers. |
+| `published` | Final. Cited externally. |
+| `superseded` | Replaced by a later paper. Cite the successor. |
+
+Status changes via the file's frontmatter. No tooling.
+
+## Current papers
+
+| File | Status | Target |
+|---|---|---|
+| [`design-sketch.md`](design-sketch.md) | outline | arxiv + project website, ~3-6 months from outline |
+
+## Versus academic publishing
+
+These are not peer-reviewed papers. They're position papers / design sketches. Cleave reserves "real" academic publishing for empirical work once the chain layer is shipping (consensus + state + a real testnet). That's the [`#67`](https://github.com/cleave-lang/cleave/issues/67) timeline: ~12-18 months out from now.
+
+A position paper bridges the gap. It exists so:
+
+- Researchers writing about smart-contract languages have something specific to cite
+- Engineers at competing chains can read the design without reverse-engineering the repo
+- Funders + design partners have a single artifact that captures Cleave's argument
+- Future contributors can decide whether the project's direction is worth their time