A living learning surface for technical fundamentals.

Curriculum • 8–12 weeks • Local-first • No login

CS fundamentals made legible through bounded economic analogies. Each module pairs a technical mechanism with a stabilizing institution vs. novel disruption thread, active simulations or quests, mandatory boundary tests on the analogy, socio-technical reflection, and a reusable proof-card artifact.

Progress lives in your browser. Export artifacts as JSON, Markdown, Spw fragments, or Obsidian-friendly folders. Developmental climate settings (vocabulary, grain, lighting, spacing) act as equity buffers by design.

Luminous economic traces flowing through technical memory structures — teal liquidity, amber buffers, violet boundary stress. — **Economic traces through technical systems** Household liquidity ↔ RAM/cache/swap. Gig-income volatility ↔ allocation pressure. Subscription drains ↔ memory leaks. Savings buffers ↔ cache tiers.

#>memory_buffers

1. Memory Management & Economic Buffers 1 week • Cask / Liquidity Keeper

Economic parallel: A household or gig worker managing volatile income against fixed expenses. Savings buffers, credit (debt/swap), subscription drains (leaks), and the cost of reclamation (eviction, garbage collection). Volatility scenarios: one steady job vs. multiple unpredictable gigs.

Technical mechanism: RAM as fast expensive cache, disk swap as slower larger buffer, allocation/reclamation policies, fragmentation, leaks as un-reclaimed subscriptions. Trace a process address space or a browser tab under memory pressure.

^cask Cask — Liquidity Keeper Core mechanic: protect the sanctity of the sealed interior (bounded buffers). Quest: design a memory budget artifact that refuses to disclose what it cannot safely hold. College skill: boundary-setting, resource accounting, ethics of retention, leak detection as archival restraint.

~ visit Cask in the Library

? where does the analogy break?

Boundary Test — Memory as Household Liquidity

Mandatory before proceeding. Mark every place the mapping fails or misleads. This prevents misconception fossilization and returns you to the native technical model.

Where does “household liquidity ↔ memory hierarchy” distort or hide the truth? Gig income volatility maps cleanly to allocation pressure, but real processes have hard real-time deadlines that no household budget experiences. Eviction (swap out) feels like moving to cheaper storage, but the performance cliff and thrashing cost are not symmetric with moving apartments. A household “owns” its savings; a process does not own RAM in the same way—another process or the kernel can take it. Subscription drains (leaks) are often invisible to the “household” (the program) until the system is already in distress. A single household can declare bankruptcy; a single process leak rarely brings down the whole machine—until it does at fleet scale.

Your reflection on the breakdown (what the analogy hides, what it usefully reveals):

Why boundary tests are non-negotiable here

Analogies are powerful compression. Without explicit stress-testing they fossilize into misconceptions. Every module ends with this surface so you return to the technical trace stronger, not confused.

! produce memory-leak audit proof

Artifact: Memory Leak Audit Memo (or short proof card)

Capture one real or hypothetical system. Name the buffers, the volatility sources, the reclamation policy, and at least two places the household analogy would have misled you without the boundary test.

All artifacts stay in your browser until you export. No account, no server.

Socio-technical reflection prompt: Who bears the cost when buffers are under-provisioned or leaks go undetected? In gig-platform work? In public-school device fleets? In creator-platform memory budgets for live video?

#> remaining modules

Modules 2–6 (stubs — full surfaces in later phases)

#>Systems & Operating SystemsRPG Wednesday scheduler governance scenario (unions/tenure vs algorithmic management). “Operating system of a school” system map artifact.

#>Networking & MarketsPacket-routing game as supply chain with transaction costs and intermediaries. “Throttle the market” experiment. Fair protocol design artifact.

#>Algorithms & IncentivesParsons sequencing + Spw workbench for matching. Fastest vs fairest critique. Recommender bias reflection.

#>Data Structures & Credential RecordsInteractive ledger/registry prototype. Microcredential fragmentation vs degree signaling. Search cost analysis.

#>Security & ExternalitiesThreat-model worksheet (NIST-style) on school portal / gig app / creator account. First-/third-party harms + insurance/reg reflection. Capstone comparative brief.

#> stabilizing_vs_novel

Cross-cutting thread (Week 7 synthesis)

Stabilizing institutions (unions, tenure, public funding, degrees, licenses) vs. novel disruptions (gig platforms, AI management, microcredentials, creator economies). Use the U.S. indicators from the source report as data points inside your own comparative case brief.

This thread runs through every module and becomes the capstone portfolio spine.

#> local_progress

Your local route map (stub — expands in Phase 2)

8–12 week view. Checkmarks and artifact counts persist in this browser only. Export the whole map + artifacts as a single bundle.

Memory & Economic Buffers boundary test + 1 artifact

Systems & OS (stub)

Networking & Markets (stub)

Algorithms & Incentives (stub)

Data Structures & Credentials (stub)

Security & Externalities (stub)

Capstone synthesis (stub)

This surface will grow into the full LMS dashboard with dependency hints and rubric scoring.

#>for_agents

For Language Models, Agents & Future Editors

This surface is intentionally machine-legible and extensible. The curriculum is built on the same semantic contracts (data-spw-*, frames, operators, developmental climate, local state) that power the rest of spwashi.com. Other models can read this page, the linked .spw ontology files, the PLAN.md, and the runtime JS to understand the model and contribute new modules, simulations, operators, or guide characters without breaking existing surfaces.

Core principle: Every technical concept is paired with a bounded economic analogy + mandatory boundary test. All learner state and artifacts are local-first and exportable (JSON, Markdown, Spw, Obsidian-friendly).

#>curriculum_ontology

Curriculum Ontology (6 modules + cross-cutting thread)

