#>knowledge_bases topic hub

Knowledge Bases

This hub is for tools and methods that treat notes as working memory rather than as a single final document. The useful distinction is not just "editor" versus "not editor." It is whether a system can preserve a relation across retrieval, revision, rendering, and handoff—and show enough evidence that another reader can verify the result.

Spw is the knowledge base I actually keep: readable source, named stems, and routes that project the same notes into HTML. Other local-first writing tools exist; they are neighbors, not the substrate this site is built from.

This site is itself a public knowledge surface: routes carry data-spw-* semantics, the runtime can snapshot topical payloads for handoff, and Spw stays readable beside HTML. The goal is a compact receipt—source, relation, state change, witness—not a transcript of every step. Compare private notes with how this field guide exposes inspectable contracts.

^value_model knowledge base value

Knowledge Base Value Model

Knowledge bases matter when they reduce rediscovery cost. A good one turns scattered work into durable recall, gives future collaborators a route into the material, and keeps private notes close enough to become public artifacts when the time is right.

Retrieval

Search, backlinks, tags, and stable file names help a thought survive beyond the week it was written.

Publication

Notes become useful outside the notebook when they can project into guides, service pages, books, documentation, or route maps.

Codebase curriculum

The same habit applies to software: events, page data, component rationales, and architecture notes should make a codebase easier to learn.

One piece of work, four ways to find it

A folder of topics, a lesson sequence, a web of links, and a record of an experiment answer different questions. For the tiny-show cue sheet, keep one version of the work and offer several routes into it.

Subject shelf — “what is this about?”: File the sheet under performance, logic, or programming. Tags can name several subjects without copying the file. Sharing a category does not mean one subject must be learned first.
Project path — “what do I do next?”: Write the rule, represent the cues, check the decisions, then rehearse. A step depends on another only when it uses that step's result. Someone with a rule already written can begin at the checks.
Relationship map — “why is this link here?”: Label the connection in a sentence: “this function implements the rule,” “this test challenges it,” or “this rehearsal revealed a missing instruction.” A backlink records a connection; the sentence supplies its meaning.
Evidence record — “what happened, under which conditions?”: Keep the rule version, inputs, expected result, observed result, and limits. “The ribbon was missing” belongs to one rehearsal; “all ribbons are unavailable” would be a different and unsupported claim.

Make the next search succeed

Name the note for the question it answers: Quiet show — which cues may play?
Save the cue-sheet template with your rule, one failure, and what you changed. Leave unobserved results blank.
Link the exact test example or other source you used. Add one sentence about what you adapted.
Return later using only the title and links. If the note cannot tell you how to repeat the check, add the missing assumption.

Keep: a record someone can find, rerun, and revise. Markdown can carry it as a plain file; version control can preserve how it changed. Trying the method in another setting tests whether the knowledge travels.

?utility why this matters here

What this page should help answer

Use this route when the question is practical: what makes a tool a knowledge base, which kinds of structure matter, and where the category overlaps with writing, research, and publication. The point is not generic productivity advice. It is to understand which properties actually change author workflow. Returning learners can treat this as the junction point between note-taking, Markdown, and publication surfaces.

Move in when

you want to compare note systems by the work they make easier to return to.

Keep in view

local files, links, tags, metadata, search, and the shape of the later export.

Can become

an essay workflow, a book outline, documentation, or a worldbuilding surface with better recall.

#>spw_as_kb working memory

Spw as a knowledge base

A knowledge base is useful when a later reader — human or model — can find a claim, follow a link, and tell source from projection. Spw is that layer here: .spw files and route HTML stay dual-readable; operators and topics are retrieval handles; the atlas and the literal parser show what the marks actually parse.

Earlier passes concentrated on the application that held the notes. The durable lessons were narrower and more useful: keep the files, put rare behavior at the edge, teach agents an open format, and let a reader leave without surrendering the corpus. The current work begins one layer deeper: state the semantic relation before asking software to transform it.

The infrastructure a knowledge base needs in order to stay honest is now visible here: a page template so routes share a shell, a browser parser that is the same kernel as the workbench, operator names aligned with that parser, a module catalog that can unmount as well as mount, and site search that can find a stem. Copy still has to earn its keep as a checkable claim, not as a plea to imagine more integrations.

What file-first tools taught

Agents get more useful when the corpus has a grammar they can be taught, and less trustworthy when they must invent structure inside a blob. Owned files, explicit links, and narrow extensions matter more than copying a particular vault interface.

What AI changes now

