# Build your work LLM wiki

Fictional examples. Portable setup. Evidence before answers.

## Start with one project and grow your work wiki slowly

### Why this matters

One project lets you check whether the wiki preserves decisions, owners, and next actions. Expand after you can trace its answers to the source evidence.

A work LLM wiki stores readable Markdown pages and uses an assistant to help capture and retrieve them. Its value comes from preserving decisions, context, and evidence across meetings and projects. The assistant does not make a statement true merely by writing it into a page.

- Preserve the original source so another person can check it.
- Write a source card that explains what the source actually says.
- Link that card to the current project and any reusable lesson.
- Search, read the underlying page, and check the answer against its source.

This guide uses a fictional Northstar pilot. None of its people, dates, decisions, or metrics describe an employer.

### Your first planning prompt

```text
Help me build a small work LLM wiki for one fictional project. My goal is to recover decisions and their reasons. Give me a folder plan, one source-card template, and three questions to test retrieval. Use fictional content. Explain unfamiliar terms before using them. Do not install software or change existing files.
```

## Choose how AI reads, adds, and edits work files

### Why this matters

Your employer’s storage and model rules determine which tools you can use. Choose an approved access path, then check what the assistant can read and change.

| Option | What you get | What you must manage |
| --- | --- | --- |
| Markdown only | Editable pages; folder and text search | Manual capture and evidence review |
| Markdown + approved agent | Drafting and synthesis from pages you provide | Agent access, allowed data, and review of edits |
| Local install kit + Ollama | Local semantic retrieval and local answers | Python, local models, indexes, and installation checks |
| Automated source connectors | Scheduled intake from approved systems | Account scope, source identity, deduplication, and failure reporting |

Obsidian is an optional reader and editor. SQLite is a local search database. An embedding is a numeric representation used to find similar meaning. A graph is a set of explicit page links. You do not need every component to begin.

For a work wiki, select the employer-approved storage and model route before putting work material into it. A local model endpoint is one technical boundary; it does not establish whether another app, sync service, or agent is allowed to access that material.

### Choose a route

```text
Recommend a setup for these constraints: [approved storage], [approved agent/model], [device], [install permissions]. Separate required tools from optional tools. Start with manual Markdown if installation is unavailable. Do not assume cloud access or connector permissions.
```

## Set up your work wiki in a new folder

### Why this matters

An empty practice folder lets you learn the workflow without replacing existing work. The starter supplies readable files; you choose and verify the assistant separately.

- Download and unzip the work starter kit into a new empty folder named MyWorkLLMWiki.
- Open README.md and instructions/wiki-rules.md in a text editor.
- Open raw/ingest/example-meeting.md: it is fictional evidence for the practice exercise.
- Use your approved assistant by pasting the rules and source. Save its proposed page in drafts/; compare it with the source before accepting.
- Open the folder as an Obsidian vault if you want linked notes, search, and templates.

The starter is a set of Markdown files. It installs no model, database, connector, or plugin. An assistant with folder tools can reduce copying, but you must verify its access and read-back behavior. On a managed work device, use approved storage, accounts, and model routes.

### Verify a file agent before setup

```text
Work inside the new MyWorkLLMWiki folder only. Read README.md and instructions/wiki-rules.md. List the files you can access and your available read/search/write tools. Do not execute scripts, read parent folders, or replace existing files. If tools are unavailable, use paste-and-save instructions.
```

For optional local inference, follow the current Ollama quickstart: https://docs.ollama.com/quickstart. Select a local model explicitly; running a model does not grant it file access. Test names, numbers, citations, and missing evidence before selecting it for this workflow.

## Separate sources, project work, and reusable knowledge

### Why this matters

Sources record what happened, project pages guide current work, and knowledge pages preserve lessons. Keep those jobs separate so an update does not erase the evidence behind it.

| Artifact | Home | Job |
| --- | --- | --- |
| Raw original | raw/ | Preserve the file as evidence; keep out of a public repository |
| Source card | wiki/sources/ | Explain one source and point back through raw_ref |
| Live project | active-projects/northstar-pilot/ | Track current state, dated decisions, actions, and open questions |
| Durable finding | wiki/work/ or wiki/concepts/ | Preserve reviewed conclusions and reusable methods |
| Generated draft | Owning project outputs/ or categorized outputs/ | Hold reviewable work before deliberate promotion |

