Obsidian Vault Blueprint — vanos-brain

The company knowledge system of Prime Products Ltd: a git-backed Obsidian vault, working name vanos-brain. It is a separate vault from key-account-prime, owned by PRIME PRODUCTS, and it is the curated core corpus of the RAG pipeline (../05-technical/rag-and-data-pipeline.md).

Content in vanos-brain may be Greek or English; frontmatter keys and controlled values are always English.

1. Why Obsidian + git

• Plain markdown is AI-readable. No proprietary format between the company’s knowledge and the LLM platform. Every note is directly chunkable, embeddable, and citable.
• Local-first matches the on-prem mandate. Files live on company machines and the on-prem git server; nothing depends on a SaaS vendor’s cloud (see ../05-technical/architecture-overview.md).
• Free/cheap and durable. Obsidian is free for the files themselves; if Obsidian disappears tomorrow, the vault is still a folder of markdown that any editor — or any future AI tool — can read. Knowledge survives tool churn.
• Git gives versioning, backup, audit, and multi-user collaboration. Every change is attributable and reversible; the ingestion pipeline can trigger on commits.

Remote recommendation: a private self-hosted Gitea instance on the on-prem platform (same host cluster as the LLM stack), with a mirrored private GitHub repo (TPL-S-A org or a PRIME PRODUCTS org) as off-site backup. Gitea keeps business data on-prem; the mirror is disaster recovery.

Sync mechanism — recommendation: git-based sync via the obsidian-git community plugin (auto-pull on open, auto-commit/push on interval). Fallback for non-technical heavy editors: self-hosted Obsidian LiveSync (CouchDB) for a small subset of users, still committed to git by a scheduled job.

Option	Cost	On-prem	Conflict handling	Ingestion trigger	Verdict
obsidian-git plugin → Gitea	Free	Yes	Git merge; rare conflicts with folder ownership	Native (post-receive hook)	Recommended
Self-hosted LiveSync (CouchDB)	Free, +1 service to run	Yes	Real-time, per-note	Needs a git-export job	Supplement for heavy simultaneous editors
Obsidian Sync (official)	€/user/month	No — vendor cloud	Good	None	Rejected: violates on-prem mandate
Shared network drive	Free	Yes	None — corruption risk	Poor	Rejected

Conflict avoidance rule of thumb: each department writes inside its own folders; cross-folder edits go through the knowledge manager.

2. Folder tree

vanos-brain/
├── 00-home/                # Dashboards & entry points: vault home, per-role start pages, orphan report
├── 01-company/             # Company profile, org chart, sites (Piraeus HQ, Akti Miaouli, Perama), glossary
│   ├── profile.md
│   ├── organisation.md
│   ├── sites/
│   └── glossary/           # One term per file
├── 02-departments/         # One hub folder per department (15) — the wiki heart of the vault
│   ├── executive-management/
│   ├── sales/
│   ├── procurement/
│   ├── logistics/
│   ├── warehouse/
│   ├── finance/
│   ├── accounting/
│   ├── hr/
│   ├── customer-service/
│   ├── marketing/
│   ├── product-technical-support/
│   ├── it/
│   ├── compliance-quality/
│   ├── administration/
│   └── reporting-bi/
│   #   each: _index.md (hub), overview.md, processes/, sops/ (links into 04-sops), knowledge-map.md, faqs.md
├── 03-processes/           # Process map archive — one process per file (SIPOC + swimlane), cross-department
├── 04-sops/                # All SOPs, flat, named sop-<dept>-<slug>.md — single home, linked from dept hubs
├── 05-meetings/            # Meeting notes: daily/, weekly/, monthly/, ad-hoc/ — dated files
├── 06-projects/            # One folder per project, incl. ai-transformation/ (mirror of program milestones)
├── 07-ai/                  # Prompt library (by department/task), agent docs, use-case docs, model notes
│   ├── prompts/<dept>/
│   ├── agents/
│   ├── use-cases/
│   └── models/
├── 08-data/                # Data source inventory (one source per file), report catalog
├── 09-decisions/           # Company decision log, ADR-style, NNN-slug.md, append-only
├── 10-risks/               # Risk register — one risk per file + _index register table
├── 11-training/            # Training docs, course notes, onboarding paths per role
├── 12-vendors/             # Vendor & technology notes, evaluations (incl. SoftOne, Microsoft 365)
├── 13-lessons-learned/     # Retrospectives and post-mortems, dated
├── 14-improvement-backlog/ # One improvement idea per file, triaged by status
├── 15-compliance/          # ISO 22000 / 21001 / 29993 controlled documents & doc-control register
├── _templates/             # Templater/core templates — see obsidian-template-library.md
└── _archive/               # Superseded notes, moved not deleted; excluded from RAG

