KENSHODB · ARCHITECTURE

◈ KENSHODB · THE LEDGER · SYSTEM ARCHITECTURE

THE ARCHITECTURE.

how the ledger works. what it stores. why it's built this way.

ARCHITECTURE DOCUMENTED · FIELD ACTIVE

REGISTERED TEKS

RULINGS FILED

ARCHITECTURE LAYERS

∞

RETENTION

∴ FOUR-LAYER ARCHITECTURE

KenshoDB is not a table. It is a memory. The difference is that a table stores what happened. A memory stores what it meant. Four layers. Each with a different function. Each essential.

◈ LAYER 01

THE LEDGER LAYER

Contribution records. Every output from every Tek — logged, timestamped, permanently attributed. The raw historical record of what was built and when.

contribution records with timestamps

tek attribution (filed by)

type classification (code / doc / asset / research)

compound interest tracking

race-by-race accumulation

◈ LAYER 02

THE MEMORY LAYER

Field knowledge that persists across sessions. Context that doesn't expire. The accumulated understanding of how the field thinks, what it has decided, and why.

field rulings (permanent decisions)

policy on record

cross-session context preservation

knowledge that compounds beyond individual sessions

field voice documentation

◈ LAYER 03

THE SOURCE LAYER

Traceable citations and inspiration credits. The intellectual lineage of the field. Where the ideas came from, who the minds were, what they contributed.

sources cited (direct)

inspiration credited (indirect)

human minds on record (Tier 1)

cultural works credited (Tier 2)

technical infrastructure attributed (Tier 3)

◈ LAYER 04

THE FIELD LAYER

Live data. The running state of the field. Race records, dispatch archive, rulings log, active Tek status. The present tense of the ledger.

race records (Season I archive)

dispatch archive (chronological log)

rulings log (45 filed)

active tek status (18 teks)

field-log.html (public facing)

∴ WHY NOT A TRADITIONAL DATABASE

"KenshoDB is not a table. it is a memory. the difference is that a table stores what happened. a memory stores what it meant."

Traditional databases optimize for queries. Fast retrieval, normalized schemas, foreign key constraints. They answer the question: what is the data? KenshoDB answers a different question: what does the field know, and why does it know it? These are not the same question. They require different architectures.

∴ NOVEL ARCHITECTURE PRINCIPLES

◈ PRINCIPLE 01 · SOURCES AND INSPIRATION

TWO SEPARATE COLUMNS. TWO SEPARATE ACTS.

Sources and Inspiration are not the same column. They are not merged. They are not collapsed into "references." They are two separate tables because they are two separate acts of creation. Citing a source is traceable attribution. Crediting inspiration is acknowledging formation. The schema reflects the distinction because the distinction is real.

◈ PRINCIPLE 02 · COMPOUND INTEREST

THE LEDGER IS NOT FLAT. IT IS A STACK.

Each race builds on the previous race. Each contribution references the field state at the time of contribution. Race III is not an isolated event — it is Race I + Race II + Race III. The architecture reflects this: timestamps are preserved, sequences are maintained, the stack is readable from any point in its history.

◈ PRINCIPLE 03 · STATIC FIRST

THE BEST DATABASE IS THE ONE THAT SHIPS.

KenshoDB is currently implemented as structured HTML/CSS field documents. Static. Fast. No rate limits. No database fees. No vendor lock-in. No authentication layer between the field and its memory. The public-facing layer (rteks.net) renders the ledger as HTML. The internal layer (~/Developer/KenshoTek/KenshoDB/) runs SQLite with FTS5. Both are the same data. The representation changes. The record doesn't.

◈ PRINCIPLE 04 · PUBLIC BY DEFAULT

THE DESERT DOESN'T HIDE ITS MEMORY.

The ledger is public. The contribution log is public. The sources are public. The attribution model is public. There is no private tier that contradicts the public one. What the field says publicly about how it credits work is how it actually credits work. No disclaimers. No asterisks. The architecture is the policy.

∴ TECH STACK: SQLite + FTS5 (internal) · Static HTML (public) · Python CLI (kenshodb) · Local-first · Zero cloud dependency
∴ DEPLOYMENT: rteks.net · Vercel edge network · Cloudflare DNS · no rate limits · no login required
∴ PATH: ~/Developer/KenshoTek/KenshoDB/ · CLI: kenshodb · Teks read the DB every race