A language model can traverse named stems, propose a scene, or draft a weight table. It should not become the owner of the files. Human-readable source stays the trust surface; the model is a temporary reader whose work leaves a receipt, not a second memory silo.

Where attention moved

Attention is now on semantic identity, admissible transformations, and compact evidence. The honest question is whether a claim stays the same claim across its native shapes—and whether a crew can inspect the authorized result without replaying the whole search.

~authorable_tracks composition guide

Four authorable ways to keep meaning inspectable

A contribution becomes easier to share when its native shape, transformation rule, and witness are explicit. These four tracks are useful across games, publications, software, and learning systems because each can produce a compact receipt without collapsing into one universal format.

Track A — deterministic renderings

A committed seed selects traits, then a pure function renders layered SVG. The contract is render(traits) → SVG with no hidden randomness, so another reader can re-derive the same image. That is closer to a craft constraint than to a style prompt. Continue in the SVG experiments.

Track B — readable scene files

A scene can remain handwritten text—rooms, conditions, effects, exits, and a declared win—while an executor checks the same marks later. The source stays authorable without runtime expertise. The compact pattern lives in the scene receipt below.

Track C — seasonal tables

Generated biomes, ingredients, or encounter lists can live in versioned tables. If an addition re-buckets every seed, expansion belongs at a named season boundary rather than inside a silent edit. The table version is part of the result.

Hand art, separately

Procedural assets should stay seed-derived. Hand-drawn or generated stills are another layer with their own provenance, crop, palette, and review path. A missing integration should not erase the asset’s native identity. Continue in the folios or depiction bench.

The tracks become consequential when a crew can share the same seed, scene, and table version. A stranger should be able to re-run the authorized transformation and compare the result. lore.land is where long-form scenes can become public without pretending source notes and reading surfaces are the same room.

A .spw sidecar can hold curriculum beside code without becoming the executable scene grammar. Canon, index, and mount remain readable to a crew; the parser can challenge whether their references resolve. Different consumers may project the notes differently while preserving the same relation.

$versioned_holdings holdings

Identity, boundary, ledger

Value gets vague when identity, supply boundary, and history collapse into one number. These are three separate holdings a crew can share. Other systems can reuse the policy without copying the surrounding world.

Seed

The same committed seed must render the same thing twice. That is identity you can re-run, closer to a serial number than to a vibe.

Season

Appending mid-season re-buckets every existing seed. Expansion is a boundary, not a silent mint. Supply policy you can see.

Table version

The ledger is the versioned table. A stranger should be able to name which table they played.

Keep the three in relation. Collapsing them into one score hides the mechanism. Five boonhonk voices work the same way: you do not spend all at once. Count the dummy, then return to a region.

Any system that needs “the same object stays the same across a season” can use these primitives. Color and emphasis change how a holding is seen; they do not create its identity.

>hypermedia projection

An open medium

Notes become a medium when a reader can re-read the surface, follow a capability this page offered, and check a receipt. The fuller account, including how Spw marks those moves, is the hypermedia topic.

(scene_receipt cheat-sheet

Scene marks and executable prose

A compact scene file can keep prose, conditions, effects, and exits in one readable shape. An executor may compile and re-run those marks, but the authorable source remains the receipt. This is a neighboring scene pattern, not Spw syntax: a site (scene) may project onto $scene without claiming the two file formats are identical.

---
id: salt-vault
title: The Salt Vault
tags: [descent]
---
=== entrance
The vault door hangs open.
* [Force it] { strength >= 5 }
  ~ noise += 1
  -> hall
* [Pick the lock] { gold >= "$price" }
  ~ gold -= 10
  -> hall
=== hall
* [Take the crown] { hands < 1 }
  ~ hands = 1
  -> END

Rooms

=== name is a room. Prose under it is what the runner sees. -> hall or -> END is the exit.

Gates

{ strength >= 5 } is a condition. var op value, membership, !, AND (&& or comma), OR (||). A $ on the right is another slot, not Spw substrate.

Effects

~ gold -= 10 mutates a slot. Assign, add, subtract, or call("name", args). Budget is sixteen slots.

Win and publish

A declared win condition is what a verifier re-executes. Until the publish path accepts and checks the same source, a .scene file is a draft rather than an authorized board entry.

~refs starting references

Related routes

#>markdown_knowledge_bases #>text_editing #>note_taking_history #>text_editor_history #>curricular_codebase #>systems_offer #>spw_operator_atlas #>authorable_tracks (scene_receipt ~consequence_arcs