The layout below shows optional folders for a larger wiki. The starter supplies MyWorkLLMWiki with raw/, project files, and wiki pages. Add system controls or executable tools only when you choose and verify those capabilities.

### Compare the optional larger-wiki layout

```text
MyWorkLLMWiki/
  index.md
  active-projects/northstar-pilot/
    _index.md
    live-log.md
    promotion-queue.md
    outputs/
  wiki/sources/
  wiki/work/
  wiki/concepts/
  _system/
  tools/scripts/
  raw/
```

One reviewed advanced installation links raw/ to a separate source folder. The manual starter uses a normal directory. Check your selected setup before assuming it uses a link. If you cannot reach the source folder, report that you could not verify the evidence.

The work routing contract makes each canonical source discoverable from index.md through wiki/sources/_ingestion-index.md and a provider or project register. Link the project to the source card and the card back to the project. Create meaningful pages when evidence exists rather than empty cards just to satisfy a link. These optional larger-wiki registers are not supplied or required for the manual starter; use the included index and project card first.

## Update each project’s state, decisions, and next actions

### Why this matters

A project page helps the next reader see what changed and who acts next. Its dated decisions and source links preserve the reasoning behind the current plan.

Create the project files below manually. The starter includes no ingestion helper. The helper in the reviewed advanced installation did not create this structure, assign task owners, archive outputs, or close projects automatically. Before asking an approved agent to manage a project, read its project rules and review the changes it proposes.

### Create these project files in your practice wiki

```text
active-projects/northstar-pilot/
  _index.md
  current-state.md
  decision-log.md
  tasks.md
  promotion-queue.md
  notes/
  outputs/
    current/
    archive/
```

| File | What to put in it | What to check |
| --- | --- | --- |
|  _index.md | Purpose, owner, status, next milestone, links to source cards and control pages | A new reader can find current state and evidence |
| current-state.md | As-of date, current scope, blockers, latest reviewed decision, next action | Each material claim links to its source |
| decision-log.md | Dated decision, stated reason, decider, source link, replacement decision when applicable | Previous decisions remain visible |
| tasks.md | Action, owner, due date or unknown, status, source link | Dates and owners come from a source or explicit assignment |
| promotion-queue.md | Candidate reusable findings plus supporting source cards | Candidates stay separate from established lessons |
| outputs/current/ | The currently reviewed deliverable and its evidence manifest | Current version is explicit |
| outputs/archive/ | Superseded deliverables in dated/version folders | Old versions remain recoverable |

### Fictional current-state page

```text
# Northstar pilot — current state
As of: 2026-10-08
Owner: Mira
Current scope: Two-team pilot, approved October 8.
Evidence: [[source-northstar-review-20261008]]

## Next action
Sam drafts the handoff checklist by October 9.
Evidence: [[source-northstar-meeting-20261002]]

## Open question
Escalation ownership remains unresolved.

## History
[[decision-log]]

## Current deliverable
[Checklist draft](outputs/current/handoff-checklist.md)
```

- After a new meeting, preserve its raw source and create or review its source card.
- Append the supported decision to the dated log. Update current-state only after resolving whether that decision changes the project.
- Update task owners, dates, and completion only when the source or a person establishes them. Keep unknown values explicit.
- Save the reviewed deliverable under outputs/current/. Move superseded versions into a dated archive when the project contract authorizes that operation.
- At closeout, review results against the project goal, preserve unfinished obligations, and promote reusable findings into wiki/work/ or wiki/concepts/ with source links. Keep a Produced manifest in the historical project record.

### Project setup and update prompt

```text
Create a reviewable plan for the fictional Northstar project using the files above. State purpose, owner, current scope, dated decisions, source links, tasks, and open questions. When a new source arrives, show exact changes to current-state, decision-log, tasks, and outputs. Do not infer completion or assign new dates. Follow the target project contract for current/archive and closeout. List reusable findings separately as promotion candidates. Show the plan and diff before any write.
```

