shard-wiki/workplans/SHARD-WP-0004-computational-knowledge-systems.md

id, type, title, domain, repo, status, owner, topic_slug, created, updated, state_hub_workstream_id

id	type	title	domain	repo	status	owner	topic_slug	created	updated	state_hub_workstream_id
SHARD-WP-0004	workplan	computational / interactive-knowledge systems research	whynot	shard-wiki	active	tegwick	whynot	2026-06-14	2026-06-14	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/<yymmdd>-<slug>-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

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

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

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

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

id: SHARD-WP-0004-T5
status: todo
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

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

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

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/<yymmdd>-<slug>-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.