--- id: SHARD-WP-0004 type: workplan title: "computational / interactive-knowledge systems research" domain: whynot repo: shard-wiki status: done owner: tegwick topic_slug: whynot created: "2026-06-14" updated: "2026-06-15" state_hub_workstream_id: "5fc3911a-1c68-4826-bbd2-b892dec8f981" --- # SHARD-WP-0004 — computational / interactive-knowledge systems research ## Goal Research systems **tuned to interactive usage of knowledge interacting with computation, programming, and mathematics** — literate programming, computational notebooks, live- coding REPLs, and image-based/moldable programming environments — to extract patterns for shard-wiki's treatment of **executable / computational / live page content** and **one-source-many-projections**. This workplan is more *exploratory* than the engine batch (`SHARD-WP-0003`): these systems are mostly **not candidate shards**, they are **design prior art** for questions the modern-tool dives raised but did not answer — what a "page" is when it is a *live computation*, how *computed results* carry provenance/reproducibility, and how one source projects into multiple rendered forms. Outputs feed the **page model** and the **addressing/ navigation** threads of the adapter contract, and may produce a dedicated synthesis ("the computational page model"). Each subject follows the dive tradition (`research/--deep-dive/` with `README.md` + `findings.md`) but the catalog yield is expected to be **fewer new UCs and more page-model / projection design notes**. Promote UCs only where a genuine new *orchestration* scenario appears; otherwise enrich (UC-44 compose-by-reference, UC-54 query-defined page, UC-55 non-Markdown content, UC-32 transclusion) and log page-model implications for `SHARD-WP-0002` T12/T16. ## Context - Page-model thread: `SHARD-WP-0002` T12 (structured/typed/computed payload, query-defined pages, non-Markdown content) and T16 (addressing, transclusion, dimensional/query nav). - Relevant existing UCs: UC-44 (compose-by-reference / EDL manifest), UC-54 (query-defined dynamic page), UC-55 (non-Markdown content), UC-32 (transclusion), UC-63 (derived index). - Synthesis: `research/260614-shard-spectrum-synthesis/findings.md` (the spectra a "computational content" capability would extend). **Framing question carried across all subjects:** *Can a shard-wiki page be a live computational artifact — a source that is woven/tangled/evaluated into rendered forms — and if so, how do projection, transclusion, provenance, and the adapter contract treat the source, the kernel/environment, and the computed output?* **Non-goal:** Implement a kernel or execution layer. Research + design notes only; any "executable content" remains mechanism-over-policy and capability-gated. --- ## Literate Programming — Knuth's WEB / weave / tangle ```task id: SHARD-WP-0004-T1 status: done priority: high state_hub_task_id: "c252fccc-c442-4437-b1c7-4a310d1ede3c" ``` Deep-dive **Donald Knuth's WEB** and the **weave/tangle** model of **literate programming**. The keystone pattern: **one WEB source → `weave` (typeset documentation) + `tangle` (compilable code)** — *one source, two projections* — plus **named code chunks** referenced/embedded across the document (transclusion-like). This is the deepest ancestor of shard-wiki's **projection** and **transclusion** ideas applied to *executable* content. Map to UC-44 (compose-by-reference), UC-32 (transclusion), and the projection model; log "source-with-multiple-projections" as a page-model pattern for T12. ## Mathematica Notebooks ```task id: SHARD-WP-0004-T2 status: done priority: medium state_hub_task_id: "6e46ec45-3c4a-4eb0-815d-d401d72394d5" ``` Deep-dive **Mathematica Notebooks** (the `.nb` format and cell model). The original computational notebook: **cells** (input/output/text), an **expression-tree** document, symbolic evaluation, interactive results inline. Study the document format, output provenance, and reproducibility. Enrich UC-54 (query/computation-defined content), UC-55 (rich computed output); page-model notes on **computed-output cells** for T12. ## Jupyter Notebooks ```task id: SHARD-WP-0004-T3 status: done priority: high state_hub_task_id: "3d35d58f-a9ea-44f9-89ea-d89205da8d8b" ``` Deep-dive **Jupyter Notebooks**: the **`.ipynb` JSON** model (cells: markdown / code / output), **kernels**, embedded outputs, and execution-count/provenance. The dominant computational document — and a concrete **non-Markdown, partially-executable content type** with **embedded computed outputs** that carry (fragile) provenance. Highly relevant to a "computational shard" and to output reproducibility. Enrich UC-54, UC-55, UC-59 (lossy capture of rich outputs); consider a new UC for **attaching/projecting a notebook with computed-output provenance**; feed T12/T15. ## Processing.org and Processing.js ```task id: SHARD-WP-0004-T4 status: done priority: low state_hub_task_id: "0f54cb0e-ca8a-4131-ad4d-a675f21e153c" ``` Deep-dive **Processing.org** (creative-coding) and especially **Processing.js** (browser-run sketches). The pattern: **the sketch *is* the document** — a program whose rendered form is live visual output, runnable in the browser. Study "program-as-page" and client-side live rendering. Notes on **executable/visual content rendered at view time** for the page model (UC-54/55). ## Strudel.cc — live-coding REPL ```task id: SHARD-WP-0004-T5 status: done priority: low state_hub_task_id: "2b099639-3f8b-4b29-a24a-75f7418dd083" ``` Deep-dive **Strudel.cc** (the JS port of TidalCycles): a **browser REPL** for live-coding music/patterns. The pattern: **code as a live, evaluated performance**; a page whose "content" is a running pattern. Study the REPL/live-evaluation model and pattern language. Notes on **live-evaluated, time-based content** and the limits of static projection (UC-54/55; graceful degradation to a snapshot). ## Squeak Smalltalk ```task id: SHARD-WP-0004-T6 status: done priority: medium state_hub_task_id: "50723598-7e21-4aaf-8f26-463cabc4e2d7" ``` Deep-dive **Squeak Smalltalk**: the **image-based** live-object environment — "everything is a live object," the **image as a persistent world**, Morphic. The pattern: **knowledge-as-live-objects** rather than files, and an environment with no file/document/app boundary. Contrast hard with shard-wiki's files-canonical stance (design-bug boundary), but mine it for **live-object / moldable** ideas. Page-model and boundary notes (image-as-store is the anti-pattern; the live-object inspection is the inspiration). ## Glamorous Toolkit — moldable development ```task id: SHARD-WP-0004-T7 status: done priority: high state_hub_task_id: "9e11efac-92d1-4226-b532-7d916a26c70b" ``` Deep-dive **Glamorous Toolkit** (on Pharo): **moldable development** — **custom views/ inspectors per object/domain**, a notebook + IDE where the *environment adapts to the knowledge*. The pattern: **many co-equal, domain-specific views over the same live objects** — a striking parallel to the ZigZag dimensional model (UC-47/48) and to "query-defined / computed views" (UC-54). The strongest source for **moldable, multi-view projection** of knowledge. Enrich UC-47/48 (dimensional/multi-view), UC-54; feed T16. ## Pharo ```task id: SHARD-WP-0004-T8 status: done priority: low state_hub_task_id: "b3a862d0-6980-411a-b41c-dd3592a39c52" ``` Deep-dive **Pharo**: the modern Smalltalk that GT is built on — live image, reflective environment, the substrate for moldable tools. Largely **context for T6/T7** (Squeak lineage → Pharo → Glamorous Toolkit); keep brief unless it surfaces distinct page-model ideas. May be folded into the GT memo if thin. --- ## Acceptance criteria - Each of T1–T8 has a `research/--deep-dive/` dir with `README.md` + `findings.md` (or a justified merge, e.g. Pharo folded into GT), framed by the carried question above. - `spec/UseCaseCatalog.md` updated **where a genuine orchestration UC appears**; otherwise enrichments to UC-32/44/54/55 and explicit **page-model / projection design notes** recorded in findings for `SHARD-WP-0002` T12/T16. - `research/README.md` and `SCOPE.md` updated; each dive committed + state-hub-synced. - **After the batch:** produce a short synthesis — *"the computational page model"* — consolidating literate-programming projection, notebook computed-output provenance, and moldable multi-view, with a recommendation on whether shard-wiki needs an **executable/ computational content capability** (and how it stays mechanism-over-policy + capability- gated + degradable to a static snapshot). ## Suggested task order Conceptual keystones first: **T1 Literate Programming → T3 Jupyter → T7 Glamorous Toolkit**, then **T2 Mathematica → T6 Squeak (+ T8 Pharo)** for lineage, then the live/ visual REPLs **T4 Processing → T5 Strudel**. Close with the "computational page model" synthesis.