Use these project filenames and current/archive folders for a new setup. If you already have a work wiki, read its project rules and adapt the example to its layout.

To reach the current state shown above, review both practice sources and create the source cards. The starter begins with a pending-review state. It does not supply the linked source cards or checklist: you create those files during the exercise. Save the reviewed cards under the IDs shown, then create and review the checklist before linking it as an accepted deliverable.

## Open your wiki in Obsidian

### Why this matters

Obsidian lets you search, link, and edit the same files. Configure its note folders and templates so it saves new notes where you expect.

Install Obsidian through the software route permitted for your device. Open Manage Vaults, choose Open folder as vault, and select the practice wiki folder. If you have no folder yet, create a new vault in your chosen practice location. A vault is the folder of files, not a separate import database. Official setup reference: https://obsidian.md/help/manage-vaults

- Open Settings → Files and links. Choose a new-note folder such as daily-planning/inbox and an attachment folder appropriate to your wiki; confirm those folders exist. For this practice vault, keep copied attachments separate from immutable source originals.
- Open Settings → Core plugins. Enable Templates, Daily notes, Backlinks, and Search as needed. Keep community plugins disabled while you learn the basic workflow.
- Create wiki/templates/ and add a meeting template. Set the Templates folder location to that folder. Insert the template into a new meeting note through Templates: Insert template.
- Configure Daily notes with a daily-planning folder and your daily template. Make one daily note and link it to [[project-northstar-pilot]].
- Open a source card, add its project link, then inspect Backlinks on the project note. Confirm the link connects the intended existing notes.
- Search for Northstar, open the matching page, and check the source passage. Obsidian text search and the LLM retrieval index are separate interfaces.

### Simple meeting template for the practice vault

```text
---
type: meeting
status: draft
created: "{{date:YYYY-MM-DD}}"
project: "[[project-northstar-pilot]]"
---
# {{title}}

Meeting date: unknown
Attendees: unknown
Source: pending

## Decisions and stated reasons

## Actions
| Action | Owner | Due | Source |
| --- | --- | --- | --- |

## Open questions

## Related pages
```

The template date records when you created the note. It does not establish the meeting date; fill that field from the source. The draft status above is a teaching convention. Use the target wiki schema before promoting the note. Templates inserts snippets and supports title/date variables; Daily notes can create dated notes from a configured template. References: https://obsidian.md/help/plugins/templates and https://obsidian.md/help/plugins/daily-notes

| Core feature | Beginner application | Boundary |
| --- | --- | --- |
| Properties | Store small fields such as project, owner, status, and source date | Keep rationale and evidence in the note body |
| Backlinks | See which notes explicitly reference the active project or source | A link does not establish that one claim supports another |
| Bases | Build a filtered table of project notes and their properties | View/edit metadata; does not replace source capture or semantic retrieval |
| Canvas | Lay out project notes and attachments visually | Text-only cards do not appear in Backlinks until converted into files |

Core-feature references: Properties — https://github.com/obsidianmd/obsidian-help/blob/master/en/Editing%20and%20formatting/Properties.md ; Backlinks — https://obsidian.md/help/plugins/backlinks ; Bases — https://obsidian.md/help/bases ; Canvas — https://obsidian.md/help/Plugins/Canvas . These official pages were checked October 5, 2026; app labels can vary by version.

## Add plugins for jobs you repeat

### Why this matters

Each plugin adds behavior you must understand and maintain. Start with a job you repeat, choose one plugin that helps, and check its result.

| Optional plugin | Use when | Application and boundary |
| --- | --- | --- |
| Dataview | You need reusable lists or tables from structured fields | List project notes by owner or status. Its data index reads metadata and supported list/task fields; it is not full-text semantic search. |
| Tasks | You need due-date and recurring-task queries across notes | Show unfinished checklist items by due date. Marking a task done in a query updates its source file. |
| Templater | Simple Templates cannot express your repeated note creation | Insert variables and function results; it can run JavaScript. Review template code before using it. |

