> Public study copy. Original Xavier note path: `00-09 System/02 Vault Governance/02.02 Vault Data Governance Audit 2026-07-04.md`. Secrets/credential-like values, if any, are redacted.

# 02.02 Vault Data Governance Audit — 2026-07-04

> Status: audit / proposed governance changes
> Scope: Xavier Obsidian vault, with focus on agility, dispersion, redundancy, and research/project data governance.
> Trigger: Paulo noted that the vault made a large operational leap today but raised concern that it may become dispersed, redundant, and less agile.

## Executive diagnosis

The vault is **not yet unmanageable**, but it is at an inflection point.

The Johnny.Decimal architecture is doing useful work: it gives addresses, separates projects from sources, and keeps Xavier/Hermes decisions more auditable than chat history. Today's PhD/Career/Voice Lab separation was directionally correct.

However, the vault is beginning to show **early bloat signals**:

- too many places can receive the same idea;
- project notes, source notes, concept notes, and decision notes sometimes repeat the same framing;
- dashboards risk becoming link lists rather than operating surfaces;
- incoming research material can be preserved faster than it is promoted or retired;
- legacy links and old naming conventions are still present;
- root-level scratch/plugin files exist outside the schema;
- one homepage contained credential material and required immediate sanitization.

The right response is **not to simplify by deleting context**, but to tighten governance around ownership, promotion, and canonical notes.

## Inventory snapshot

As of this audit:

- Total Markdown notes: **136**.
- Main concentration: `30-39 Projects` with **73** notes.
- Knowledge layer: `40-49 Knowledge` with **14** notes.
- Operations layer: `50-59 Operations` with **15** notes.
- Sources layer: `60-69 Sources` with **4** notes.
- Root-level Markdown files outside schema: `[[20.99 Paulo Scratchpad - Do Not Process]]`, `[[Kanban Plugin Test 2026-07-04]]`, `coiso.md`, plus `AGENTS.md`.
- Unresolved wikilinks detected: **82**. Many are legacy path links or intentional examples, but several are real migration leftovers.
- Notes without backlinks detected: **23**. Many are templates or reports, but some may be orphaned.

Largest/currently heavy notes:

- `37.14 Approved Thesis Project V9 Extract` — over 100k chars.
- `OSF Form Submission Copy - Voice Lab PhD` — large research/form copy.
- `LPA R Pipeline Study Manual` — large methodology manual.
- `64.01 YouTube - CEOs Are Regretting Firing People Over AI` — transcript-heavy source note.
- `00.03 Vault Log` — growing chronological log.
- `32.03 Voice Lab Decision Register` — already substantial.

## Positive governance already working

### 1. Separation of durable layers exists

The vault has a coherent layered model:

- `00-09 System` — schema, JDex, log, rules.
- `10-19 Dashboard` — overview/status.
- `30-39 Projects` — active project state and decisions.
- `40-49 Knowledge` — reusable concepts/research/syntheses.
- `60-69 Sources` — source/provenance material.
- `70-79 Assets` — support files.
- `90-99 Archive` — old/superseded material.

This is the right baseline. The issue is enforcement, not the high-level architecture.

### 2. PhD / Voice Lab / Career Architecture separation is conceptually correct

The split prevents a bigger mistake:

- `36 Career Architecture` — Paulo's long-term identity/trajectory across management, PhD, teaching, and intervention.
- `37 PhD Research` — scientific workbench.
- `32 Voice Lab` — public-facing/recruitment/platform layer.

This separation should stay. The risk is not that there are three layers. The risk is that the same paragraphs get copied into all three.

### 3. Decision capture has improved

The vault increasingly distinguishes decisions from raw chat. `37.09`, `32.03`, and `33.12` are valuable because they prevent re-litigating previous conclusions.

### 4. Source/provenance preservation is improving

The YouTube transcript workflow is a good pattern:

- source note stores URL and transcript;
- concept note extracts the reusable idea;
- PhD notes link only the thesis-relevant implication;
- decision register records the decision to use it.

This pattern should become canonical.

## Major risks

## Risk 1 — Canonical ownership is not explicit enough

A single idea can currently appear in multiple places without a clear “owner note”. Example: junior/senior pipeline collapse now appears in:

- source note `61.01`;
- concept note `41.01`;
- PhD dashboard `37.01`;
- conceptual model `37.03`;
- literature map `37.04`;
- decisions note `37.09`.

This was acceptable as a first capture because the idea matters. But if we keep expanding this way, every good idea will generate 5-6 updates.

