Knowledge Schema
How do you gain knowledge about a new domain fast enough to build in it?
A knowledge schema maps unfamiliar territory against territory you already own. The known structure becomes the Rosetta Stone. You stop learning from scratch and start translating — then you only need to deeply learn the gaps where translation fails.
The Procedure
Any agent or person can follow this to rapidly acquire a new domain.
1. Pick the Anchor
Choose the domain you know deepest. It becomes column 1 of every comparison table. The anchor must be experiential — something you built with, not something you read about.
| Good Anchor | Bad Anchor |
|---|---|
| Years of EVM/Solidity development | Read a blog post about Ethereum |
| Built production P&ID systems | Saw a factory diagram once |
| Shipped React apps | Watched a React tutorial |
2. Map Concepts
For each concept in the new domain, find the equivalent in the anchor. Build the table.
| Anchor (Known) | Target (New) | Gap Type |
|---|---|---|
| Concept A | Equivalent A | Direct mapping |
| Concept B | Different B | Different model |
| Concept C | Nothing needed | Absence — target removes the need |
| No equivalent | Concept D | Genuinely new |
3. Classify the Gaps
Four gap types. Each requires a different learning strategy.
| Gap Type | What It Means | Learning Strategy |
|---|---|---|
| Direct mapping | Same concept, different syntax | Fast — learn the syntax, skip the theory |
| Different model | Same problem, different solution | Medium — understand why the new model exists |
| Absence | Anchor has it, target doesn't need it | Unlearn — the old concept is a liability here |
| Genuinely new | No anchor equivalent | Deep — this is where real learning happens |
4. Prioritize the Genuinely New
Everything that maps directly is vocabulary swap. You pick it up by doing. Spend your time on the "genuinely new" and "different model" rows — these are where the new domain's power lives and where your anchor can mislead you.
5. Build With It
Schema without application is theory. Build something small that forces you through each gap type. The build reveals which mappings were wrong.
6. Update the Schema
After building, go back and correct the table. Some "direct mappings" turn out to be "different models" under pressure. Some "genuinely new" concepts turn out to be familiar patterns in disguise. The corrected table is the legacy for the next agent.
Worked Examples
EVM → Move (Smart Contracts)
EVM as reference schema for understanding Sui/Move. Full comparison at Smart Contract Standards.
| EVM (Known) | Move (New) | Gap Type |
|---|---|---|
| Global state | Objects with ownership | Different model — no shared mutable state |
msg.sender | tx_context::sender() + capabilities | Different model — compiler-enforced, not convention |
| ERC-20 interface | sui::coin module | Direct mapping |
onlyOwner modifier | Capability object (AdminCap) | Different model — no runtime modifiers |
OpenZeppelin ReentrancyGuard | Nothing needed | Absence — Move makes re-entrancy impossible |
OpenZeppelin Ownable | two_step_transfer wrapper | Direct mapping — choreography on top of capabilities |
| Proxy upgrade pattern | sui client upgrade with policy | Different model — protocol-level, not pattern-level |
| No equivalent | PTBs (1,024 atomic ops) | Genuinely new — no EVM equivalent at this scale |
| No equivalent | zkLogin (OAuth → address) | Genuinely new — protocol-level account abstraction |
| No equivalent | Linear types (move only, never copy) | Genuinely new — entire vulnerability classes vanish |
The "genuinely new" rows — PTBs, zkLogin, linear types — are where deep learning is required. Everything else accelerates through translation.
P&ID → A&ID (Agent Nomenclature)
Process engineering as reference schema for Agent & Instrument Diagrams.
| P&ID (Known) | A&ID (New) | Gap Type |
|---|---|---|
| Process equipment | Agents (HA, DA, PA, OA) | Direct mapping |
| Instruments (sensors, valves) | Instruments (tokens, identity, incentives) | Direct mapping |
| Pipelines | Protocols (data flows, value flows) | Direct mapping |
| Control loops | Feedback loops (VVFL, tokenomics) | Direct mapping |
| ISA-5.1 symbol codes | A&ID symbol codes (DA-ST01) | Direct mapping |
| ANSI valve assemblies | Standard fittings (OpenZeppelin) | Direct mapping |
| No equivalent | Smart contracts as intelligent hyperlinks | Genuinely new |
| No equivalent | Verifiable settlement (on-chain proof) | Genuinely new |
P&ID → A&ID is almost entirely direct mapping. That's what makes it powerful — process engineers can read agent diagrams immediately. The genuinely new concepts (smart contracts, on-chain settlement) sit on top of a familiar structure.
The Lindy Dimension
The Lindy Effect applies to schemas: the longer a mapping survives real use, the more trustworthy it is. A direct mapping that has worked for years (P&ID symbols → A&ID codes) is more reliable than one created yesterday.
Standard fittings demonstrate this. OpenZeppelin's EVM patterns are Lindy — battle-tested since 2016. When ported to Move, the patterns transfer even though the implementation is new. The schema (access control, safe math, time locks) survives across platforms because the underlying problems are the same.
The Matrix
Jobs × Attributes = Visibility.
| Job | Artifact | Owner | Status |
|---|---|---|---|
| ? | ? | ? | ? |
Each row is a job. Each column is what you need to know. Empty cells are blind spots. The reference schema procedure above is how you fill the cells fast — by translating from a domain where you already filled them.
Applied:
- Marketing Protocols — 25 jobs × 8 attributes
- Jobs To Be Done — What customers hire products to do
- Smart Contract Standards — EVM × Move × SVM comparison tables
Context
- Matrix Thinking — Making invisible visible
- Knowledge Stack — Primitives → Protocols → Standards → Platform
- Smart Contract Standards — Worked example: EVM as reference schema for Move
- A&ID Template — Worked example: P&ID as reference schema for agent nomenclature
- Naming Standards — Consistent taxonomy makes schemas navigable
- Data Footprint — The data model IS the knowledge schema for any domain
- Tight Five — The schema that organises schemas
- Hacker Laws — Lindy Effect: survival validates the schema
- Jobs To Be Done — What customers hire products to do
- Work Charts — Human/AI capability mapping
Links
- Schema Development — Psychology of knowledge schemas
- Diátaxis — Four documentation types serve four learning needs
Questions
How do you know when a reference schema is helping you learn — versus trapping you in the old model's assumptions?
- Which "genuinely new" concept in your current learning target would be invisible if you only translated from your anchor?
- When the anchor has a concept the target deliberately omits (like
ReentrancyGuardin Move), is the absence a feature or a blind spot you'll pay for later? - What's the minimum number of "genuinely new" rows that justify learning a new domain — versus staying in the anchor domain and waiting for it to catch up?
- If an agent follows this procedure with a different anchor, do they arrive at the same schema — or does the anchor determine what you see?