Plugin author documentation: Dataview — https://blacksmithgu.github.io/obsidian-dataview/ ; Tasks — https://publish.obsidian.md/tasks/Introduction ; Templater — https://silentvoid13.github.io/Templater/ . These feature claims were checked October 5, 2026. They are optional choices, not proof that a plugin is approved for your work environment.

### Optional Dataview example: requires Dataview

```text
TABLE owner, status, source_date
FROM "active-projects"
WHERE project = "northstar-pilot"
```

Place the example in a dataview code fence after installing and enabling the plugin. Give the example project notes a plain-text project: northstar-pilot property for this filter. If your project property uses wikilinks instead, adapt the filter to that representation. If the list is blank, check whether each note has the project property and uses the expected value type.

- Check that a plugin is permitted and that you trust its author and code. Keep Restricted mode enabled if you do not need community plugins.
- When permitted, open Settings → Community plugins, turn on community plugins, select Browse, find the exact name and author, select Install, then Enable.
- Configure only the feature needed for the practice task. Test the plugin on fictional notes and inspect any files it changes.
- Record the plugin name, version, purpose, and required settings in your wiki setup note. Check for updates through Community plugins when appropriate.
- If the plugin causes a problem, disable it and compare behavior. Turning Restricted mode back on disables community-plugin execution while leaving installed plugin files in the vault.

Obsidian cannot reliably sandbox community plugins to narrow permissions; they inherit its access and may access files or the internet. Plugin installation does not itself authorize cloud processing or connecting a work account. Official instructions and boundary: https://obsidian.md/help/community-plugins and https://obsidian.md/help/plugin-security

### Plugin decision prompt

```text
I repeatedly need [specific job] in my practice wiki. Compare core Obsidian tools with one optional plugin. Use the official documentation for capability claims. State the data it reads, files it changes, code or network behavior to review, and the setup needed. Recommend no plugin if the core feature meets the job. Use fictional data for the test.
```

## Draft a source card from one meeting

### Why this matters

A source card preserves the meeting’s decisions, reasons, owners, and open questions. Review those details before you use the card to update a project or answer a question.

### Fictional first source

```text
Northstar pilot meeting — October 2, 2026
Attendees: Mira (project lead), Sam (support lead).
Decision: Pilot one team before expanding.
Reason: The team must test the handoff process first.
Action: Sam drafts the handoff checklist by October 9.
Open question: How will escalation ownership be assigned?
```

### Ingest proposal prompt

```text
Use only the fictional meeting text above. Draft a source card and a proposed project update. Preserve attendees, date, decision, stated reason, action owner, due date, and open question. Quote or locate the source passage supporting each claim. Separate source facts from your suggestions. Propose id, raw_ref, source_date, privacy, project link, and draft status using the target wiki schema. Show both proposed file paths. Do not write files.
```

Write a source card that answers later questions: who decided, why they decided, what remains uncertain, and which passage supports each answer. Preserve the useful detail and structure from the source. Write unknown when the source lacks a date or owner. Check the proposed paths and factual coverage before saving.

### Source card body example

```text
## What this source establishes
The team will pilot one team before expanding.

## Decision and reason
- Decision: Pilot one team.
- Stated reason: Test the handoff process first.
- Evidence: Meeting lines 3–4.

## Action
- Sam drafts the checklist by October 9, 2026.
- Evidence: Meeting line 5.

## Open question
Escalation ownership remains unresolved.

## Links
[[project-northstar-pilot]]
```

## Check source extraction before you automate intake

### Why this matters

Extraction can lose table rows, labels, or pages even when a tool reports success. Check coverage and identity before you let the process create or update wiki pages.

Manual path: save the original under raw/, supply it to the assistant with rules, ask for a source card, review the draft, then accept it into wiki/sources/. Link the accepted card from its active project. Preserve useful context, decisions, disagreements, and missing extraction—not only a short summary.

### Inspect an automation before trusting it

```text
Describe the installed ingestion tool from its actual help and source. Which file types can it extract? Does it truncate input? What happens if a title or filename already exists? Does it offer a preview? How are raw evidence, updates, logs, and search refresh handled? Separate implemented behavior from documentation. Do not run ingestion or overwrite files.
```

