> Public study copy. Original Xavier note path: `00-09 System/02 Vault Governance/02.05 Transversal Knowledge Governance and OKF-lite Freshness Model.md`. Secrets/credential-like values, if any, are redacted.

---
title: Transversal Knowledge Governance and OKF-lite Freshness Model
created: 2026-07-05
updated: 2026-07-05
type: governance
status: active
tags: [xavier, governance, obsidian, zettelkasten, okf-lite, data-rot]
---

# 02.05 Transversal Knowledge Governance and OKF-lite Freshness Model

> Status: active governance model / evolving implementation.
> Scope: how Xavier handles material that serves multiple themes, while preserving Johnny.Decimal navigation, Obsidian link intelligence, and data-rot control.

## Core decision

Xavier will not force multi-use material into the first project where it appears.

Instead, the vault uses a three-layer model:

1. **Johnny.Decimal gives administrative ownership.**
2. **Obsidian links/backlinks/block links give intellectual and contextual circulation.**
3. **OKF-lite metadata gives freshness, reviewability, and auditability for critical maintained notes.**

Short rule:

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

Operational rule:

> Folders say who owns the note. Links say where it is useful. Metadata says whether it is still reliable.

## Why this decision was needed

Paulo identified a recurring problem: a study, article, video, quote, or concept often serves several contexts at once:

- PhD research;
- teaching/aulas;
- executive work;
- Voice Lab;
- career architecture;
- future applied organizational intervention;
- public writing or conference material.

If the material is filed under only one project, it becomes harder to retrieve and maintain for the other contexts. If it is copied into every project, the vault creates redundancy and data rot.

This model keeps one canonical owner while allowing many contextual uses.

## Relationship to Zettelkasten

The model borrows from the Zettelkasten distinction between capture, sources/reference material, and knowledge notes.

Mapping in the Xavier vault:

- `20-29 Inbox` = temporary capture / buffer;
- `60-69 Sources` = reference/source archive;
- `40-49 Knowledge` = note archive for reusable concepts, frameworks, and Xavier/Paulo syntheses;
- `30-39 Projects` = situated use, decisions, outputs, and project-specific implications;
- `10-19 Dashboard` = operational navigation;
- `00-09 System` = governance and schema;
- `50-59 Operations` = Hermes/Xavier infrastructure and runbooks.

Important boundary:

> `60-69 Sources` is not the whole Zettelkasten. It is the source/reference layer. Knowledge emerges when sources are interpreted into `40-49 Knowledge` and then applied through project maps and decisions.

## Relationship to OKF-lite

OKF-lite is not a replacement for Johnny.Decimal or Zettelkasten practice.

It is a small metadata layer, inspired by Google's Open Knowledge Format pattern, used selectively to reduce data rot in critical maintained notes.

OKF-lite should be applied to notes where stale state would create real confusion, such as:

- project dashboards;
- decision registers;
- source intake trackers;
- important syntheses;
- operations/runbooks;
- PhD/Voice Lab/Career notes that drive decisions;
- reusable concept notes with ongoing project implications.

It should not be forced across the whole vault.

Avoid heavy frontmatter on:

- bulky raw transcripts;
- assets;
- scratchpads;
- historical logs;
- low-value transient notes;
- old notes unless they become active again.

## Canonical ownership model

Every durable information object should have one canonical owner note.

Default ownership:

- original source/provenance → `60-69 Sources`;
- reusable idea/concept/framework → `40-49 Knowledge`;
- project use/application → relevant `30-39 Projects` note;
- project decision → relevant decision register;
- current state → dashboard/tracker;
- task → task board/tracker;
- procedure → Hermes skill or operations runbook.

Other notes should link to the owner and record only local implications.

## Multi-use source pattern

Example: one study about AI, tacit learning, and organizational capability.

Canonical source:

```text
60-69 Sources/62 Papers/62.xx Study - AI and Organizational Learning Loss.md
```

Reusable concept:

```text
40-49 Knowledge/41 Concepts/41.xx Tacit Learning Loss under Automation.md
```

Project/contextual uses:

```text
30-39 Projects/37 PhD Research/37.xx Evidence Map.md
30-39 Projects/38 Academia/38.xx Teaching Use Cases.md
30-39 Projects/36 Career Architecture/36.xx Executive Practice Evidence.md
```

The source is not copied into all projects. Projects link to the source, concept, section, block, or paragraph that matters.

## Link and block-link practice

Use Obsidian links to avoid folder silos.

Preferred levels:

- note link: `[[62.xx Study Title]]`;
- section link: `[[62.xx Study Title#Key findings]]`;
- block link: `[[62.xx Study Title#^finding-junior-learning]]`.

Use block links for reusable, stable claims or excerpts that multiple contexts may cite.

Avoid copying a finding into five project notes. Create or preserve one canonical finding and link to it from the relevant project maps.

## OKF-lite frontmatter pattern

For critical maintained notes, use a lightweight frontmatter pattern:

