shard-wiki/research/260614-computational-page-model-synthesis/findings.md

The computational page model — synthesis (SHARD-WP-0004)

Date: 2026-06-15 · Source: SHARD-WP-0004 (post-batch synthesis, T1–T8) · Kind: synthesis (no new external research) reading the eight computational/interactive-knowledge dives across each other.

What this is

The acceptance-criteria synthesis for SHARD-WP-0004. The batch asked one carried question: can a shard-wiki page be a live computational artifact — a source woven/evaluated into rendered forms — and if so, how do projection, transclusion, provenance, and the adapter contract treat the source, the environment, and the computed output? This memo answers it by distilling the eight dives into one model: the source / derivation / projection view of computational content, anchored on two axes, plus a recommendation on whether shard-wiki needs an executable-content capability.

Dives consolidated: T1 literate programming (WEB/weave/tangle), T2 Mathematica, T3 Jupyter, T4 Processing/p5.js, T5 Strudel, T6 Squeak, T7 Glamorous Toolkit, T8 Pharo. Catalog yield: UC-83 (literate one-source-many-projections), UC-84 (notebook with computed-output provenance); the other six are enrichment/boundary dives (UC-54/55/47/48 + the projection model).

1. The one finding: source is canonical, everything rendered is a projection

Every system in the batch, however "live," externalizes to a canonical artifact and treats the rendered/computed form as derived:

System	Canonical (attach this)	Derived (a projection)
Literate (WEB)	the WEB/.nw/.org source	woven docs and tangled code
Mathematica	the .nb (a Wolfram expression)	cached Output cells; CDF; Dynamic widgets
Jupyter	.ipynb source (ideally paired text)	embedded outputs; nbconvert/nbviewer renders
Processing	the sketch source	the view-time canvas render
Strudel	the pattern source	the live audio performance / a recording
GT / Lepiter	git-versionable page/Tonel files	moldable gtViews; live snippet results
Squeak/Pharo	exported files (Tonel/git)	the live image / running objects

This is the same principle shard-wiki already holds (files-canonical, index/render derived — ikiwiki UC-79, Logseq UC-62, nbstripout). The computational batch did not break it; it stress-tested it to the live extreme and it held. The image (Squeak/Pharo) is the only would-be exception, and it is a boundary, not a counterexample: an image is not a store.

2. Two axes the contract must add

The batch refines the projection model (SHARD-WP-0002 T16) with two orthogonal axes:

2.1 Projection kind: replication vs derivation

• Replication-projection (the existing default): a lazy cache/copy of remote content (Obsidian/Notion mirrors, UC-53/57).
• Derivation-projection (new, from T1): a transform/compile/weave/evaluate of a source into rendered forms — regenerable, may delegate to the source's tool, degrades to a captured snapshot when the tool is absent. Covers weave/tangle, nbconvert, CDF, sketch render, audio recording, gtView.

Sub-facets of derivation (from T4): materialization timing = ahead-of-time (CDF, nbconvert, static HTML) vs view-time (Processing/Strudel); multiplicity = one output (UC-79) vs N co-equal projections (UC-83 weave+tangle; UC-47/48/54 moldable views).

2.2 Liveness: the live↔snapshot axis (from T6, bounded by T5)

Every derived view sits on a spectrum, and the more live the source, the more its static form is a clearly-marked degrading snapshot:

static source ── captured output ── live-over-files ── view-time one-shot ── continuous/
(literate)       (notebook UC-84)    (GT/Lepiter)        (Processing)         interactive
                                                                              ── irreducibly
                                                                                 live/temporal
                                                                                 (Strudel: source
                                                                                  + recording only)

Honesty rule (union-without-erasure): a computed/live view must always declare what it is — "captured at run N, environment unguaranteed" (UC-84), "one performance, time T, source rev R" (UC-83/Strudel), "live render needs the runtime." Never present a snapshot as live or a static page as capturing a live artifact.

3. The computational page-model shapes (T12)

The batch adds these page shapes (beyond prose / typed records / query-defined / inline- embedded objects / typed-graph already catalogued):

1. One-source-many-projections (UC-83) — a source whose presented forms are co-equal derivations (docs + code), each with output→source provenance; named-chunk transclusion assembles fragments by name at derivation time (UC-32/44).
2. Notebook (UC-84) — ordered/nestable cells (Mathematica adds the outline tree) where code cells own embedded computed outputs (the derived output is stored inside the source) with weak execution provenance; outputs may be MIME blobs or structured re-evaluable values (Mathematica) — a new point on the content-opacity spectrum.
3. Program-as-page (Processing) — canonical content = source text, presentation = an executable render with no cached output; non-Markdown executable content.
4. Live/temporal/generative content (Strudel) — source canonical, render irreducibly live; static = source + a marked recording.