Automation can extract, draft, link, and index files. Test each behavior before relying on it. A source-backed implementation review found truncated input, title-based overwrite risk, ignored smoke-check errors, and documented flags absent from available code. These are reasons to verify your own installer; this public starter includes no such helper.

## Update conclusions and keep the decision history

### Why this matters

A new source may extend, correct, or replace an earlier conclusion. Identify which change it supports so you preserve useful history and leave disagreements visible.

| What changed | Review action | What remains |
| --- | --- | --- |
| Same bytes already captured | Link to existing card after identity check | Original evidence and original card |
| New meeting or independent source | Create its own dated card; update project links | Both sources |
| Minor supported correction | Show an exact proposed diff using the wiki update policy | Prior version recoverable in history or snapshot |
| New version replaces a source | Compare substantive differences and preserve lineage | Older source and supersession trail |
| Conflicting accounts | Record both with dates and authority gaps | Uncertainty until a reviewer resolves it |

### Update/review prompt

```text
A new fictional Northstar note says: “October 8: Mira approved a two-team pilot after the checklist review; Sam still owns the October 9 checklist.” Read the earlier card and project page. Propose a new source card and a dated project update. Preserve the October 2 decision as history. Show exactly what changes and what stays. Do not infer that the open escalation question is resolved. Apply the target wiki rules for reviewed/live pages, source lineage, dates, and suggestions. Include a rollback plan and questions that should find the new decision. Do not write until the concrete proposal is reviewed.
```

Do not assume the PersonalLLMWiki sidecar policy applies to every WorkLLMWiki page. Read the target wiki update policy. Review status, stable IDs, source links, and date fields before an edit. A relationship such as supports or contradicts needs a source-backed reason; an assistant finding similar themes is a review candidate.

## Find relevant pages and check the answer

### Why this matters

Search returns possible evidence. Read the relevant passages before relying on an answer, and check that each citation supports the claim beside it.

Start with an exact filename, project index, or editor search. Open likely pages and their source references. In chat, paste the passages needed for the question; with a file agent, ask it to search and read them. A result preview helps find a page but may omit a caveat. Ask for complete relevant passages before relying on an answer.

### Ask a question from evidence

```text
Search the authorized wiki for the Northstar pilot decision and handoff checklist. Read the matching project page, source cards, and cited original passages. Explain why the pilot was approved and who owns the next action. Cite filenames and headings for each material claim. Separate current decisions, prior decisions, and unknowns. If you cannot read files, tell me which passages to supply.
```

Optional semantic retrieval finds similar meaning; keyword retrieval finds matching terms; graph retrieval follows explicit links. Add them only after a repeatable question fails with basic search. No database or vector service is required for the starter. An answer helper may receive only previews unless its implementation actually opens complete pages.

## Refresh search after you accept a page change

### Why this matters

Search indexes hold derived copies of your files. Refresh them after accepted changes so queries can find the current evidence.

For the manual starter, save the accepted page, open it again, verify links, and repeat the retrieval tests. Obsidian search and links operate on the vault; no custom refresh script is supplied. If you later install external indexing, inspect its documented command and actual source before using it.

### Check an accepted update

```text
Read back the accepted source card and project page. Verify the updated date, source path, decision history, task owner/deadline, and outbound links. Repeat one known-answer question, one changed-decision question, and one unknown. Report stale or missing evidence. Do not invent a refresh command.
```

For advanced setups, confirm that all search stores reflect the accepted source version. Successful indexing does not establish correct extraction or a supported answer. A backup must preserve readable files and source originals so a failed derived index can be rebuilt.

## Test answers, missing evidence, and changed decisions

### Why this matters

A fluent answer can still be wrong. Test a known fact, an unanswered question, and a changed decision to check whether the wiki cites evidence and admits its limits.

