🚧 Early alpha — building the foundation. See the roadmap →
Why Obsidian, why files
The decision
Section titled “The decision”Crosswalker is built on files and folders, not a proprietary database. Obsidian is the chosen platform because it IS files — markdown on your filesystem, owned by you.
Why NOT a no-code database tool
Section titled “Why NOT a no-code database tool”Building this on Notion, Airtable, Coda, or any SaaS database would be:
- Too opinionated — their schema is their schema. You can’t version-control a Notion database with git. You can’t diff two versions of an Airtable base. You can’t run a CI/CD pipeline against a Coda doc.
- Locked in — your compliance data lives in their servers, their format, their export limitations. When the vendor changes their API or pricing, your workflow breaks.
- Not universal — everyone has a filesystem. Not everyone has Notion. Files work on Linux, Windows, macOS, air-gapped networks, classified environments.
Why files specifically
Section titled “Why files specifically”| Property | Files | Database |
|---|---|---|
| Version control | Git natively | Requires export/API |
| Diff between versions | git diff | Custom tooling |
| Offline access | Always | Depends on vendor |
| CI/CD integration | Read files directly | API calls needed |
| Air-gapped environments | Works | Usually doesn’t |
| Ownership | You own the bytes | Vendor owns the platform |
| Portability | Copy the folder | Export + re-import |
| Tool-agnostic | Any editor, any OS | Vendor-specific UI |
Why Obsidian specifically
Section titled “Why Obsidian specifically”Obsidian is chosen over other markdown editors because:
- Plugin ecosystem — Crosswalker can ship as a community plugin with UI, commands, settings
- WikiLinks — native bidirectional linking between notes, which IS the knowledge graph
- Graph view — built-in visualization of the link structure
- Properties API — native YAML frontmatter support with type system
- Bases — native tabular views for compliance dashboards (though limited to flat queries)
- Community — large, active community of knowledge workers and developers
- Local-first — no server dependency, works offline, syncs optionally
- Extensible — Excalidraw, Dataview, Templater, and hundreds of plugins that complement Crosswalker
What this means for the architecture
Section titled “What this means for the architecture”The layered architecture keeps Obsidian at the integration layer, not the core:
- Spec + Library → no Obsidian dependency, pure data processing on files
- Plugin wrapper → Obsidian-specific (vault API, modals, commands, settings)
- CLI wrapper → Node.js, no Obsidian required at all
If someone wanted to build Crosswalker for VS Code, Logseq, or a web app — the spec and library layers work unchanged. Only the integration layer changes.
The trade-off accepted
Section titled “The trade-off accepted”Files give us portability and ownership. In exchange, we accept:
- No referential integrity (broken links are possible)
- No ACID transactions (partial imports can happen)
- No real-time collaboration (file-level merge conflicts with sync)
- Manual eventual consistency (re-import required to converge)
These trade-offs are the right ones for compliance knowledge management, where data ownership and auditability matter more than real-time collaboration.