> Public study copy. Original Xavier note path: `00-09 System/02 Vault Governance/02.01 Vault Schema.md`. Secrets/credential-like values, if any, are redacted.

# 02.01 Vault Schema

## Purpose

This vault is the durable workspace for Paulo ↔ Xavier/Hermes: relationship dashboard, project memory, research synthesis, operating notes, sources, assets, and decision continuity.

Working metaphor:

> Obsidian is the workspace. Johnny.Decimal is the address system. Xavier is the maintainer.

## Canonical Johnny.Decimal structure

```text
Xavier/
├── 00-09 System/         # JDex, schema, templates, migration maps, logs
├── 10-19 Dashboard/      # visual dashboards and operating overview
├── 20-29 Inbox/          # unprocessed captures and temporary intake
├── 30-39 Projects/       # active projects, decisions, tasks, results, reports
├── 40-49 Knowledge/      # concepts, research, syntheses, resources
├── 50-59 Operations/     # Hermes, VPS, sync, backups, runbooks
├── 60-69 Sources/        # raw/provenance material
├── 70-79 Assets/         # attachments, images, screenshots, media
├── 90-99 Archive/        # old/superseded material
├── .obsidian/            # Obsidian settings
└── .stfolder/            # Syncthing marker
```

## Filing rules

1. If it is navigation/schema/log/template material → `00-09 System`.
2. If Paulo should see it as status/overview → `10-19 Dashboard`.
3. If it is unprocessed → `20-29 Inbox`.
4. If it belongs to a project with outcomes → `30-39 Projects`.
5. If it is reusable knowledge/research/synthesis → `40-49 Knowledge`.
6. If it explains how Xavier/Hermes/VPS/sync/backups work → `50-59 Operations`.
7. If it is original source/provenance material → `60-69 Sources`.
8. If it is an image/attachment/support file → `70-79 Assets`.
9. If it is old/superseded → `90-99 Archive`.

## Sources vs assets

- `60-69 Sources` is for material that should be cited or preserved as evidence/provenance.
- `70-79 Assets` is for support files embedded in notes: images, screenshots, diagrams, PDFs, audio, video.

Default attachment target: `70-79 Assets/70 Asset Inbox`.

## Transversal knowledge model

For material that serves multiple contexts, use the governance model in [[02.05 Transversal Knowledge Governance and OKF-lite Freshness Model]].

Core rule:

> JD gives the address. Links give the network. OKF-lite gives freshness.

Operationally:

- folders/JD express canonical ownership and maintenance responsibility;
- links, backlinks, section links, and block links express intellectual/contextual use;
- OKF-lite frontmatter is applied selectively to critical maintained notes where stale state would create confusion.

A source, study, video, quote, or document should not be copied into every project it helps. Preserve it once under the right canonical owner, then link to it from PhD, Academia, Career Architecture, Voice Lab, or other project maps as needed.

## Canonical owner rule

Before creating or editing a note, identify the canonical owner of the information. If the owner already exists, update it or link to it instead of creating a parallel note.

Default owners:

- source/provenance → `60-69 Sources`;
- concept/framework → `40-49 Knowledge`;
- project decision → relevant project decision register;
- current project state → dashboard/tracker;
- task → task board/tracker;
- procedure → skill or operation/playbook.

Project dashboards should point to owner notes; they should not duplicate source material or full syntheses.

## Johnny.Decimal naming

- Areas: `30-39 Projects`
- Categories: `31 ShonenSOL`
- IDs/notes: `31.02 ShonenSOL Decisions.md`

Prefer short IDs in chat when clear: `31.02`, `53.01`, etc.

## Structural-edit preflight

Before renames, moves, bulk link cleanup, or governance restructuring:

1. Check the destination category and required note ID prefix.
   - Example: a note under `60-69 Sources/64 Media/` should be `64.xx`, not `61.xx`.
2. Check active naming decisions in the relevant decision register/canonical note.
   - Example: GUI/Guilherme is active; Baltasar is historical only.
3. Treat filenames as evidence, not authority. A legacy filename may be wrong.
4. Use dry-run for risky changes and review the proposed diff before applying.
5. After applying, verify old path removal, new path existence, active duplicate IDs, source-folder alignment, unresolved-link changes, and forbidden active labels.

## Page conventions

Durable maintained pages should normally have frontmatter:

```yaml
---
title: Page Title
created: YYYY-MM-DD
updated: YYYY-MM-DD
type: dashboard | project | decision-log | research | synthesis | operation | source | asset-index | schema
status: active | draft | archived
tags: [xavier]
sources: []
---
```

Use wikilinks for navigation. Do not force artificial links.

## Promotion rules: what should be filed from chat

Do file:

- project decisions and rationale
- research insights that could influence a paper, model, product, or teaching material
- technical setup procedures and environment-specific notes
- unresolved durable questions
- substantial comparisons or synthesis answers
- product principles that should guide future implementation
- results that Paulo may want to review later

Do not file:

- routine acknowledgements
- temporary task progress
- secrets, passwords, API keys, tokens, private keys, or connection strings
- every minor idea before it has enough signal

Rule of thumb:

> File things that would be painful to rediscover later.

## Orientation workflow

Before major vault work, read:

1. [[00.01 JDex]]
2. [[00.02 Vault Map]]
3. [[00.03 Vault Log]] recent entries
4. Relevant project dashboard/decision notes

## Maintenance rules

- Update [[00.01 JDex]] when adding durable top-level notes.
- Update [[00.03 Vault Log]] for meaningful restructuring, decisions, or project-state captures.
- Keep dashboards short and useful.
- Keep files out of root except `.obsidian`, `.stfolder`, and intentionally root-level system files if ever needed.