One-line intent per top folder is inline above. Reserved-growth rule (as in key-account-prime): create subfolders when the first real content arrives, not before.

3. File naming rules

• Everything kebab-case, ASCII where possible; transliterate Greek proper nouns in filenames (content may stay Greek).
• Dated notes (meetings, lessons learned, session-style notes): YYYY-MM-DD-slug.md, e.g. 2026-09-14-weekly-sales.md.
• SOPs: sop-<dept>-<slug>.md, e.g. sop-warehouse-inbound-receiving.md.
• Decisions: NNN-slug.md sequential, e.g. 007-adopt-teams-approval-flow.md; never renumbered.
• One concept per file. If a note covers two things, split it.

4. Tagging system

Small controlled set, defined in 00-home/tag-registry.md; new tags require knowledge-manager approval.

Namespace	Values (examples)	Purpose
#dept/…	#dept/sales, #dept/warehouse, … (15)	Cross-folder department filter
#status/…	#status/draft, #status/review, #status/approved, #status/archived	Mirrors frontmatter status for quick queries
#type/…	#type/sop, #type/process, #type/faq, #type/prompt, #type/decision	Note kind, mirrors frontmatter type
#sensitivity/…	#sensitivity/high, #sensitivity/normal, #sensitivity/public	RAG access filtering

Rules of thumb — folders vs tags vs links:

• Folders answer “who owns this note” (exactly one home).
• Tags answer “what kind of thing is it / how should machines filter it” (few, controlled).
• Links answer “what is this related to” (unlimited, encouraged).
• If you are inventing a tag to group related notes, you probably want a hub note (MOC) with links instead.

5. Linking methodology

• Every note links up to its hub (_index.md of its folder or department) in a Part of: line near the top.
• Hubs link down to every note they own — a note not reachable from a hub is an orphan.
• MOC pattern (map of content): department _index.md files and 00-home/ dashboards are MOCs; they narrate the links, not just list them.
• Orphan-note weekly report: a scheduled job (git hook or CI) lists notes with no incoming links and posts the report to 00-home/orphan-report.md and the knowledge manager’s Teams channel. Orphans are fixed or archived within a week.
• Use relative markdown links (GitHub- and RAG-friendly), not bare wiki-links, for anything the site or pipeline must resolve.

6. Frontmatter standard

Identical OKF style to this repo — mandatory on every note, because the RAG pipeline filters on it:

---
name: Inbound receiving SOP (warehouse)
description: Step-by-step receiving procedure for the Perama warehouse.
type: sop            # sop | process | faq | prompt | agent | decision | meeting | risk | training | vendor | data-source | glossary | project | note
status: approved     # draft | review | approved | archived
last-updated: "2026-09-14"
owner: warehouse-lead        # role, not a named individual
tags: [dept/warehouse, type/sop]
vault: vanos-brain
data_sensitivity: normal     # public | normal | high
language: el                 # el | en — content language hint for retrieval
---

status, data_sensitivity, and language are load-bearing: ingestion includes only status: approved, applies access filters from data_sensitivity, and routes embeddings by language.

7. Daily / weekly / monthly note structure

Cadence	Note	Who writes	Content
Daily	05-meetings/daily/YYYY-MM-DD-<team>.md	Team lead (2 min) — optional, ops teams only	Blockers, exceptions, handovers
Weekly	05-meetings/weekly/YYYY-MM-DD-<dept>.md	Department head or delegate	Decisions, actions with owners/dates, KPI notes
Monthly	05-meetings/monthly/YYYY-MM-<topic>.md	Executive management / steering	Review against roadmap, escalations

