Vitals Knowledge Vault

MiniMax Vault Conversion Skill

9 min read

MiniMax Vault Conversion Skill

Purpose

This file is the high-standard operating skill for MiniMax workers converting Vitals research into Obsidian vault notes.

Use it when transforming:

  • research/ packets
  • skills/knowledge-base/ long-form compound docs
  • existing vault notes that need upgrading

into:

  • retrieval-friendly Obsidian hub notes
  • reusable mechanism notes
  • biometrics / detection / recovery notes
  • MOC updates

This skill is designed to push output quality as high as possible while preserving speed and scale.

Core mission

Build a vault that is:

  • easy for an LLM to retrieve from
  • easy for a human to scan quickly
  • semantically clean
  • resistant to duplication and ontology drift
  • useful for Vitals product reasoning, coaching, and biometric interpretation

You are not writing articles for entertainment. You are building a knowledge graph for retrieval and decision support.

The 3-layer architecture

Always respect the role of each layer.

Layer 1 — Source layer

Location:

  • research/

Contains:

  • worker JSON packets
  • raw evidence pulls
  • briefs
  • crawls
  • partials
  • CSVs

Do not try to make this pretty. This is the provenance and audit layer.

Layer 2 — Deep research library

Location:

  • skills/knowledge-base/

Contains:

  • long-form canonical research docs
  • compound docs
  • protocol docs
  • research plans

This is the synthesis layer. Use it as source material. Do not duplicate it mechanically.

Layer 3 — Retrieval graph

Location:

  • obsidian/Vitals-KB/

Contains:

  • compact hub notes
  • MOCs
  • mechanism notes
  • biometrics notes
  • recovery / risk notes
  • detection-model notes
  • interaction notes

This is your output layer. Optimize for retrieval and graph clarity.

Non-negotiable principles

1. Build the smallest useful graph

Do not explode the vault. A concept gets its own note only if it is:

  • reusable across multiple notes
  • independently retrievable by a human or LLM
  • likely to matter again later

If it is merely interesting, keep it inside the hub.

2. Reuse existing notes aggressively

Before creating a new note, check whether the concept already exists in the vault. If an existing note can carry the concept, link to it instead of duplicating it.

3. Separate evidence from projection

Never blur:

  • source-backed evidence
  • mechanistic inference
  • product relevance
  • wearable speculation

Keep these distinct.

4. Prefer semantic clarity over completeness theater

Do not create more notes just to appear comprehensive. The goal is usefulness, not note count.

5. Tone must stay sober

Avoid hype. Avoid guru language. Avoid promotional framing. Avoid “10/10”, “ultimate”, “revolutionary”, “magic”, “perfect”, unless directly quoted from a source and explicitly framed.

6. Make Vitals relevance explicit

For notes that matter to Vitals, explicitly say why. That means:

  • body composition
  • HRV
  • sleep
  • recovery
  • readiness
  • glucose
  • confounders
  • detection logic
  • coaching implications

7. Never orphan a note

Every new note must be linked to at least one MOC or the Vitals Knowledge Map.md. If a note cannot be discovered by walking the graph from a map, the graph is broken.

If you mention a concept that should be a mechanism note eventually, but isn’t worth building right now because only one compound uses it, wrap it in wikilinks (e.g., [[Glycemic Variability]]) but do not create the file. This leaves a “ghost link” in Obsidian that we can fill in later when a second compound needs it.

Output standards by note type

A. Hub notes

Use for:

  • important substances
  • important compounds
  • important peptides
  • important stack anchors

Preferred structure

---
[id/frontmatter]
---
 
# [Topic]
 
## TL;DR
 
## Why it matters for Vitals
 
## Key facts
 
## Mechanism summary
 
## What the current evidence suggests
 
## Likely wearable / Vitals relevance
 
## Risks and uncertainty
 
## Best stack context
 
## What stays inside this hub
 
## Related notes

Not every hub must have every section, but this is the preferred default.

What a good hub does

It answers:

  • what is it?
  • why does it matter?
  • how does it work?
  • what is the strongest evidence?
  • what is likely vs still uncertain?
  • what are the most important graph links?

What a hub should NOT do

  • replicate the long-form research doc
  • become a literature dump
  • bury practical relevance in paragraph 19
  • include company trivia unless truly decision-relevant

B. Mechanism notes

Use mechanism notes only when the mechanism is truly reusable.

Good candidates

Bad candidates

  • one compound’s fragment metabolite
  • proprietary formulation details
  • structural substitutions relevant only to one peptide
  • ultra-specific subpathways with no future reuse

A mechanism note should:

  • define the concept cleanly
  • describe why it matters
  • connect multiple compounds or substances
  • provide retrieval anchors, not essay sprawl

C. Biometrics notes

Use for patterns Vitals may infer or interpret. Examples:

  • HRV signatures
  • REM suppression
  • cardiovascular signatures
  • sleep architecture

Must answer:

  • what signal changes?
  • how reliable is it?
  • what confounds exist?
  • what compounds/substances link here?

D. Recovery / risk notes

Use when the consequence itself is retrieval-worthy. Examples:

  • hangover mechanism
  • psychosis risk
  • withdrawal
  • CHS
  • crash states

These should be practical, not generic medical essays.

E. Detection-model notes

Use for wearable inference and confound logic. Must include:

  • what features matter
  • what features mislead
  • realistic certainty limits
  • route / dose / timing caveats when relevant

F. Interaction notes

Only create an interaction note when the interaction is independently worth retrieving.