| Test question | Expected evidence | Failure to catch |
| --- | --- | --- |
| Who owns the Northstar checklist? | Sam; meeting action passage | Invented or missing owner |
| Why start with one team? | Test handoff process; October 2 source | Reason invented from general knowledge |
| What changed on October 8? | Two-team approval; newer source plus earlier decision history | Older decision returned as current |
| What is the approved budget? | No budget in these fictional sources | Model invents a number |
| Can I reopen the original? | Resolved raw_ref or explicit unavailable state | Broken source treated as verified |

- Write expected answers and exact supporting passages before running the questions.
- Check that relevant cards appear among the retrieved candidates; inspect ranking rather than testing only fluent answers.
- Read the answer citations and compare every owner, date, number, and reason to the source.
- Repeat the changed-decision questions after refresh. Confirm the old source remains recoverable.
- If a test fails, fix the specific layer: extraction, page capture, links, stale index, ranking, or answer context.

### Acceptance review prompt

```text
Review my fictional practice wiki against the five tests above. Return PASS, FAIL, or CANNOT_ASSESS for each. Cite the exact saved page and supporting source passage. Check that old decisions remain in history and that unknown budget stays unknown. Do not infer success from an installer message, index count, or confident wording.
```

Add a second project after your setup passes these checks. Automate one source type at a time. For each type, check source coverage and confirm that you can undo a change before expanding intake.

## Check what the guide and starter actually provide

### Why this matters

Examples teach the workflow; they do not prove that your installation works. Check the supplied files and test your setup before relying on an optional tool or automated step.

This guide combines authored teaching recommendations with an implementation review. It keeps an original installer, available code, and later documented improvements distinct. The public edition includes no private source snapshots, machine paths, work records, or credentials.

The reviewed code snapshot added broader project/planning retrieval, exclusions for generated content, stable chunk identities, metadata, and refresh/diagnostic tools. Later documentation described additional extraction and lineage gates that the available snapshot did not implement. Verify your installed version before using a documented command.

Use the fictional starter to test setup, evidence capture, accepted updates, project closeout, retrieval, and missing evidence. Browser checks prove that the guide renders and links work; they do not prove an installed model or wiki pipeline works.

## Use assistant plugins to write, map, and review

### Why this matters

Writing tools help you organize a claim; diagram tools help you explain a process. Choose the tool for the job, then check its output against the source.

The tools below helped build this guide. Run these tools in a compatible assistant or developer environment. Install Obsidian plugins through its separate Community plugins menu. This starter does not include them. Check the host’s installed capabilities and the plugin’s own setup instructions before asking it to run; a plugin name in a prompt does not install a tool.

| Assistant tool | Application | Check the result |
| --- | --- | --- |
| Pyramid Principle | Structure a project brief or answer: conclusion, key reasons, evidence. | Clarity does not establish truth; retain citations and caveats. |
| Diagram Intelligence | Preserve a directed graph and render ingestion or retrieval flows. | Check evidence, edge direction, branches, and the rendered diagram. |
| NavGator | Inspect supported code and propose an architecture map. | A bounded scan may miss scripts or configured agent steps. |
| RossLabs Agent Architect | Inspect supported code and architecture packets. | Verify language coverage; an empty scan does not prove no workflow exists. |
| RossLabs Designer | Choose a readable layout for a guide or project dashboard. | Inspect the actual desktop/mobile result and working controls. |

### Ask for a source-backed workflow diagram

```text
If Diagram Intelligence and NavGator are installed, inspect the authorized implementation and instructions. Map source → extraction → draft → review → accepted page, including updates and failure branches. Label user actions, actual tool calls, automatic steps, and external systems. Keep a canonical directed graph with source evidence. Export a public diagram without private source paths. Validate connections and inspect the rendered view. If a tool is unavailable or lacks language support, state the coverage limit and use a labeled source-backed fallback.
```

### Write a project brief with Pyramid Principle

```text
Use Pyramid Principle if available. Lead with the current decision, then its key reasons and supporting evidence. Include the next action, owner, due date if known, and unresolved questions. Keep facts separate from inference. Cite the original source for each material claim.
```

Use a diagram to explain the process, a plugin to support a repeated job, and an evidence test to decide whether the result is trustworthy. Do not install every tool before completing your first source-to-answer loop.