All four reduce to (source, derivation rule, projection with provenance + liveness) — one model, four positions.

4. Provenance & reproducibility (the honest weakness)

Computed output provenance is real but fragile everywhere: Jupyter/Mathematica execution_count/In-Out can be out-of-order; environment/versions/data are not captured; Strudel/Processing may be non-deterministic. Implication for the contract: treat a computed output as a snapshot with declared, incomplete provenance (run id, source rev, timestamp; environment "unguaranteed"), reusing one snapshot-provenance machinery across notebooks, recordings, and renders (UC-84 is the template). This is consistent with shard-wiki's existing "surface freshness/completeness, never imply more than you have" (Oddmuse partial-history UC-82).

5. The recommendation

Does shard-wiki need an executable/computational content capability? — Yes, but only as recognition + projection + capability-gating, never as an execution engine.

1. Adopt the source/derivation/projection model (no execution required). shard-wiki recognizes computational content types (literate source, notebook, sketch, pattern), attaches the canonical source, and presents derived forms as projections with provenance + liveness markers. This alone delivers UC-83/UC-84 and the enrichment of UC-54/55 — and needs no kernel, no sandbox, no runtime.
2. Make execution a capability, off by default. "Drive a derivation" (run tangle/weave, re-execute a notebook, render a sketch, evaluate a pattern in the viewer) is a gated capability with a trust/sandbox sub-concern (T11). Absent it, degrade to the captured snapshot / static render / recording — the graceful-degradation rule, which the batch shows always has an honest fallback (source is tiny and diffable everywhere).
3. One projection model, two axes (T16): projection-kind (replication vs derivation; with timing + multiplicity facets) × liveness (live↔snapshot). The moldable view registry (T7) is the unifying structure — an open, type-keyed set of co-equal projections, none canonical-by-fact (display-canonical is policy).
4. One snapshot-provenance record reused for notebook outputs, renders, and recordings (run id, source rev, timestamp, environment "unguaranteed").
5. Hard boundaries (design-bugs if violated): never host a kernel/runtime as the store; image-is-not-a-store (attach exported files); never present a derivation without output→source provenance; never imply a static view captures a live artifact.

Net: computational content is in scope as a page-model + projection concern, out of scope as an execution platform — exactly the mechanism-over-policy, capability-aware, degradable posture INTENT already mandates. No INTENT amendment is required; this extends the page model and projection model within existing constraints.

6. Fold into SHARD-WP-0002

• T12 (page model): add the four computational shapes (§3); allow nestable cells and structured re-evaluable outputs; "derived output may live inside the source" (notebook).
• T16 (projection): the two-axis model (§2) + the moldable view registry (§3/T7); materialization-timing, multiplicity, continuity, and the live↔snapshot far end as explicit projection metadata.
• T11 (capabilities): "derive/execute/render/evaluate" as gated capabilities with trust/ sandbox; default off → snapshot.
• T15 (fidelity): non-Markdown executable/computed content; lossy renders; the structured-re-evaluable-value point on the content-opacity spectrum.
• T13 (history): paired-text (Jupytext) / cell-aware (nbdime) strategies for embedded- output documents; outputs-as-derived (nbstripout ethos).
• T14 (binding): image-is-not-a-store boundary (export→files only).

7. Open questions (escalated)

1. Is liveness (and "irreducibly live / no faithful static form") an explicit first-class metadata flag on every projection, so the union renders the honest fallback automatically? (T5/T6 far-end question.)
2. Does shard-wiki ever drive a derivation (sandboxed), or strictly attach + present snapshots? (Recurs UC-56/UC-83/UC-84/T4/T5 — a single capability/trust policy decision.)
3. Is a computed output's structured re-evaluable value (Mathematica/Wolfram) modeled as a typed value or stored opaquely with provenance? (UC-55 open-Q #10; UC-84 Q3.)
4. Should UC-83 and UC-84 eventually merge as two positions of one "source + derivations" shape, or stay distinct? (Kept distinct: UC-84's defining trait is output embedded in source with weak provenance; UC-83's is N co-equal external derivations.)

8. Sources

The eight SHARD-WP-0004 dives: research/260614-{literate-programming,mathematica,jupyter, processing,strudel,squeak-pharo,glamorous-toolkit}-deep-dive/. Prior projection/structure anchors: research/260614-{ikiwiki,logseq,zigzag}-deep-dive/, research/260614-shard-spectrum-synthesis/.

9. Traceability

No new UC (consolidation). Consolidates UC-83, UC-84 and enrichments to UC-32, UC-44, UC-47, UC-48, UC-54, UC-55, UC-79, UC-37, UC-35. Feeds SHARD-WP-0002 T11/T12/T13/T14/T15/ T16 (see §6). Recommendation: computational content is in scope as page-model + projection mechanism, out of scope as an execution platform; no INTENT amendment required.