```yaml
---
title: Note title
type: dashboard | decision-log | source | synthesis | operation | concept | project-map
status: active | draft | archived | superseded
updated: YYYY-MM-DD
review_after: YYYY-MM-DD
freshness: current | watch | stale
resource: optional canonical URL/path/asset
sources: []
tags: []
---
```

Field meanings:

- `type`: what kind of maintained object this is.
- `status`: lifecycle state.
- `updated`: last meaningful update.
- `review_after`: date after which freshness should be checked.
- `freshness`: current confidence state.
- `resource`: canonical external object or internal asset, when applicable.
- `sources`: supporting Obsidian source notes or external citations.
- `tags`: optional retrieval aids, not a substitute for links.

## Freshness policy

Use freshness only where it creates value.

Suggested states:

- `current`: safe to use as active context.
- `watch`: probably useful, but depends on changing external conditions or pending review.
- `stale`: should not be used for decisions without checking.

Review dates should be pragmatic, not bureaucratic:

- operations/runbooks: shorter review windows when infrastructure is changing;
- project dashboards: review when project cadence requires;
- concept notes: review only if actively used in project decisions;
- sources: review when they are used as evidence, superseded, or part of active research.

## Project-map pattern

A project should not absorb all source material. It should maintain a map of relevant uses.

Example entry:

```markdown
## AI and tacit learning erosion

- Source: [[62.xx Study - AI and Organizational Learning Loss#^finding-junior-learning]]
- Concept: [[41.xx Tacit Learning Loss under Automation]]
- Use: supports the argument that AI may weaken apprenticeship-style knowledge transfer.
- Context: PhD literature review / organizational learning.
- Freshness: source current; interpretation watch.
```

## Ambiguous intake / source-box triage

When Paulo shares a note, article, screenshot, post, link, or idea and its filing status is ambiguous, Xavier should not silently create a new Johnny.Decimal note.

Default behavior:

1. Read/analyze the material and give Paulo the useful reflection as normal.
2. If it appears worth preserving but the destination is not obvious, state the recommended filing level and why.
3. Present numbered options with short descriptions, usually 1-4 options.
4. Wait for Paulo's choice before creating, moving, consolidating, or deleting notes, unless Paulo explicitly asked Xavier to decide and act.

Suggested option pattern:

```markdown
Paulo, isto parece-me uma nota de arrumação dúbia. Eu punha em [recommended level] porque [reason].

1. Não guardar — fica só na conversa/session search.
2. Source Box — guardar 3-5 linhas em `61.00 Article Source Box` ou equivalente.
3. Nota de fonte própria — criar nota individual em `60-69 Sources` porque será relida/citada/auditada.
4. Promover para Knowledge/Project — criar/atualizar uma nota interpretada (`40-49 Knowledge`) ou aplicação concreta (`30-39 Projects`).
```

Use fewer options when the decision is obvious. The point is to preserve Paulo's control over borderline filing decisions and avoid vault clutter.

## Decision implications

- Do not abandon Johnny.Decimal. It remains the vault's address and governance system.
- Do not classify sources by every possible topic. Classify by object type and canonical ownership.
- Do not duplicate source material into project folders.
- Use backlinks and links to recover cross-context use.
- Use concept notes for interpreted knowledge, not just source summaries.
- Use OKF-lite only for critical maintained notes where data rot matters.
- Treat `60-69 Sources` as a source/reference layer and prefer Source Box entries over one-file-per-link when evidentiary value is low.
- For ambiguous intake, ask Paulo with numbered filing options before creating or restructuring notes.
- Treat this as an evolving model. Future changes should be captured here, in [[02.01 Vault Schema]], [[33.12 Xavier Decision Register]], and [[00.03 Vault Log]] when meaningful.

## Non-decisions

- This does not approve a full OKF conversion of the Xavier vault.
- This does not require frontmatter on every existing note.
- This does not require moving all current project sources immediately.
- This does not replace the current structural-edit preflight in [[02.04 Vault Governance Guardrails and Night Run]].
- This does not make `60-69 Sources` the only important knowledge layer. It remains the source/reference layer.

## Implementation status

Initial implementation on 2026-07-05:

- Created this governance note.
- Linked this model from [[00.01 JDex]].
- Updated [[02.01 Vault Schema]] with the JD + Links + OKF-lite rule.
- Added the decision to [[33.12 Xavier Decision Register]].
- Logged the governance change in [[00.03 Vault Log]].
- Patched the `obsidian` skill reference so future sessions recall the model.

Future implementation options:

- Add OKF-lite frontmatter to a small pilot set of critical notes.
- Update the nightly watchdog to detect expired `review_after` only on notes that opt into OKF-lite.
- Create or update project evidence/use maps for PhD, Academia, and Career Architecture.
- Decide whether source notes need stable block IDs for high-value reusable findings.

## Related

- [[02.01 Vault Schema]]
- [[02.02 Vault Data Governance Audit 2026-07-04]]
- [[02.04 Vault Governance Guardrails and Night Run]]
- [[33.12 Xavier Decision Register]]
- [[00.01 JDex]]
- [[00.03 Vault Log]]