> Public study copy. Original Xavier note path: `30-39 Projects/33 Xavier/33.15 Xavier System Public Explainer.md`. Secrets/credential-like values, if any, are redacted. --- title: Xavier System Public Explainer created: 2026-07-05 updated: 2026-07-05 type: synthesis status: draft freshness: current sources: - [[33.01 Xavier Operating Model]] - [[02.01 Vault Schema]] - [[02.05 Transversal Knowledge Governance and OKF-lite Freshness Model]] - [[33.06 Xavier Memory Dashboard]] - [[11.05 Kanban Operating Model]] - [[10.02 Relationship Dashboard]] tags: [xavier, operating-system, obsidian, hermes, governance, public-explainer] --- # 33.15 Xavier System Public Explainer > Draft public-facing explainer. Purpose: describe, in human terms, what the Paulo ↔ Xavier/Hermes system is, how it is organized, and how it governs memory, projects, knowledge, decisions, and work. # Xavier: an operating partnership between a human, an AI agent, and a living knowledge system Most people still use AI as a conversation box. They ask a question, receive an answer, maybe copy part of it somewhere, and then start again the next day. The interaction is useful, but shallow. It has little memory, little structure, and very little institutional continuity. The AI may be powerful, but the work disappears into chat history. Xavier is an attempt to build something different. It is not just a chatbot. It is not just a note-taking system. It is not just automation. It is a governed operating partnership between Paulo, an AI agent powered by Hermes, and a durable Obsidian workspace that functions as the shared memory, project state, decision register, source archive, and operational map. The core idea is simple: > A human should not have to rebuild context every time he speaks with an AI. But the implementation is not simply “give the AI more memory”. More memory can become more confusion. It can become stale, bloated, contradictory, or unsafe. The real challenge is not remembering everything. The challenge is knowing what deserves to be remembered, where it belongs, how it should be maintained, and when it should be ignored. Xavier is the system we are building around that problem. It combines: - a human decision-maker, Paulo; - an AI operating partner, Xavier/Hermes; - a durable Obsidian vault; - a Johnny.Decimal address system; - decision registers; - project dashboards; - source and knowledge layers; - runtime memory mirrors; - reusable skills; - watchdogs and audits; - messaging channels; - task boards; - and a growing governance model for avoiding data rot. It is an AI-enabled operating system for one person’s projects, research, work, and thinking. Not in the sense of replacing the human. In the sense of giving the human a persistent operational partner that can hold context, execute tasks, preserve decisions, and keep the system legible over time. ## The problem: AI without continuity is not enough A normal AI conversation has three weaknesses. First, it is episodic. You can have a brilliant conversation today and lose most of its practical value tomorrow. Unless the output is deliberately captured, the useful reasoning remains trapped in a chat transcript. Second, it is context-fragile. If the user has to explain the same project, constraints, preferences, and prior decisions every time, the system never compounds. Every session starts too close to zero. Third, it is governance-poor. AI systems are good at generating text, but poor governance turns that into sprawl. Notes multiply. Summaries duplicate each other. Project state gets mixed with sources, temporary tasks, and old decisions. The system looks like memory, but behaves like sediment. Xavier exists because the useful question is not: > How do we make the AI remember more? The useful question is: > How do we build a system where human intention, AI execution, and durable context can compound without becoming chaotic? That is a governance problem as much as a technology problem. ## The basic architecture The system has three main layers. ### 1. The human layer Paulo sets direction, constraints, taste, priorities, and final decisions. He decides what matters. He approves strategic shifts. He challenges the system when it becomes too complex, too heavy, too rigid, or too self-confident. This matters because Xavier is not designed as an autonomous authority. It is designed as an operating partner. The system is useful only if it keeps Paulo in control while reducing the cognitive cost of managing many parallel projects. ### 2. The agent layer Xavier/Hermes researches, drafts, implements, edits, compares, checks, documents, and maintains state. The agent can use tools: file operations, terminal commands, browser access, scheduled jobs, messaging, memory, skills, and integrations. But tool use is not the point. The point is that the agent operates inside a governed workspace rather than only inside a chat. Xavier does not merely answer. It can update the vault, create decision notes, inspect current state, run audits, preserve procedures, and verify that changes actually happened. ### 3. The durable workspace layer Obsidian is the human-readable source of truth. The vault stores project state, decisions, dashboards, research synthesis, source material, operating notes, task boards, runbooks, and governance rules. It is plain Markdown, readable by humans and agents, syncable across machines, and resilient against platform lock-in. The working metaphor is: > Obsidian is the workspace. Johnny.Decimal is the address system. Xavier is the maintainer. That sentence captures the philosophy. The AI is not the memory. The AI maintains and uses a memory system that the human can inspect. ## Why Obsidian matters Obsidian is not used here as a decorative notebook. It is the durable operating surface. It provides several properties that are important for a human-AI partnership: - files are plain Markdown; - the human can read and edit them directly; - notes can link to other notes; - backlinks show how material is being used; - sections and blocks can be referenced precisely; - the folder structure remains visible; - sync and backup can be handled independently; - the system can survive beyond one app or AI provider. The vault is not simply “notes about projects”. It is the place where the partnership becomes auditable. When a decision is made, it goes into a decision register. When a project changes direction, the dashboard or project note changes. When a procedure becomes reusable, it becomes a skill or runbook. When source material might matter later, it is preserved with provenance. When temporary traffic is not worth keeping, it is allowed to disappear. This is how the system avoids the common trap of AI work: producing impressive outputs with no durable operational memory. ## Johnny.Decimal: the address system A large knowledge system needs addresses. The Xavier vault uses a Johnny.Decimal-inspired structure. The current top-level map is: ```text 00-09 System # schema, indexes, governance, logs, templates 10-19 Dashboard # home, relationship dashboard, project overview, task boards 20-29 Inbox # temporary captures and unprocessed intake 30-39 Projects # active projects, decisions, tasks, reports, outputs 40-49 Knowledge # reusable concepts, syntheses, frameworks 50-59 Operations # Hermes, VPS, sync, backups, runbooks 60-69 Sources # source/provenance material 70-79 Assets # screenshots, attachments, media, support files 90-99 Archive # old or superseded material ``` The purpose of this structure is not bureaucracy. It is shared orientation. Paulo and Xavier can refer to short addresses like `33.12`, `37.09`, or `02.05` in conversation. That makes the system navigable in chat, in Obsidian, and in future sessions. The address system gives every durable object a place. But importantly, the folder is not expected to express every possible meaning of the note. A study can be useful for the PhD, teaching, executive work, and public writing. It still needs one canonical place. That place is determined by what kind of object it is, not by every context where it might be useful. This leads to one of the central rules of the system: > Folders say who owns the note. Links say where it is useful. ## The transversal knowledge model As the system grew, a problem became obvious. Some material serves several themes at once. A paper might matter to the PhD, to a class, to a future article, and to Paulo’s executive work. A video might provide an example for teaching, an intuition for research, and a warning for organizational practice. A quote might become a writing seed, a conceptual hook, and a personal operating principle. If that material is placed only inside one project folder, the system loses agility. If it is copied into several project folders, the system creates data rot. One version gets updated, another does not. The same source slowly becomes several inconsistent summaries. The solution is not to abandon folders. The solution is to separate ownership from use. The current model is: > JD gives the address. Links give the network. OKF-lite gives freshness. Or, more operationally: > Folders say who owns the note. Links say where it is useful. Metadata says whether it is still reliable. In practice: - `60-69 Sources` stores source and provenance material; - `40-49 Knowledge` stores interpreted concepts and reusable frameworks; - `30-39 Projects` stores situated uses, decisions, outputs, and implications. A source lives once. Concepts interpret it. Projects link to it. For example, a study about AI and tacit learning loss would live once in the source layer. A reusable concept note might interpret the idea as “tacit learning loss under automation”. The PhD evidence map, teaching notes, and executive practice notes would then link to the source or to a specific finding, section, or block. Obsidian makes this powerful because links do not have to point only to whole notes. They can point to sections and blocks: ```markdown [[62.xx Study Title]] [[62.xx Study Title#Key findings]] [[62.xx Study Title#^finding-junior-learning]] ``` This means the vault can preserve one canonical source while allowing many precise uses. Backlinks then become a living usage graph. When opening a source note, Paulo or Xavier can see where it is used: PhD, Academia, Voice Lab, Career Architecture, teaching material, or a future writing project. That is the advantage of treating Obsidian not as a folder hierarchy, but as a linked knowledge environment. ## OKF-lite: freshness without bureaucracy The system also borrows a lesson from the Open Knowledge Format idea: important knowledge objects should be plain files with enough metadata to remain interpretable over time. But Xavier does not convert the whole vault into a rigid schema. That would create friction and make the system too heavy. Instead, it uses an OKF-lite approach for critical maintained notes. For notes where stale information would create confusion, frontmatter may include: ```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: [] ``` This is not applied everywhere. It is applied where it matters: - project dashboards; - decision registers; - source intake trackers; - important syntheses; - operations and runbooks; - PhD, Voice Lab, and Career Architecture notes that drive decisions; - reusable concept notes with ongoing implications. The principle is: > The antidote to data rot is not more structure everywhere. It is enough structure on the notes that matter. OKF-lite helps answer: - What kind of note is this? - Is it active, draft, archived, or superseded? - When was it last meaningfully updated? - When should we review it again? - Is it current, watch, or stale? - What source or resource does it point to? This lets the system stay light while giving Xavier a way to detect aging context. ## Decisions are first-class objects One of the most important parts of the system is decision capture. A decision is not the same as a summary. A summary says what was discussed. A decision says what changed. Xavier decision notes usually capture: - Decision; - Rationale; - Implication; - Status; - Source; - Related notes; - sometimes options considered and rejected. This matters because projects often waste energy by re-opening already closed options. The system therefore preserves not only what was chosen, but also why alternatives were rejected. For example, the decision to use JD + Obsidian links + OKF-lite is preserved because it will likely be revisited. It is not just a casual design preference. It is a governance model for how the entire vault avoids becoming either too siloed or too chaotic. The decision register makes the system cumulative. Instead of asking “what did we say last time?”, Paulo or Xavier can ask “what did we decide, why, and is it still active?” That is a different standard of continuity. ## Memory is layered, not dumped The system distinguishes several kinds of memory. Runtime memory is compact. It stores facts that should influence future sessions immediately: Paulo’s preferences, durable operating conventions, and stable environmental facts. Obsidian stores long-form context: dashboards, decisions, project state, reports, maps, source material, and governance notes. Skills store procedures: reusable workflows, commands, pitfalls, verification steps, and operational playbooks. Session history is used for recall on demand. It is searchable, but not treated as the main source of truth. The classification is simple: - runtime memory: small, durable, behavior-relevant; - Obsidian: long-form continuity and human-readable state; - skills: reusable procedures; - session history: recall when needed; - nowhere: temporary, obvious, stale, sensitive, or low-value information. This layered approach prevents a common failure mode: stuffing everything into memory and then having the AI become over-conditioned by stale or irrelevant details. There are also memory mirrors in Obsidian. These make runtime identity, user profile, and operational memory visible to Paulo. But the mirror direction is deliberate: runtime can be reflected into Obsidian for auditability, while editing an Obsidian mirror does not automatically rewrite runtime memory. That preserves human visibility without creating accidental feedback loops. ## Dashboards are operating surfaces, not encyclopedias The vault has dashboards, but their job is not to list everything. A dashboard should show what matters now: - active projects; - current direction; - key decision notes; - task boards; - important links; - next actions. Dashboards become useless if they turn into exhaustive indexes. The system therefore distinguishes between dashboards, indexes, source archives, concept notes, and decision registers. A good dashboard is an operating surface. It helps Paulo or Xavier resume work quickly. It should not try to contain the whole project. The `00.01 JDex` is the master navigation map. The relationship dashboard shows the collaboration model. Active project dashboards show the current state of each project. The vault log records meaningful changes. The decision registers preserve decisions. Each layer has a different job. ## Projects in the system The system currently supports several kinds of work. Some are product or software projects, such as ShonenSOL. Some are public-facing research or platform projects, such as Voice Lab. Some are long-term intellectual or professional architectures, such as Career Architecture, which integrates Paulo’s executive management practice, PhD research, teaching, and possible future organizational intervention work. Some are research projects, especially the PhD workspace, which has its own dashboard, research question, conceptual model, literature map, methodology, writing notes, supervision notes, data/analysis log, source intake, outputs, project management tracker, and thesis idea capture log. Some are teaching or academic operations, under Academia. Some are personal or life operations, with privacy boundaries. Some are research themes that may or may not become formal projects, such as energy/proof-of-work as a lens for history and economy, or psychology/consciousness themes. The system does not assume that all work has the same shape. It gives each area enough structure to be recoverable, but not so much that every thought becomes a project. ## Task management: visible boards, durable outcomes Tasks are handled differently from decisions. The system uses a Markdown-first Kanban approach, currently oriented around Obsidian task boards and tags. The preferred model is a human-visible board that keeps tasks as ordinary Markdown checkboxes, with status tags and area tags. This matters because task traffic is not memory by default. A task board can contain active work, blocked items, review items, and recently completed tasks. But completed trivial tasks should not become permanent memory. Durable outcomes should be promoted to the correct place: - decisions to decision registers; - procedures to skills or runbooks; - source material to Sources; - project state to dashboards or trackers; - results to result logs or project outputs. This distinction keeps the system from confusing activity with knowledge. ## Communication channels The system also separates communication channels by role. Telegram is the Paulo-facing channel by default. It is used for direct conversation, important escalations, and low-noise human attention. Discord is treated as the agent control plane: a better place for lower-priority operational traffic, logs, threads, multi-agent activity, and domain workstreams. Obsidian remains the durable source of truth. Discord and Telegram can generate decisions, but decisions do not become durable merely because they were said in a chat. They must be promoted into Obsidian with the same quality bar. This prevents chat from becoming fake memory. ## Operations, sync, and resilience Xavier also has an operations layer. The vault includes notes for Hermes itself, sync, backups, replication, gateway operations, messaging targets, and service recovery. It distinguishes between human-readable operating notes and secret material. Secrets do not belong in Obsidian. They also do not belong in runtime memory, skills, logs, or summaries. The system is designed to be recoverable. There are backup and replication notes, sync notes, and watchdogs. Some watchdogs are intentionally quiet: they only alert when there is a meaningful problem. This matches the general philosophy of the system: support the human without creating noise. The operational layer is not glamorous, but it matters. A personal AI operating system is only useful if it can survive machine changes, sync failures, stale configuration, and future migration. ## Governance as an evolving practice A key feature of Xavier is that governance is not treated as finished. The system has already evolved through several corrections: - separating runtime memory from Obsidian long-form memory; - separating sources from assets; - introducing Johnny.Decimal addresses; - adding structural-edit preflight rules; - adding vault watchdogs; - clarifying that multi-use material should live once and circulate through links; - introducing OKF-lite freshness for critical notes; - distinguishing dashboards from indexes; - distinguishing source archives from interpreted knowledge; - distinguishing task traffic from durable decisions. This is not a static template. It is a living operating model. The important thing is that changes to the model are themselves documented. When Paulo challenges the architecture, the resulting decisions become part of the system. That is how the system learns without hiding its own history. ## What makes this different from ordinary productivity systems Many productivity systems organize tasks. Many note systems organize information. Many AI systems generate answers. Xavier tries to integrate four things that are often separate: 1. **Work execution** — the agent can actually do things. 2. **Durable project state** — work is preserved outside chat. 3. **Decision continuity** — choices and rejected options are recorded. 4. **Knowledge governance** — sources, concepts, projects, tasks, and operations are separated but linked. The system is not about having more notes. It is about making context usable across time. The value is compounding. A decision made today becomes part of tomorrow’s operating environment. A source captured once can support many future uses. A procedure solved once can become a skill. A project dashboard can let the next session resume from state rather than memory. A governance correction can prevent a whole class of future errors. This is what ordinary AI chat does not provide by default. ## The human role remains central The system is deliberately not built around the fantasy that the AI should autonomously manage everything. Paulo remains the source of direction, taste, risk tolerance, and judgment. Xavier can propose, compare, execute, document, and maintain. But the system is designed so that Paulo can inspect the state, challenge the model, and redirect the architecture. This is important. An AI operating partner must be useful without becoming opaque. The Obsidian vault is therefore not only memory. It is also a control surface. It makes the partnership visible. ## The simplest summary Xavier is a governed personal operating system built around a human-AI partnership. It uses: - Hermes for agent capability; - Obsidian for durable human-readable state; - Johnny.Decimal for navigation; - links and backlinks for transversal knowledge; - decision registers for continuity; - skills for reusable procedures; - task boards for active work; - watchdogs for quiet operational safety; - OKF-lite metadata for freshness where it matters. Its core rules are: > Obsidian is the workspace. Johnny.Decimal is the address system. Xavier is the maintainer. > JD gives the address. Links give the network. OKF-lite gives freshness. > Runtime memory stays compact. Long-form context belongs in Obsidian. Procedures belong in skills. Decisions belong in registers. > A source lives once. Concepts interpret it. Projects use it. > Dashboards show current state. Decision registers preserve choices. Sources preserve provenance. Knowledge notes preserve reusable thinking. That is the system. It is not finished. It is deliberately evolving. But it already has a clear shape: a practical architecture for making AI collaboration cumulative, inspectable, recoverable, and useful across real work, research, teaching, and life.