### Governance rule needed

Every durable idea should have **one canonical owner note**.

For the junior/senior pipeline:

- canonical concept owner: `41.01 Junior-Senior Pipeline Collapse`;
- source/provenance owner: `64.01 YouTube - CEOs...`;
- thesis integration owner: `37.03 Conceptual Model` or future thesis section note;
- decision pointer: `37.09`, but only one concise decision entry.

Other notes should link and summarize in 1-3 lines, not duplicate the concept.

## Risk 2 — Dashboards can become link dumps

Dashboards should be **operational surfaces**, not indexes of every related note.

Current risk areas:

- `37.01 PhD Research Dashboard` is still concise, good.
- `32.01 Voice Lab Dashboard` is short, but uses some legacy relative links that may not resolve.
- `00.01 JDex` is necessary but can drift if every new object is added manually.

### Governance rule needed

Dashboard maximum:

- current orientation;
- top 5-10 active links;
- active decision/open question links;
- current next actions.

Do not add every concept/source/report to dashboards. Link via maps/registers instead.

## Risk 3 — Intake can become a graveyard

`37.10 Source Intake` is useful, but it can become a parking lot if not governed.

For research, intake must be temporary. Every item needs:

- status;
- source location;
- why it matters;
- next processing decision;
- promotion target or archive target.

### Governance rule needed

Every intake entry should end in one of:

- promoted to concept/literature/model/methods;
- preserved as source only;
- converted into task;
- archived as low-value;
- pending with owner and next action.

No indefinite “interesting” entries.

## Risk 4 — Duplicate IDs and naming drift reduce agility

Detected duplicate Johnny.Decimal ID:

- `37.10 Source Intake`
- `37.14 Approved Thesis Project V9 Extract`

This breaks the clean ID/address system. The approved thesis extract should not share `37.10` with Source Intake.

Also detected old or unresolved links:

- legacy `projects/...` links in ShonenSOL notes;
- old `syntheses/...` links in Voice Lab strategy;
- `33.09 Draft Core-Guilherme...` links while the actual file uses `Draft Core-GUI...`;
- source area naming mismatch: JDex describes `64 Media`, but actual media note is under `61 Media`.

### Governance rule needed

IDs are addresses. They should be unique among active notes.

Proposed fix later:

- rename `37.14 Approved Thesis Project V9 Extract` to a non-conflicting ID, probably `37.14 Approved Thesis Project V9 Extract` or move full extract into `60-69 Sources/63 Documents` with a project-facing summary in `37`.
- fix legacy unresolved links in ShonenSOL, Voice Lab, Xavier routing notes.
- decide whether media sources live under `61 Media` or `64 Media`, then align JDex and files.

## Risk 5 — Long source extracts live too close to project operating notes

`37.14 Approved Thesis Project V9 Extract` is very large and lives inside the PhD project folder. It is useful, but it behaves more like a source/extract than an operating note.

Same pattern applies to transcript-heavy notes.

### Governance rule needed

Large raw/extracted material should live in `60-69 Sources` or `70-79 Assets`, with project notes holding:

- short summary;
- provenance link;
- decisions/deltas;
- active implications.

This keeps project folders agile.

## Risk 6 — Vault Log is growing into a long audit ledger

`00.03 Vault Log` is valuable but already long. It should remain chronological, but not become the main way to understand current state.

### Governance rule needed

Use Vault Log for meaningful changes only. Do not log every small note edit. For current state, dashboards and decision registers should be primary.

If `00.03` becomes too long, split by year or keep a rolling current log plus archive.

## Risk 7 — Sensitive data boundary failed once

`10.01 Xavier Home` contained provider/API key material. It was sanitized during this audit and a follow-up search found no remaining direct matches for the detected key patterns.

### Required follow-up

Paulo should assume any credential that ever lived in the vault may have been synced/backed up. Rotate/revoke the affected provider keys if they were real and active.

Governance implication:

- no secrets in Obsidian, even temporarily;
- scratch notes must not be used for credential handoff;
- root-level scratch notes need cleanup/quarantine.

## Risk 8 — Root-level scratch/plugin files violate the schema

Root files found:

- `[[20.99 Paulo Scratchpad - Do Not Process]]` — contains operational instructions involving a dashboard session token flow. It should not live at root and should be reviewed for sensitivity before filing or deletion.
- `[[Kanban Plugin Test 2026-07-04]]` — plugin-generated board file, probably test artifact.
- `coiso.md` — empty.

