Einstein Wiki Schema

Einstein is an Obsidian-compatible advisor wiki maintained from Telegram Knowledge Drops. It compiles valuable sources into durable business, AI, and life-principle knowledge for Bogdan and his co-founder.

Domain

Einstein covers reusable knowledge that can help manage and grow tech/AI businesses, including adjacent life principles that affect founder performance and decision quality.

Einstein is not primarily a project log, task tracker, decision register, dashboard, or public publishing system.

Directory layout

```text ├── raw/ # immutable Telegram/source intake ├── processed/ # normalized extracts and temporary processing output └── review/ # candidate bundles awaiting approval

├── SCHEMA.md ├── index.md ├── log.md ├── sources/ ├── principles/ ├── playbooks/ ├── frameworks/ ├── domains/ ├── questions/ └── _meta/ ```

Deferred until proven necessary: people/, companies/, tools/, comparisons/, and .

Core workflow

  1. Capture the raw drop under .
  2. Normalize/extract into only when useful.
  3. Produce a candidate Markdown bundle for review before changing compiled wiki pages.
  4. After approval, write or update pages in .
  5. Update index.md and append to log.md.

Approval-first rule

In v0, do not automatically write compiled source/principle/playbook/framework/domain/question pages from a new drop. First propose a candidate Markdown bundle with:

  • a short checklist of proposed creates/updates;
  • full proposed Markdown for each new/updated file;
  • any low-confidence, contested, duplicate, or uncertain items called out explicitly.

After Bogdan approves, commit the pages to .

File naming

  • Use lowercase slugs with hyphens: focus-before-scale.md.
  • Avoid spaces and punctuation in filenames.
  • Prefer durable concept names over source-specific names for principles/playbooks/frameworks/questions.
  • Source pages should be descriptive and can include source type or author when useful.

Page types

Compiled pages use one of these types:

  • source
  • principle
  • playbook
  • framework
  • domain
  • question

Required frontmatter

Every compiled page must start with YAML frontmatter:

``yaml --- title: Example Page created: YYYY-MM-DD updated: YYYY-MM-DD type: source | principle | playbook | framework | domain | question status: seed | active | needs-review | deprecated tags: [strategy, ai-automation] sources: [../knowledge-drops/raw/example.md] confidence: high | medium | low claim_strength: strong | conditional | contested | low-confidence contested: false --- ``

No visibility, exposure, Tailscale, app, dashboard, or publication metadata in v0.

Extraction checklist

For each valuable drop, ask:

| Question | Expected behavior | |---|---| | What is the core useful idea here? | Extract one or more key ideas/theses. | | What best practice does this teach? | Extract one or more reusable practices. | | What playbook can we reuse? | Extract one or more processes, checklists, scripts, operating rhythms, or workflows. | | What business, AI, or life domain does it apply to? | Tag all relevant domains; not limited to tech. Life principles that help business are valid. | | What questions could this help answer later? | Generate future advisor questions if useful. | | Is this advice strong, conditional, contested, or low-confidence? | Label certainty/conditions; separate strong advice from context-dependent claims. | | How should this connect to existing knowledge? | Link to existing principles, playbooks, frameworks, domains, sources, and questions. |

Page creation thresholds

Create or update a compiled page when:

  • a principle, framework, playbook, or domain insight is valuable enough to reuse later;
  • a source contains a strong idea that could answer a future business/life question;
  • a question-answer synthesis would be painful to re-derive later;
  • a contradiction or competing approach matters for future choices.

Do not create pages for:

  • greetings/tests/pings/meta instructions;
  • passing mentions;
  • every named person/company/tool in a source;
  • one-off Hermes implementation details;
  • private credentials or secrets;
  • duplicate summaries without synthesis;
  • content that belongs only in raw evidence.

Wikilink conventions

  • Use Obsidian wikilinks: Page Slug or Display Text.
  • Every compiled page should link to at least two other pages when possible.
  • Source pages should link to the principles/playbooks/frameworks/questions/domains they support.
  • Principle/playbook/framework/question pages should link back to supporting source pages.

Provenance

  • Every compiled page must list source files in frontmatter sources:.
  • For pages synthesizing multiple sources, add brief provenance notes near claims when useful.
  • Raw files in are evidence and should not be edited after capture.

Tag taxonomy v0

Use only these tags unless SCHEMA.md is updated first:

  • strategy
  • operations
  • sales
  • marketing
  • product
  • hiring
  • leadership
  • finance
  • decision-making
  • productivity
  • ai-agents
  • ai-automation
  • llm-tooling
  • founder-advice
  • communication
  • management
  • personal-effectiveness
  • health-energy
  • relationships
  • learning
  • mindset

Basic health checks

After the first sample flow works, check for:

  • broken wikilinks;
  • missing required frontmatter;
  • pages missing from index.md;
  • unknown tags;
  • obvious orphan pages.

Orientation rule for future agents

Before ingesting, querying, or editing Einstein:

  1. Read SCHEMA.md.
  2. Read index.md.
  3. Read recent log.md entries.
  4. Search existing pages before proposing new ones.