Your "Decisions" folder is missing the decisions.

If you are searching for "Obsidian decision journal" or wondering how to track product experiments in a vault, this comparison is for you. Obsidian users are some of the most thoughtful documenters in software. Plain-text durability, local-first storage, no cloud lock-in, the daily note as a deliberate practice. The values match what a serious experiment journal needs. There is one thing missing, and it cannot be added with a plugin: the actual A/B test. Vault notes can record the hypothesis and the lesson learned. They cannot prove the hypothesis was tested at all. This guide covers what Obsidian does brilliantly, the structural reason a plugin will never close the gap, and how Blazeway sits underneath the vault as the proof layer.

A vault stores what you wrote. Blazeway stores what your visitors did. Both matter, both are real, both answer opposite questions. Obsidian links your thinking. Blazeway provides the evidence the thinking was reacting to. The vault crowd believes in compounding knowledge, durability, and plain text. They are right. They have also built a system that compounds beautifully on the thinking side and barely at all on the proof side. Blazeway closes that gap, with a clean markdown export back into the vault when each test ends.

The vault is good at storing the hypothesis as a daily note. It is good at backlinking the hypothesis to a strategic theme. It is good at letting your future self find the pattern across six months of decisions. What it cannot do is verify that the hypothesis was ever tested against real users. That part lives outside the vault. It always has. It always will.

Plain-text durability. Local-first. No cloud lock-in. Decision journal as a deliberate practice. Anyone running an Obsidian setup with a "Decisions" folder has already accepted the entire premise of compounding institutional knowledge. The argument has nothing to do with whether to document. The question is whether your documentation is connected to anything outside your own memory.

If you have been running a vault for a year or more, you already know the failure mode. The decisions folder fills up with notes that refer to changes ("rolled out the new pricing page in May, results good"), but the changes themselves live nowhere in the vault. They live in a Stripe dashboard, a feature-flag tool, a deployment log. Six months later, when you want to revisit the decision, the note exists and the proof is gone.

Blazeway is the proof layer that the vault was built to be linked from.

Assigning a real visitor to variant B requires server-side infrastructure. So does counting a conversion, and hashing a session deterministically without a cookie. These problems live outside any local-first vault, by design. The vault is good at thinking. The server is good at running tests.

Blazeway is the server piece, with a markdown export that closes the loop back into your vault. The export includes the hypothesis (in your chosen schema), the variant descriptions, the conversion result, and the structured insight you wrote when the test ended. Drop it into your daily note or your /tests/ folder, and the backlinks light up the graph just like any other vault content.

Obsidian does not fail here. The test mechanism was always going to live somewhere else, and Blazeway is the somewhere else, designed to close the loop.

Every PKM crowd produces three "experiment tracker" plugins. They are clever. None of them run a real A/B test. They cannot, because variant assignment requires server-side hashing, and the Obsidian plugin runtime is your laptop. A plugin can format your hypothesis. It can build a database view of your past experiments. It cannot route a real visitor to variant B, because the plugin only runs when your vault is open, and your visitors are on a server somewhere else.

The trap is investing weekends building a plugin that, when finished, still cannot do the one thing the workflow needs. Better to recognize the architectural reality early: the test runs on a server, the documentation runs in your vault, and a markdown export connects them.

Your vault stays sacred. Blazeway is the part of the stack that lives outside it.

The Obsidian community values privacy and data ownership at a level most software users do not. Local vault, no telemetry by default, optional encryption, plain-text storage that no vendor can take away. Blazeway shares the underlying philosophy at the test-runner layer: the variant assignment is server-side and cookieless, no fingerprinting, no localStorage, no consent banner needed.

The combination is unusual. A local-first thinking layer (Obsidian) and a privacy-by-design experiment runner (Blazeway). Most experiment tools force a tradeoff between rigor and privacy compliance. Most PKM tools cannot run experiments at all. The pattern recommended here, vault for thinking and Blazeway for proof, gives both layers their privacy stance without compromise.

For more on the underlying mechanism, see the cookieless A/B testing guide and the GDPR A/B testing legal guide.

The hypothesis lives as a daily note in the vault. The Blazeway test link drops in as a backlinked reference. When the test closes, Blazeway exports the result as markdown with frontmatter, and that file lands in your /tests/ folder. The graph view picks up the new node. Backlinks connect the new test to the original hypothesis note, the relevant strategic theme, and any past tests on the same surface.

Six months later, when you ask "what have we learned about pricing pages," you can search across the vault graph (for thinking) and across Blazeway's LLM export (for proof). Both layers stay clean. Neither one is asked to do the other's job.