The Two Weeks Before the First Document
There is a common pattern in knowledge management projects that nobody talks about enough: the first two weeks are not spent capturing knowledge. They are spent arguing about structure.
What pages should exist? How should the query routing be organized so that "show me the LBO sensitivity table for the Acme deal" lands on the right page instead of returning a generic financial overview? Which source types need their own intake forms, and what fields matter for a pharmaceutical company versus an investment fund? How aggressively should the lint gate fire - a compliance team needs every claim to be citation-backed, while a personal learning wiki can afford to be looser?
These decisions are not arbitrary. They reflect how knowledge actually moves through a domain: the document types people produce, the questions they ask against existing content, the verification standards that professionals in that field consider non-negotiable. A compliance analyst's knowledge base has a fundamentally different shape than a DevOps runbook system, even if both are backed by the same LLM infrastructure.
The problem is that most teams figure this out by trial and error. They install a blank wiki, start ingesting, discover the routing is wrong after a dozen queries fail to route correctly, rebuild the index, start over. The structural questions that should be answered on day one get answered by week four, after the team has already ingested content that no longer fits the corrected structure.
This is the problem that domain templates solve.
What a Domain Template Actually Provides
A domain template is not a demo or a sample dataset. It is a pre-made structural skeleton for a specific knowledge domain - everything that governs how knowledge is organized, ingested, and queried, without any of the actual content.
When you install Synthadoc with a domain template, you get six structural components in one operation:
1. Query routing table (ROUTING.md)
This is the map that tells the query engine which branches of your wiki to search based on the nature of the question. A finance/investment template routes "capital structure questions" to pages about debt financing and covenants, while routing "valuation questions" to financial models and comparable companies. A compliance template routes "regulatory requirement questions" to the regulatory obligations register, separate from the controls and audit findings that address them.
Writing this routing from scratch requires understanding how queries in that domain actually decompose - what the natural question categories are and which page types hold the answers. That is domain knowledge most developers building a knowledge system do not have, and it shows up as poor retrieval quality until someone with domain expertise intervenes.
2. Domain-tuned agent guidelines
Each template ships with a CLAUDE.md, AGENTS.md, and GEMINI.md in the wiki root. These are the standard files that AI coding assistants — Claude Code, Gemini CLI, GitHub Copilot Agents — read automatically when they are active in a directory. The domain guidelines from the template are injected into each file, so any AI tool you already use becomes domain-aware the moment it opens the wiki.
Here is what the clinical healthcare template puts in those files:
Cite clinical guidelines by issuing body, title, year, and recommendation strength (Grade A/B/C or Level 1/2/3). Flag drug dosages with the approved indication, route, weight-based formula if applicable, and key contraindications. Note evidence quality for every clinical claim: RCT, meta-analysis, cohort study, expert consensus, or case report. Never store identifiable patient data in wiki pages — all examples must be de-identified or synthetic.
Compare that to the compliance template:
Map every compliance obligation to the specific regulation, rule, or contractual requirement that creates it. Track compliance controls with the control owner, testing frequency, and last test date and result. Document exceptions and risk acceptances with approver, rationale, and expiry date. Distinguish between legal requirements (non-negotiable) and internal policy requirements (adjustable). Note jurisdiction and regulated entity for every obligation — compliance applies entity-by-entity.
These are not generic instructions to "be accurate and cite your sources." They reflect how practitioners in each field think about quality. When a compliance analyst has Claude Code running in their wiki directory and asks it to help write a page, draft an ingest command, or interpret a lint warning, Claude Code reads CLAUDE.md and already knows that regulatory citations need jurisdiction-level specificity, that control owners must be named, and that internal policy requirements are distinct from legal ones. The analyst gets a coding assistant that understands the domain's standards — without configuring anything.
The same files also include the full Synthadoc CLI reference, page schema, lifecycle commands, and MCP tool list, so the AI assistant always knows how to operate the wiki correctly for that domain.
3. Scaffold stub pages
Each template ships with 8–12 stub pages covering the core knowledge areas of that domain. For finance/investment, these include pages for companies, deals, financial models, and sectors. For a DevOps template, you get pages for infrastructure, incidents, pipelines, and runbooks.
These pages are not populated with content — they are empty frames with the right titles, frontmatter, and a scaffold zone marker that tells the system where auto-generated content can live versus where your own edits are protected.
The scaffold zone mechanic is worth explaining: every scaffold page contains an HTML comment <!-- synthadoc:scaffold --> that divides the page into a preserved zone (above the marker, where you write permanent content) and a generated zone (below it, refreshed by the weekly scaffold job). This means the structural skeleton gets maintained automatically as your wiki grows, without ever overwriting work you have done by hand.
4. Blank intake forms (template-*.md)
The raw_sources/ subfolders in each template install contain blank intake forms for the document types common to that domain. A finance/investment install includes forms for company profiles, deal memos, financial models, and due diligence checklists. A pharmaceutical template includes forms for clinical trial summaries, regulatory submission packages, and drug safety reports.
These are structured markdown templates with pre-defined fields that mirror what practitioners actually record for each document type. An investment banking associate filling in a deal memo form is prompted for the deal thesis, target return, capital structure, and key risks — the same fields they would populate in any professional deal memo, now wired directly into the knowledge base.
5. Pre-validated seed sources (seeds.md)
Every template includes a seeds.md file that lives in the wiki root after installation. This file contains curated ingest commands for public-domain reference sources specific to that domain — all checked for accessibility, domain relevance, and compliance with the domain's own quality standards before the template was released.
For finance/investment, the seed sources include the SEC's investor education materials and the Federal Reserve's H.15 interest rate releases. For banking, they include the FDIC's regulations and the OCC's publications index. For healthcare/clinical, they include clinical guideline registries and evidence-based medicine references.
The intent is to give the wiki real domain context before the team starts adding proprietary content. A query about LBO mechanics should have authoritative reference material to draw on, not just a blank slate.
6. Scheduled maintenance jobs
A template install also pre-registers two recurring jobs: a weekly lint run (Sunday 2:00 AM) and a weekly scaffold job (Sunday 3:00 AM). The lint job validates every page in the wiki against the domain guidelines — checking for citation presence, orphan links, and internal contradictions — then promotes clean draft pages to active status automatically. The scaffold job refreshes the stub pages and index with new LLM-generated summaries of your current content.
Neither job requires manual intervention once the wiki is running.
Template Library: 30 Domains, 9 Categories
Synthadoc ships 30 domain templates organized across 9 categories. The full library is shown below.
┌─────────────────────────────────────────────────────────────────────────┐
│ SYNTHADOC DOMAIN TEMPLATE LIBRARY │
├──────────────────┬──────────────────────────────────────────────────────┤
│ FINANCE (4) │ Investment · Mortgage · Banking · Accounting │
├──────────────────┼──────────────────────────────────────────────────────┤
│ TECHNOLOGY (4) │ Software Dev · DevOps · AI/ML · Data Engineering │
├──────────────────┼──────────────────────────────────────────────────────┤
│ HEALTHCARE (3) │ Clinical · Pharmaceutical · Public Health │
├──────────────────┼──────────────────────────────────────────────────────┤
│ LEGAL (3) │ Legal Ops · Compliance · IP Management │
├──────────────────┼──────────────────────────────────────────────────────┤
│ RESEARCH (3) │ Academic · Market Research · Science Lab │
├──────────────────┼──────────────────────────────────────────────────────┤
│ OPERATIONS (3) │ Facility Mgmt · Manufacturing & QC · Supply Chain │
├──────────────────┼──────────────────────────────────────────────────────┤
│ REAL ESTATE (3) │ Development · Investment · Property Management │
├──────────────────┼──────────────────────────────────────────────────────┤
│ EDUCATION (3) │ Personal Learning · Course Design · Corp. Training │
├──────────────────┼──────────────────────────────────────────────────────┤
│ BUSINESS (4) │ Project Mgmt · Product Mgmt · HR & People · │
│ │ Marketing │
└──────────────────┴──────────────────────────────────────────────────────┘
The categories were not chosen arbitrarily. The selection reflects two criteria: domains where knowledge is both high-stakes (wrong answers have real consequences) and naturally document-heavy (the source material already exists, it is just not queryable). Finance, healthcare, and legal are the clearest examples — these fields produce enormous volumes of structured documents whose content practitioners need to recall accurately under time pressure. Technology operations and research are the next tier, where the cost of an engineer not knowing the current incident runbook or a researcher duplicating a failed experiment is concrete and measurable.
How the guidelines were designed
Each set of agent guidelines was written from the conventions and standards of the professional community, not from first principles. The investment banking guidelines are grounded in how analysts actually distinguish between management guidance, analyst consensus, and proprietary estimates — a distinction that matters for compliance reasons, not just accuracy. The clinical guidelines encode evidence grading scales (Grade A/B/C, Level 1/2/3) that clinical practitioners use daily. The compliance guidelines map obligations to the specific regulations that create them, which is how compliance officers structure their work to survive an audit.
The seed sources were validated for two properties: accessibility (the URL resolves and returns parseable content) and domain appropriateness (the content meets the quality bar defined in the template's own guidelines). A seed URL that returns a 404, requires authentication, or produces content below the domain's evidence standards is not included. The seeds are regenerated automatically on each release by a validation script that re-checks every URL and re-runs the domain guidelines against the returned content.
Building Your Domain Wiki: From Install to First Query
Getting a domain-template wiki to the point where it can answer real questions takes less than an hour for most domains.
Step 1: Install with a template
synthadoc templates list # browse all 30 options
synthadoc install my-wiki --target ~/wikis --template finance/investment
synthadoc serve my-wiki
The install command creates a standard wiki, then applies the template: routing table, agent guidelines, stub pages, intake forms, and seeds. staging_policy is set to all on template installs — every ingested page goes to a candidates queue for your review before it enters the live wiki.
Step 2: Read seeds.md
Open seeds.md in the installed wiki. This is your starting checklist: the seed ingest commands at the top give you authoritative reference material in one copy-paste operation; the topic hints below them point you toward additional sources specific to your situation.
# From seeds.md for finance/investment:
synthadoc ingest "https://www.investor.gov/introduction-investing" -w my-wiki
synthadoc ingest "https://www.federalreserve.gov/releases/h15/" -w my-wiki
Step 3: Add your own sources
Place your documents in raw_sources/ using whatever subfolder structure makes sense for your domain. The intake forms in each subfolder show you what fields the ingest agent expects for each document type. Copy a form, rename it (drop the template- prefix), fill it in, then ingest it.
If you prefer to fill everything in first and ingest in one shot, that works too:
# All files in raw_sources/, excluding template-*.md blanks automatically
synthadoc ingest raw_sources/ --batch -w my-wiki
Step 4: Review candidates
After ingesting, open the Obsidian plugin and run Synthadoc: Candidates: review candidate pages... from the Command Palette. The modal lists every staged page with its slug, colour-coded confidence badge (high / medium / low), and ingest timestamp — promote what passes your bar, discard what does not.
Step 5: Run lint
synthadoc lint run -w my-wiki
Lint validates every page against the domain guidelines, checks citation presence, and flags orphan links and contradictions. Clean draft pages are promoted to active status automatically. After lint, your wiki is queryable.
What Happens After the Wiki Is Built
Once your domain wiki is active, you stop thinking about configuration entirely. The agentic workflows built into Synthadoc handle maintenance automatically, and the web UI guides you toward the next action without you having to ask.
After every query or lint run, the web UI reads the response and surfaces a pre-filled prompt for the most important next step: stale pages detected → "Re-ingest these pages"; re-ingest just completed → "Run lint to promote them"; contradicted pages found → "Run the contradiction resolver"; orphan pages or broken wikilinks present → the relevant workflow queued and ready. You click, confirm, and the workflow runs. The hint engine also adapts the suggested queries shown at the start of each session to your wiki's current health state — a wiki with unresolved contradictions gets different starting prompts than one that is clean. Most users find they do not need to remember any maintenance commands at all.
Contradiction resolution — when two pages in your wiki assert conflicting claims, the contradiction resolver workflow identifies the conflict, retrieves the original source documents, and proposes a resolution strategy. For a compliance wiki, this means conflicting regulatory interpretations are surfaced and queued for an analyst to adjudicate, not silently left in the knowledge base. The workflow runs interactively from both the web UI and the CLI.
Orphan management — the lint workflow detects pages that exist but are not linked from anywhere in the wiki, then the orphan resolver workflow proposes where to link them. In a knowledge base that grows through continuous ingest, orphan pages are inevitable; having them surfaced and resolved automatically keeps the knowledge graph connected.
Re-ingest on source updates — when a source document is updated, the re-ingest workflow can refresh the wiki page derived from it, comparing the new content against the old and proposing what changed. For domains like compliance (where regulatory updates are frequent) and clinical medicine (where guideline updates are routine), this means the wiki stays current with the underlying source of truth rather than drifting.
Broken wikilink repair — as the wiki grows and pages are renamed or restructured, internal wikilinks can break. The broken wikilinks workflow scans all active pages, identifies links pointing to non-existent slugs, and proposes repairs — renaming the target, creating a stub, or removing the dead link. It runs from the web UI and the CLI and emits a per-page fix summary.
Citation integrity — the citation faithfulness audit checks whether the claims in each wiki page are actually supported by the source documents it cites. Pages that have drifted from their sources — because the source was updated or the summary overreached — are flagged so they can be re-ingested with current content. For regulated domains, this is the difference between a knowledge base you can trust and one you merely hope is accurate.
Sensitive data handling — the sanitizer strips personally identifiable and confidential content from source documents at ingest time, before any text reaches the LLM or the wiki. If sensitive content is later discovered to have made it through, synthadoc retract removes the affected source from the knowledge base and rolls back every wiki page that cited it, and no manual cleanup required.
Scheduled lint and scaffold — the weekly jobs registered at install time keep running in the background. Lint promotes new draft pages and flags quality issues; scaffold updates the index and stub pages to reflect the current state of the wiki. For most wikis, the only manual intervention required is reviewing the contradiction resolver queue when it surfaces something.
The goal is that after the first few days of populating your wiki, the agentic layer handles the maintenance work that would otherwise require a dedicated knowledge engineer.
Under the Hood: Template Architecture
For readers who want to understand how the template system is built, the architecture is straightforward.
Each template is a folder under synthadoc/templates/<category>/<domain>/ containing seven components: description.txt, guidelines.md, routing.md, seeds.md, wiki/purpose.md, wiki/index.md, and at least two stub pages. The agent skill files (AGENTS.md, CLAUDE.md, GEMINI.md) are not stored in the template directory — they are generated at install time by combining the template's guidelines.md with the standard skill file boilerplate. This means improvements to the boilerplate propagate to all 30 templates without any template file changes.
The install command applies a delta-patch: it creates a standard wiki first, then overlays the template components. This keeps the install logic simple and ensures that structural improvements to the base wiki (new fields, new default settings) automatically benefit template installs.
A completeness test gates every new template contribution. A template that is missing any of the required files, or whose stub pages lack valid frontmatter, will fail the test and cannot be merged. This prevents the template library from accumulating half-finished entries.
Templates are discoverable automatically — no registration required. synthadoc templates list reads the templates directory and builds the listing from the description.txt files. Adding a new template is a file creation, not a registration process.
Quick Reference
- Browse the template library:
synthadoc templates list
- Full install instructions and all 30 templates: /templates/README.md in the installed package
- Sync template-managed files after an upgrade:
synthadoc templates sync -w <wiki>
- Release notes (v1.3.3): rtag
Synthadoc is an open-source LLM-powered knowledge base system. The domain template library is included in every install - no additional packages required.