Good examples:

  • cannabis peptide interactions
  • alcohol peptide interactions

Bad examples:

  • trivial “they both exist” links
  • speculative overlaps with no practical consequence

Folder rules

  • 00-Maps/ → MOCs, maps, workflow docs
  • 01-Substances/ → substances and non-peptide compound hubs when using current convention
  • 02-Mechanisms/ → reusable mechanism notes
  • 03-Biometrics/ → biometric signature notes
  • 04-Protocols-and-Recovery/ → recovery, withdrawal, crash, risk notes
  • 05-Detection-Models/ → detection logic
  • 06-Peptides-and-Interactions/ → peptide hubs and interaction notes under current vault convention

If unsure, prefer consistency with the existing vault over inventing a new convention mid-batch.

Naming rules

Use durable, retrieval-friendly names.

Good

  • Rapamycin.md
  • Urolithin A.md
  • Mitophagy.md
  • CRF2 receptor.md
  • Cannabis detection model.md
  • Cannabis peptide interactions.md

Avoid

  • essay titles
  • title variants for the same concept
  • inconsistent use of and, &, vs
  • over-clever names

Canonical patterns

  • MOCs: [Topic] MOC.md
  • Detection notes: [Topic] detection model.md
  • Interaction notes: [Topic] peptide interactions.md or [Topic] interactions.md
  • Mechanism notes: short concept-first names

Evidence handling rules

You must distinguish:

A. Strong source-backed findings

Examples:

  • human RCT outcomes
  • replicated clinical signals
  • well-supported mechanism statements

B. Mechanistic inference

Examples:

  • likely implications drawn from pathway logic
  • plausible stack effects not directly tested

C. Wearable / Vitals projection

Examples:

  • likely HRV effect
  • expected readiness confound
  • probable body-composition interpretation

Preferred phrases

  • “the current evidence suggests”
  • “the strongest signal in the source corpus is”
  • “this is still mostly projection”
  • “confidence level: low / moderate / high”
  • “human evidence is limited”

Avoid

  • pretending preclinical data = human certainty
  • copying speculative source language uncritically
  • using strong claims without confidence framing

Vitals framing rules

For relevant topics, explicitly include Why it matters for Vitals.

This section should say things like:

  • what biometric signal may move
  • what body-composition issue matters
  • what coaching logic is affected
  • what confounds wearable interpretation
  • whether a compound changes recovery without changing true fitness

This is one of the highest-value differences between a generic summary and a Vitals note.

Comparison rules

When useful, compare new notes to existing notes already in the vault.

Examples:

  • XW4475 vs Retatrutide vs SLU-PP-332
  • NMN NAD+ vs NADH NAD+ disruption
  • Rapamycin vs Urolithin A via Mitophagy
  • Lion’s Mane vs Noopept Semax Selank via BDNF NGF induction

Good comparisons improve retrieval and graph understanding. Bad comparisons add clutter.

Shared-note creation test

Before creating a new note, ask these 5 questions:

  1. Will at least 2 existing or likely-future notes link here?
  2. Would a human plausibly search for this concept directly?
  3. Would an LLM retrieval system benefit from this as its own chunk?
  4. Is this more than one compound’s implementation detail?
  5. Will the note remain useful in 2 months?

If fewer than 3 answers are “yes”, do not create the note. Keep it inside the hub.

Editing existing notes

When notes already exist:

  • prefer upgrading in place
  • do not create title variants
  • do not create “v2” duplicate notes
  • preserve the stronger structure
  • improve tone, retrieval clarity, Vitals framing, and links

If two notes overlap:

  • choose a canonical note
  • merge stronger material into it
  • update backlinks
  • remove or archive the duplicate

Anti-hype rules

Do not let the note sound like a pitch deck. Cut or rewrite:

  • “groundbreaking”
  • “ultimate stack”
  • “competition-level” unless critically necessary and tightly framed
  • “10/10” ratings
  • exaggerated certainty

If a claim sounds exciting, make sure it is also precise.

What to keep inside hubs

Usually keep these inline:

  • formulation logistics
  • proprietary engineering details
  • obscure metabolite names
  • company development trivia
  • niche sub-mechanisms only one compound uses
  • product sourcing detail unless central to real-world use

Standalone notes are for reusable graph nodes, not interesting leftovers.

Final QA before finishing a batch

Check all of these:

Naming / duplication

  • no duplicate concepts
  • canonical naming used
  • no drift from established folder conventions

Graph quality

  • smallest useful graph
  • no note explosion
  • mechanism notes truly reusable
  • important notes linked into maps / MOCs

Retrieval quality

  • titles match likely retrieval language
  • high-signal claims preserved
  • comparison links present where useful
  • notes are semantically chunked

Tone / evidence

  • hype minimized
  • uncertainty visible
  • evidence vs projection separated
  • preclinical not overstated

Vitals relevance

  • explicit when relevant
  • wearable / coaching implications surfaced
  • confounds visible

Deliverable expectations for each batch

Return a concise structured summary containing:

  • scope chosen
  • files created
  • files updated
  • notes created count
  • graph strategy
  • duplicate/conflict notes encountered
  • concepts deliberately kept inside hubs
  • important reusable links added

This summary should help a reviewer understand your judgment, not just your file count.

Ideal behavior

The best MiniMax output should feel like this:

  • more precise than a normal summary
  • less bloated than a research monograph
  • more cautious than a hypey biohacker note
  • more graph-aware than a normal markdown doc
  • more useful for retrieval than for literary reading

That is the target.

Graph View