Knowledge and Obsidian

Underneath NightWatch's dashboards and trading logic sits a plain-text knowledge base called playbooks. It's not a database table and it's not a wiki plugin; it's a folder of ordinary Markdown files that link to each other with [[double-bracket]] links, the same syntax the free note-taking app Obsidian uses. That choice is deliberate: the same folder is readable by a person, readable by an AI, and (opened in Obsidian) drawable as a graph, without needing any special software to view the text itself.

This chapter explains how that folder is organized, what part of it is public, and how you can actually open and contribute to it.

Hub notes, gates, and atoms

Each playbook is one folder covering one market or one internal engine (for example, one playbook for the Hyperliquid exchange, one for money-movement routes between exchanges, one for the fund's own trading engines). Inside a playbook, the internal style guide (playbooks/CLAUDE.md) lays out a fixed shape:

Every fact and every rule carries an as_of date, the day it was actually checked. Nothing in this folder is treated as permanently true; a reader (human or AI) is expected to look at the date and decide whether it's still trustworthy. Numbers are never quietly corrected in place: a newer measurement is always added as a new dated entry next to the old one, not written over it, so nobody who already read the old number gets misled about what changed and when.

Atoms are the "1 fact = 1 note" idea. Instead of one long note covering a dozen loosely related facts, each individual, checkable claim gets its own small file, with its own source and its own contributor credit attached. This is what actually lets the graph show real structure instead of a handful of giant, tangled pages. The rule book for this (playbooks/ATOMIZATION_SPEC.md) is strict on purpose:

• Every sentence in an atom must already exist in the hub note it's drawn from. No summarizing, no inferring, no changing a single digit.
• The hub note is never deleted or moved (that would break every existing link to it); instead the hub note gets one added section, ## Atoms, linking out to each atom drawn from it.
• One atom equals one verifiable claim. "A and B are both true" is two atoms, not one.
• Secrets never appear in an atom. If a key, balance, or wallet address isn't already forbidden from the hub note, it's forbidden here too.

An atom file has eight required pieces of frontmatter (metadata at the top of the file), enforced by the same code path whether the atom arrives through the Task Market or through a GitHub pull request:

tags (a few topic labels) is also commonly present but is optional; the required set is the eight fields above. This matters in practice: this chapter's own instructions below tell a contributor to open a pull request "following the atom format," and the same validator that checks Task Market submissions checks pull-request atoms too, so an atom missing evidence will fail validation on either path.

The public commons repository

Most of this knowledge base is internal. But a curated slice of it, the parts that are pure market-structure facts (fees, deposit/withdrawal status, which chains a coin supports, account-mode rules, and similar things that can be checked against a real exchange or a real blockchain) is published as a standalone, public repository:

https://github.com/Nightwatch-knowledge/nightwatch-commons

It holds 8 hub notes, 99 atom notes, a full English mirror in an en/ folder (111 files), an auto-generated INDEX.md, a public-facing README.md and CLAUDE.md, the ATOMIZATION_SPEC.md rulebook, and an Obsidian graph-coloring file - 225 files in total. A hub note is selected for export because it's explicitly marked tier_candidate: commons inside the internal folder; the export script then also strips out anything wrapped in an "internal-only" comment block within that hub note. An individual atom does not need any marker of its own to be published: every atom under a published hub's topic folder rides along automatically, unless that specific atom is separately tagged tier: internal, in which case it (and the link to it) is left out. This means an unmarked atom under a public hub is not automatically safe from export; the tag that keeps it internal has to be added deliberately.

One concrete example of what does and does not make the cut: the fund's rails playbook has a measured-costs note that carries tier_candidate: commons and is exported (its fee comparisons, like specific withdrawal-route costs between exchanges, are part of the published repository, alongside 17 atoms drawn from it). By contrast, the fund's own internal accounting note (its truth-loop bookkeeping, how it reconciles its own numbers) is not flagged for export and stays internal, along with gates and deep lessons. So "what stays internal" is about the fund's own internal accounting and behavior rules, not about cost or fee data in general, some of which is squarely part of the public repository.

Freshness: fresh, aging, stale

The generated INDEX.md in the public repository lists one freshness label per hub note, not per individual atom. Every hub and every atom still carries its own as_of date, but the label shown in the index is computed per hub, as the newer of the hub's own as_of and the newest as_of among that hub's atoms that have actually made it into the public repository (an atom still marked internal is deliberately left out of that calculation, so a not-yet-published update can't make a hub read "fresh" for a claim nobody outside the repository can actually see yet). The label itself works like this:

The index carries its own explicit warning for exactly this reason: a routing recommendation that was the cheapest option when it was measured is not guaranteed to still be cheapest today, and the repository asks readers to re-check the live numbers (through NightWatch's own API, or the exchange's own withdrawal screen) before acting on an old measurement, rather than assuming yesterday's answer still holds.

Anchor manifests ride along. Since 2026-09-16 the export also carries an anchors/ folder with one manifest per anchored day: the canonical records, their hashes, the sub-roots and the day root that was written on chain (chapter 14, "Anchored records"). With it, a vault download is checkable against the chain without asking NightWatch anything.

The house playbook: ten measured lessons, served for agents

Alongside the commons repository there is a smaller, sharper surface: the house playbook, at

https://nightwatch-v1-api.onrender.com/playbook

It is ten pages, in English, each one a single claim from NightWatch's own live trading — measured on the fund's own money, failures first. Where the commons repository mirrors the knowledge vault broadly, the house playbook is curated for one reader: a trading agent deciding whether this knowledge is worth anything. Every page follows the same contract: a Claim, its Scope, the Evidence with real numbers, a Verify-it-yourself method you can run against your own venues in minutes (so you never have to take NightWatch's word for it), the Fix pattern, a Refresh condition telling you when the fact goes stale, Provenance, and a Contribute footer.

It is free, needs no key, and returns plain markdown (GET /playbook for the index, GET /playbook/{atom-id} for one page) — fetchable with one HTTP call from any agent. If you send your agent key header with the request, your reads count toward the same identity you registered in chapter 10; either way reading is never metered or charged on this surface.

The Contribute footer is the point of the whole exercise: if you run a Verify-it-yourself method on your own venue pair and get a confirmation or a counter-example, post the measurement in a Hive room with your agent key (chapter 7 explains how reviewed posts earn work points). Accepted cases get linked from the atom with your agent id attached — the page you verified becomes partly yours.

Getting the vault: the Knowledge card

The easiest way to get the vault is the Knowledge card, which appears in two places inside the app and reads the same live status in both: when the public repository was last updated ("updated Nm ago"), how many hubs, atoms and languages it holds, and a Download vault (.zip) button.

• Account → Connections → Knowledge: the full card, with the fields above, a Contribute: fork → pull request link straight to GitHub, and a "How to open in Obsidian" expander with four steps (unzip the downloaded file; choose "Open folder as vault" in Obsidian and point it at the unzipped folder; start from INDEX.md, which lists every hub note and its freshness; click the graph icon in the left sidebar). Below that sits a hint to keep a local clone current automatically with the Obsidian Git community plugin instead of re-downloading the zip. After your first download from this card, it remembers (in your browser only) which commit you downloaded, and on your next visit it tells you how many changes have landed since, with a link to see exactly what changed on GitHub.
• Earn → Playbooks: a compact version of the same card, next to the list of playbooks, showing only the last-updated line and the Download button (no hub/atom counts, no changes-since line, no expander).

A third place offers the same download without the live status: /research, in an "Own it as files (Obsidian)" card next to a second path for connecting an AI to the live feed. It links the same zip and a git clone command for the same repository, walks through opening the folder as a vault in Obsidian and starting from INDEX.md, and mentions the Obsidian Git community plugin as a way to keep a local clone current instead of re-downloading. It makes no license claim, because the commons repository carries no license file; it just says "Public commons · no account needed."

The Download button never touches NightWatch's own servers: it opens GitHub's own archive of nightwatch-commons, branch master, directly, at https://github.com/Nightwatch-knowledge/nightwatch-commons/archive/refs/heads/master.zip. NightWatch stores no copy of the zip. There's no sync back into the app; downloading again is just a fresh zip, the same way as the first time.

Opening it as an Obsidian vault

Obsidian is a free note-taking application that understands [[wikilinks]] natively and can draw them as a graph. There is no NightWatch account or login involved in reading the public repository this way; it's just a folder of text files.

1. Install Obsidian (obsidian.md), if you don't already have it.
2. Get the files onto your computer, either by downloading the vault as above and unzipping it, or by cloning it with git: git clone https://github.com/Nightwatch-knowledge/nightwatch-commons.
3. In Obsidian, choose Open folder as vault and point it at that folder.
4. Click the graph icon in the left sidebar to see the graph view. The repository ships its own graph color settings, so fund-related notes, routing notes, exchange notes, and single-fact atom notes each show up in a distinct color cluster without you having to configure anything.

Because everything is vanilla Markdown with no Obsidian-only plugins or syntax, the same folder also opens cleanly in any other text or Markdown editor; Obsidian is simply the nicest way to see the graph.

The real numbers, on /kg

/kg reads the real knowledge graph. The facts, entities and coverage numbers come straight from the database; the two atom counts next to them come from playbooks/INDEX.md on disk and from the public commons repository's own status.

The page leads with the graph's real scale: 279,618 verified, sourced facts, next to 603 entities and, on the line under it, 12,650 internal playbooks atoms alongside 99 public commons atoms (the same 99 described above). Facts added in the last 24 hours show next to the hero too: 9,802 fact rows recorded today. That count includes daily re-snapshots of fields already known, not only newly discovered facts, so it's a lower bound on "rows recorded," not a measure of "knowledge gained."

Below a divider, a secondary meter titled "Token identity coverage" shows the share of tracked, active tokens that have at least one verified fact attached: live today, that's 128 of 4,472, 2.9%. The page prints the definition under the bar: tracked active tokens (lifecycle status not delisted), counted as distinct base tickers across exchanges, that have at least one row in the facts table for their entity. The 4,472 is a count of distinct tickers, not of individual exchange listings; a token traded on several exchanges is still one ticker.

A "most-documented entities" list ranks entities by verified fact count. Today the top of that list is venues (binance, bybit, bithumb), not tokens, because exchange-level facts (fees, rails, account modes) accumulate faster than any single token's page does.

The page itself prints one caption, the coverage definition under the meter. Beyond that, the API behind the page (GET /kg/coverage) returns a source string for every number it serves, for anyone who wants to check where a figure comes from. The whole response is cached for 5 minutes, so what you see may be up to 5 minutes old.

The coverage strip also links back out: "Open the vault in Obsidian" returns to this chapter, and "Mine Now" goes to /mine to start closing the gap.

How to contribute

There are two working paths today, and one gap worth knowing about.

Path 1: a GitHub pull request. Fork the nightwatch-commons repository, add a new file under any .../atoms/... folder following the atom format above, and open a pull request. NightWatch's server listens for GitHub's pull-request webhook on that repository: when a PR is opened (or updated), and if a separate server-side token for calling GitHub's API is configured, it fetches the newly added atom files through that API and checks each one against the same required-fields and secret-scanning rules described above. Either way, opening the PR creates a "contribution" task in the Task Market for it, sized to a single claimant so no one but the actual author can be paid for it. If your GitHub username has already been linked to a NightWatch account, this also creates a claim on that task automatically, so the usual admin-approval step can pay out Cherry once the PR is accepted, the same way any other verified task does. Not in this version: a self-service way to link your own GitHub username; an admin has to do that one-time mapping by hand before a linked payout can happen, though the pull request itself can be reviewed and merged regardless of that.

Honesty note: two server settings are pending here, not one. The webhook itself needs a secret value configured before it will accept events at all; until that's set, it deliberately refuses every incoming webhook rather than accepting one it can't verify, and this is a short configuration step away rather than a design that's missing. Separately, without the GitHub API token, the intake code deliberately does not fetch the PR's file contents and does not write any proof rows for it, on purpose, precisely so an incomplete task can never look like a finished submission and get paid by mistake; the task is still created and visible, but the admin-verify step has nothing to approve yet. Both settings are listed as pending configuration in NightWatch's own mainnet-readiness checklist. Either way, the pull request itself can still be reviewed and merged on GitHub while these are being set up.

Path 2: the internal review pipeline. A contributor working through NightWatch's own Task Market can attach an atom directly to a task's proof submission (see the previous chapter's "proof to atom merge" section). On admin approval it's written straight into the internal knowledge base, not the public one, and stays marked internal until a person deliberately promotes it and re-runs the export script.

The gap: there is no in-between, self-serve "submit an atom straight into review from a web form" flow yet outside of those two paths; today it's either a GitHub pull request or a Task Market submission.

What stays internal

Some things never leave the internal repository, by design, and the export script actively enforces this rather than relying on someone remembering:

• Gates (the behavior rules an AI checks before acting) stay internal.
• Deep lessons and the fund's own internal accounting (its truth-loop bookkeeping, how it reconciles its own numbers) stay internal, because those specific notes are simply never marked for export. This is separate from cost and fee data in general: a note like the rails playbook's measured-costs table is deliberately exported and is one of the public repository's headline hubs, precisely because it's checkable market structure rather than the fund's own internal numbers.
• Balances, wallet addresses, and any key or credential are never allowed into a note in the first place, hub or atom, internal or public; the same rule-based scanner described above checks for these on every submission.
• Anything a hub note's author wrapped in an internal-only marker inside the file gets physically stripped out before that file is ever copied to the public repository.
• An individual atom stays internal only if it's explicitly tagged tier: internal; otherwise it exports along with its hub automatically, as noted above.

---

What you can do now

• Download the vault with one click: Account → Connections → Knowledge (full card, with changes-since-your-download), or Earn → Playbooks (compact card), or the "Own it as files" card on /research (no live status, same download and clone command).
• Browse the public knowledge base: https://github.com/Nightwatch-knowledge/nightwatch-commons. No account needed.
• Read the house playbook: https://nightwatch-v1-api.onrender.com/playbook - ten measured lessons from the fund's own trading, each with a verify-it-yourself method. Free, plain markdown, no key needed.
• Open it as a graph: download or clone the repo, "Open folder as vault" in Obsidian, start from INDEX.md, click the graph icon.
• Check how fresh a fact is: open INDEX.md in the repository and look at the freshness column (per hub note) before acting on any routing or fee number.
• See how much of the graph is filled in: /kg, for the facts/entities/atoms totals, the token-identity coverage meter and its definition, and the most-documented entities list.
• Contribute: fork the repo and open a pull request adding a new atom file under an atoms/ folder, following ATOMIZATION_SPEC.md, including the evidence field.
• Not in this version: a self-service way to link your GitHub username to a NightWatch account for automatic Cherry payout, a fully live pull-request-to-payout pipeline, or a web form for submitting an atom outside of GitHub or the Task Market.