Meeting Scribe Agent (see ../08-ai-portfolio/ai-agent-registry.md) auto-drafts meeting notes from Teams recordings/transcripts into status: draft; a human attendee curates, fixes attribution, and promotes to status: approved. Drafts never enter RAG.

8. Department knowledge hubs

Each of the 15 folders under 02-departments/ carries an _index.md hub with required sections (template: department hub template in obsidian-template-library.md):

1. What we do — 5-line mission and scope.
2. Processes — links into 03-processes/ owned or touched by the department.
3. SOPs — links into 04-sops/ (sop-<dept>-*).
4. Systems — which systems the department lives in (SoftOne modules, M365, e-shop, …) with links to 08-data/ entries.
5. Contacts — roles and responsibilities (roles, not names, where the note is sensitivity/public).
6. FAQs — link to faqs.md; the top questions the AI assistant should answer for this department.
7. Prompt shortcuts — links to the department’s proven prompts in 07-ai/prompts/<dept>/.

9. Knowledge maps per department

Each department maintains knowledge-map.md: a coverage checklist that turns “is our knowledge written down?” into a number.

Dimension	Measure
Processes	# documented in 03-processes/ vs # identified in discovery → %
SOPs	# approved SOPs vs # required (from process inventory) → %
FAQs	# answered FAQs vs question log from the AI assistant → %
Freshness	% of notes with last-updated within review cycle

These percentages roll up into the program KPI framework (../02-program/kpi-framework.md) and render on Mission Control’s knowledge-base progress page (../07-mission-control/mission-control-blueprint.md).

10. Governance

• Knowledge manager role (part-time, likely compliance/quality or IT): owns conventions, tag registry, orphan report, review calendar, RAG inclusion gate. Department knowledge champions (one per department) own their folder’s quality.
• Review cycles: SOPs reviewed annually (or on process change); every note type carries a freshness expectation — notes past due are flagged in the weekly report and demoted from approved to review if untouched after 30 days of flagging.
• Quality bar for RAG inclusion: only status: approved notes with valid frontmatter and an owner get ingested (../05-technical/rag-and-data-pipeline.md). Approval = department champion sign-off; for 15-compliance/ documents, the ISO doc-control process applies instead and supersedes this.
• Escalation: disputes over ownership or content → knowledge manager → steering per ../02-program/governance-model.md.

11. Long-term role & connection to AI/RAG

vanos-brain is designed to outlive the transformation program as PRIME PRODUCTS’ permanent knowledge system:

1. Vault = curated core corpus. ERP data, SharePoint files, and mail stay in source systems; the vault holds the distilled, approved knowledge layer the assistant trusts most.
2. Git hook → ingestion. A post-receive hook on Gitea triggers the pipeline: changed approved notes are re-chunked, re-embedded, and metadata-filtered by data_sensitivity and dept tags.
3. Assistant cites vault notes. Every RAG answer links the source note; users land in the vault (or its rendered site) one click from the answer.
4. Gap-report loop. Questions the assistant could not answer well are clustered weekly; the pipeline writes back “missing knowledge” stub notes (status: draft, tagged #type/faq) into the owning department’s folder — the backlog of what to document next.

12. Rollout plan

Phase	Month	What happens
Design	M3	This blueprint approved; vault + Gitea + templates + hooks stood up; knowledge manager named
Seed	M4	Discovery outputs migrated in: process inventory, org/site profiles, glossary, requirement-linked notes (../03-discovery/requirement-analysis-framework.md)
Department rollout	M5+	Department-by-department, champion-led, sequenced with the pilots (../02-program/roadmap-12-month.md); 2-week onboarding per department: hub built, top-10 SOPs written, knowledge map baselined
Habit	M5–M12	”Document as you answer”: any question answered twice by a human becomes a note; enforced socially by champions and measured by the gap-report loop

Success criterion at M12: every department hub live, knowledge-map coverage above the KPI target, and the vault serving as the assistant’s top-cited source.