### Governance rule needed

Root should contain only:

- `AGENTS.md`;
- Obsidian/Syncthing internals;
- maybe a single `README` if intentionally used.

All scratch/test files should go to inbox or archive, then be deleted once processed.

## Recommended operating model

## Principle 1 — One object, one canonical owner

Each information object gets one owner:

- **Source/provenance** → `60-69 Sources`.
- **Concept/framework** → `40-49 Knowledge/41 Concepts`.
- **Academic literature map** → `37.04` or `40-49 Knowledge/42 Research` depending on scope.
- **Project decision** → project decision register.
- **Current project state** → project dashboard/tracker.
- **Task** → task board / tracker, not a permanent note unless substantial.
- **Procedure** → skill or operation/playbook.
- **Raw file** → `70-79 Assets` or external research file workspace.

Other notes link to owner and add only the local implication.

## Principle 2 — Preserve provenance, but do not duplicate the source everywhere

Source notes should contain:

- URL/file path;
- capture method;
- transcript/extract if needed;
- short summary;
- claims to verify.

Project notes should not copy the whole source. They should say:

- why this source matters;
- what it changes;
- where it should be used;
- what remains to verify.

## Principle 3 — Dashboards are for action, maps are for navigation, logs are for audit

Do not make one note do all three.

- Dashboard: current orientation and next actions.
- Map/index: where things are.
- Log: what changed historically.
- Decision register: what was decided and why.
- Source note: evidence/provenance.
- Concept note: reusable idea.

## Principle 4 — Intake has TTL

Intake entries should be reviewed and either promoted or closed.

Proposed statuses:

- `new`
- `triaged`
- `promoted`
- `source-only`
- `needs-verification`
- `archived`

No durable idea should live only in intake.

## Principle 5 — Project folders should stay light

Project folders should hold the living workbench, not every raw artifact.

For PhD:

- `37.01` dashboard;
- `37.02` phenomenon;
- `37.03` conceptual model;
- `37.04` literature map;
- `37.05` methodology;
- `37.09` decisions/open questions;
- `37.12` project tracker.

Large source documents, transcripts, and extracts should increasingly move to Sources/Assets with short project pointers.

## Recommended immediate actions

### High priority

1. **Rotate/revoke any provider keys that were ever stored in `10.01 Xavier Home`.** The note has been sanitized, but sync/backups may preserve history.
2. **Fix duplicate `37.10` ID.** Rename or relocate the approved thesis extract.
3. **Clean root files.** Move/delete `[[20.99 Paulo Scratchpad - Do Not Process]]`, `[[Kanban Plugin Test 2026-07-04]]`, and `coiso.md` after review.
4. **Add an explicit canonical-owner rule to `AGENTS.md` and `02.01 Vault Schema`.

### Medium priority

5. **Run a link cleanup pass.** Fix legacy `projects/...`, `syntheses/...`, `33.09 Draft Core-Guilherme...`, and Voice Lab relative links.
6. **Create a Source Register or strengthen `60-69 Sources` indexing.** Sources should be findable without hunting through project notes.
7. **Create a PhD source promotion routine.** Every source intake item gets promoted, verified, or closed.
8. **Review large notes.** Decide which large notes should become source/asset records vs active project notes.

### Lower priority

9. **Archive or rename duplicate content drafts.** Example: duplicate `Voice Lab - PhD Research Page Complete Draft` exists in both Knowledge/Syntheses and Voice Lab content.
10. **Update JDex `Last updated` and align media source path naming.**
11. **Consider annual/quarterly split of Vault Log later, not urgent.**

## Proposed rule patch for AGENTS.md

Add:

```markdown
## Canonical owner rule

Every durable information object should have one canonical owner note:

- 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.

Other notes should link to the owner and record only local implications. Avoid copying the same synthesis into multiple notes.
```

## Proposed rule patch for 02.01 Vault Schema

Add a section after filing rules:

```markdown
## 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. Project dashboards should point to owner notes; they should not duplicate source material or full syntheses.
```

## Governance conclusion

The vault is becoming powerful, but the current risk is real: without stricter ownership and promotion rules, Obsidian can become a rich but heavy archive rather than an agile operating system.

The fix is not fewer notes by default. The fix is clearer note roles:

- sources preserve evidence;
- concepts preserve reusable thinking;
- project notes preserve current working state;
- decision registers preserve commitments;
- dashboards preserve orientation;
- task boards preserve motion.

If we enforce that separation, the vault remains agile even as it grows.