Book-as-context: designing complex architecture with AI through a book substrate

Problem

Tell Claude or Cursor "build order transfer from an e-commerce system to an ERP" — you get a naive file exchange over FTP and a report saying "done." Engineers laugh and conclude "AI can't handle architecture."

The root isn't the model. The model draws on the "average of the internet" — averaged code from open sources where production-grade integrations are rarer than tutorials. Without a domain knowledge base the agent doesn't know the right answer here is event-driven with delivery guarantees, idempotency, and data consistency across systems.

End-to-end example: store → ERP

Same class of task, two different outcomes.

Without substrate: "Build order transfer from e-commerce to ERP" → CSV, cron, FTP, "done."

With Tanenbaum wiki — real brief: integration 1C-Bitrix → Galaktika ERP → Creatio CRM. The agent walks a concept graph:

"ERP may be down for hours, orders must not be lost"
  → message-oriented middleware (MOM):
    persistent communication — queue holds message until delivered
    vs transient communication — receiver must accept right now
  → message queue systems — not email: delivery guarantees, logging, load balancing
  → AMQP: unsettled → settled → forgotten — three delivery commit steps
  → two-phase commit (2PC) — if two databases must update atomically

What actually came out

Excerpt from a real spec: agent with wiki substrate for 1C-Bitrix → Galaktika ERP → Creatio CRM.

Event source — Bitrix after order commit. Event is recorded via transactional outbox, transformed into a canonical model, and placed in a persistent broker. Adapters deliver asynchronously to ERP and CRM; cross-cutting state in an integration journal. Retries via idempotency, exponential backoff, and DLQ; order updates preserve causal ordering.

Logical diagram from §7.1:

[Bitrix store] --(Outbox/event)--> [Integration service]
                                      |
                    Canonicalization, validation, master data enrichment
                                      |
                         [Message broker (persistent queues)]
                         /                              \
            [Galaktika ERP adapter]            [Creatio CRM adapter]
                         \                              /
                          `--> [State journal / integration DB] <--'

ERP transport priority — file exchange is not the primary path:

SLO and resilience (§6.1)

Partial success ERP + CRM (§12.3)

Eventual consistency without automatic two-phase commit.

• Invariant: a successful write to a target system is never rolled back automatically.
• ERP accepted, CRM temporarily down → retry CRM with same idempotency key; leave ERP untouched.
• ERP accepted, CRM exhausted retries → partial success, event to DLQ, alert.
• ERP down → retry ERP; CRM not called until ERP succeeds first.

Channel security (§8)

• TLS 1.2+ on all channels; mTLS between integration components.
• Store webhook: HMAC or JWS + replay protection (nonce, 5–15 min window).
• Rate limiting, message size limits; queue overflow → DLQ + alert.

Traceability: wiki → spec (Appendix A)

§1.2 references wiki: middleware over point-to-point, failure models, retry semantics (at-least-once, etc.). Forbidden assumptions from §6.2 — fallacies of distributed computing: "the network is reliable", "latency is zero", "topology never changes."

Methodology

Ground the agent on a specific authoritative book in the domain.

1. 1. Choose the book. For architecture / high-load / event-driven systems — Tanenbaum, Distributed Systems: Principles and Paradigms. The "Kotler for marketers" level: rigorous theory with formulas, not a summary.
2. 2. Chunk into a wiki. olw pipeline (obsidian-llm-wiki): fast model for ingest, heavy for compile. Current Tanenbaum run: 30 source chunks → 116 concept pages in .drafts/.
3. 3. Parameters. Several iterations over chunk sizes / token counts / models. Full run cost: around $1.50 via OpenRouter. Three olw runs produced 16 + 14 + 23 note(s).
4. 4. Drop into the project. Wiki lives in the repo. Agent navigates the index — via hybrid-search MCP (breakdown #02) or Cursor indexing. Context doesn't degrade: the agent walks files without loading the entire book into the window.
5. 5. Agent layer on top of retrieval. Wiki + retrieval is infrastructure. On top — query routing, score interpretation, traversal from business requirement to pattern. Queries use the author's terms:

   Bad query	Good query (author's term + plain language)
   "find something about Kafka"	reliable multicast + FIFO ordering — delivery order and reliable broadcast
   "how to sync orders"	persistent vs transient communication — queue holds vs receiver must be online now
   "delivery guarantees"	AMQP: unsettled → settled → forgotten — three delivery commit states

6. 6. Effect. Work plans, API contracts, infrastructure decisions, and vibe-coding flow through the book's lens. The level holds from a single prompt.

The mechanics transfer: wiki is text, it copies between projects. Different phases get different books: Clean Code for development, Fowler for review, Savin for QA.

Vault anatomy: three layers

Real directory structure of tanenbaum/wiki/:

tanenbaum/wiki/
├── raw/tanenbaum-full_rag_00012.md            # book chunk + YAML
├── wiki/sources/Tanenbaum Full_Rag_00012.md   # summary + Concepts
├── wiki/.drafts/Message transmission.md        # concept article
├── wiki/index.md                               # index of 30 sources
├── wiki/log.md                                 # olw run log
└── wiki.toml                                   # models, ctx, language

Layer 1 — raw chunk

rag_chunk: 12
rag_total_chunks: 30
rag_chunk_size: 51542
rag_overlap: 800

Layer 2 — source page

Concepts (author's chunk index): IBM WebSphere MQ, message channels, routing tables, message transmission — index before reading full text.

Layer 3 — concept article

Excerpt from wiki/.drafts/Message transmission.md:

Message queue systems provide guaranteed delivery,
priorities, logging, [[load balancing]] and [[fault tolerance]]
[[Tanenbaum Full_Rag_00012]].

Message transmission in [[AMQP]] has three stages:
1. Message in "unsettled state" on sender and server.
2. Receiver processed → "settled state".
3. Sender forgets the message, receiver formally marks settled
   [[Tanenbaum Full_Rag_00012]].

## See Also
[[Message-oriented models]] · [[Two-phase commit protocol]]
· [[Tanenbaum Full_Rag_00012]]

Cross-references aren't decoration: the agent goes from "orders must not be lost" to persistent communication (queue holds the message), then to AMQP delivery states (unsettled → settled), and only then — to Kafka/RabbitMQ as implementations.

Frontmatter + quality flags:

confidence: 0.35
status: draft
sources:
  - raw/tanenbaum-full_rag_00012.md

<!-- olw-auto: low-confidence (0.35) — verify before publishing -->
<!-- olw-auto: single-source — cross-reference recommended -->

Run parameters

From the real vault's wiki.toml:

fast = "google/gemini-2.0-flash-lite-001"   # ingest
heavy = "google/gemini-2.5-flash"           # compile
fast_ctx = 24000                            # ≈ 12k chars per chunk
max_concepts_per_source = 25
language = "ru"

olw pipeline: raw/ → ingest → compile → lint → approve. Command: olw run.

Artifact

Tool: obsidian-llm-wiki (olw) — local Karpathy-style LLM Wiki pipeline.

• Input: PDF or book text, chunks in raw/
• Output: Obsidian vault with wikilinks and source traceability
• Retrieval: obsidian-hybrid-search as MCP (breakdown #02)
• Applied: Kafka = 2PC, outbox (breakdown #09)

olw init my-book-wiki
# drop chunks into raw/
olw run

For whom and why

If you're building AI-assisted development and want the agent to hold an architectural standard without reminders — this methodology transfers to any domain. The bottleneck isn't code: it's choosing the right primary source and the discipline to apply it.