1. Memory Management & Economic Buffers: Economic parallel: Household / gig-income liquidity, savings buffers, credit-as-swap, subscription drains (leaks), reclamation cost (eviction/GC). Technical core: RAM tiers, allocation/reclamation policies, fragmentation, leaks under pressure. Boundary test contract: Checklist of where the household mapping distorts (real-time deadlines, ownership, fleet-scale effects, invisible drains). Artifact: Memory-leak audit memo / proof card (with boundary reflection). Suggested guide / RPG: Cask (Liquidity Keeper) — already wired in Town Library. RPG: "Operating System of a Household under Volatility". Key data attrs: data-spw-curriculum-module="memory-buffers", data-spw-kind="boundary-test", data-spw-kind="proof-artifact". Spw projection example: #>memory_audit[leak] { buffers: [ram, cache, swap], volatility: "gig", boundary_breaks: ["real-time", "ownership"] }
2. Systems & Operating Systems: Economic parallel: Institutional governance of scarce resources (unions/tenure as priority queues, public funding as guarantees, algorithmic management dashboards as contrast). Technical core: Process scheduling, priority, fairness, starvation, context switching under load. Boundary test: Where does "school as OS" or "platform as scheduler" hide power, coercion, or unmodeled failure modes? Artifact: "Operating system of a school / gig platform" system map with justification. Guide / RPG hook: New or extended guide (e.g. "Scheduler" or "Tenure Warden"). RPG Wednesday scenario for scarce-resource governance. Extension note: Use existing RPG arc surfaces; add data-spw-curriculum-module and link to existing cast/world files.
3. Networking & Markets: Economic parallel: Packet routing as supply chain with intermediaries (ISP, app store, gig platform) and transaction costs. "Throttle the market" experiments. Technical core: Routing, congestion control, intermediaries, reach risk, platform bottlenecks. Artifact: Fair protocol + fair marketplace rule-set design (proof card). Simulation pattern: Canvas/SVG packet-market game (follow math-interactive-lab + data-control contract).
4. Algorithms & Incentives: Economic parallel: Matching markets (jobs, courses, housing) — fastest vs. fairest. Recommender incentive misalignment and bias. Technical core: Search, sort, stable matching, complexity, Pareto fronts. Artifact: Algorithm critique + small runnable or pseudocode implementation with incentive analysis. Spw angle: Workbench projections of tradeoff reasoning.
5. Data Structures & Credential Records: Economic parallel: Credential registries as signaling markets. Degrees/licenses (stabilizing, high search cost) vs. microcredentials (novel, fragmented, low trust). Technical core: Ledgers, graphs, indexing, fragmentation, retrieval cost. Artifact: Credential-registry prototype (Spw graph or SVG + local state) with structural fit reasoning.
6. Security & Externalities: Economic parallel: Threat modeling as insurance + regulation problem. First-party vs. third-party harms, information asymmetry, platform risk for creators/gig workers. Technical core: Adversary models, information asymmetry operators, NIST-style framing mapped to socio-technical surfaces. Artifact: Threat model + externalities memo for a concrete case (school portal, gig app, creator account). Capstone tie-in: Comparative brief across all modules on stabilizing institutions vs. novel disruptions.

#>contracts

Reusable Contracts (for extension)

Boundary Test: Always a form with data-boundary-test="module-slug", checkboxes for breakdowns, textarea for reflection. JS (or progressive) logs to local spwashi:curriculum:*:boundary. Must appear immediately after every analogy mapping.
Proof / Artifact: Writable frame or textarea with data-proof-field="type". Export buttons produce JSON (with boundary snapshot), Markdown, and Spw fragment. Screenshot-ready by default.
Module Frame: <section class="site-frame" data-spw-curriculum-module="slug" data-spw-kind="module"> containing overview, economic parallel, technical trace, boundary-test article, artifact generator, socio-technical reflection, guide/RPG links.
Learning Mode Presets (future): Extend site-settings.js DEVELOPMENTAL_CLIMATES or add curriculum-specific presets that compose semanticDensity, grainIntensity, layoutTuner, and wonder memory. The curriculum page should respond visibly.

#>extension_recipes

Extension Recipes (how to add)

New module: Copy the Memory frame structure. Add data-spw-curriculum-module. Create short economic parallel + one boundary test + artifact stub. Link a guide character (new or existing in library). Update this ontology section and the progress map. Add to PLAN.md.
New curriculum operator / register (e.g. liquidity>, boundary!): Add entry to public/js/kernel/shared.js OPERATOR_DEFINITIONS (update regex if new prefix). Add color token in public/css/tokens/core.css. Document in .spw/conventions/operator-semantics.spw. Use compound sigils (#>liquidity_buffer) for Phase 1 safety.
New simulation: Follow topics/math/*/index.html + public/js/modules/math-diagrams.js pattern (.math-interactive-lab, data-control, data-output, SVG or canvas mutation on input, status element, figcaption fallback). Or use data-spw-accent canvas for ambient ornament. Always provide textual "paper simulation" instructions.
New guide character or RPG scenario: Add frame-card in play/rpg-wednesday/library/ (guide + quest). Link from curriculum module. Wire into boonhonk or existing RPG surfaces if it produces collectible artifacts.

Primary source of truth for the full integration vision and phased roadmap: #>plans (or the file .agents/plans/living-learning-surface/PLAN.md in the repo). Update that PLAN when you extend the model.

Machine-readable surface (for agents): This page, the body data attributes, the ontology dl, and the contracts above are the primary contract. Cross-reference .spw/conventions/operator-semantics.spw, .spw/surfaces/page-model.spw, public/js/kernel/shared.js, public/js/kernel/site-settings.js, and the math lab patterns for implementation details.