Knowledge organization
The organization problem
Section titled “The organization problem”Compliance frameworks are structured hierarchies, but the knowledge work around them (evidence, reviews, policies) is graph-shaped. Organizing this in a filesystem requires choosing between competing structural primitives.
Structural primitives in Obsidian
Section titled “Structural primitives in Obsidian”Folders
Section titled “Folders”- Strict hierarchy — each item has exactly one parent
- Best for: consumable outputs, framework taxonomies, published structures
- Limitation: single classification only
- Overlapping hierarchies — items can belong to multiple categories
- Best for: clustering, cross-cutting concerns (e.g.,
#access-managementacross multiple frameworks) - Nested tags enable sub-classification:
#framework/nist/ac
- Flexible relationships — any note can link to any other
- Best for: evidence mapping, cross-references, ad-hoc connections
- Limitation: no metadata about the relationship (Crosswalker addresses this)
Metadata / Properties
Section titled “Metadata / Properties”- Structured information — typed key-value pairs in YAML frontmatter
- Best for: queryable attributes (status, reviewer, date, framework version)
- Powers Dataview queries and Obsidian Bases views
How Crosswalker uses each
Section titled “How Crosswalker uses each”| Primitive | Crosswalker Usage |
|---|---|
| Folders | Framework hierarchy (Family → Control → Enhancement) |
| Tags | Cross-cutting categories from framework data |
| Links | Cross-framework references and evidence mapping |
| Metadata | Frontmatter properties from source columns + _crosswalker tracking |
SEACOWr meta-framework
Section titled “SEACOWr meta-framework”Prior art by the project owner — SEACOW is a meta-framework for knowledge organization inside filesystem-primitive worlds, developed and lives in cybersader/cyberbase (search the repo). It’s not abstract theory — it’s working convention from years of real use. Crosswalker should treat it as Foundation-phase prior art, not as a decontextualized thinking tool.
A thinking tool for organizing knowledge platforms, applicable to how Crosswalker structures output:
- System — the platform (Obsidian, with its specific capabilities)
- Entity — the user (GRC analyst, security engineer, auditor)
- Activities:
- Capture — how knowledge enters (Crosswalker import wizard)
- Output — how knowledge exits (reports, queries, exports)
- Work — how knowledge is processed (evidence mapping, gap analysis)
- (r)elation — how concepts connect (typed links, crosswalks)
This framework helps answer “where should this go?” when structuring imported data.
See the 04-10 SEACOW + folder-tag-sync prior-art log for how SEACOW’s axes map onto Crosswalker’s current Foundation decisions, and the roadmap research item tracking what Crosswalker should formally adopt from it.
Polyhierarchy via tags — obsidian-folder-tag-sync
Section titled “Polyhierarchy via tags — obsidian-folder-tag-sync”More prior art from the project owner — the cybersader/obsidian-folder-tag-sync plugin (active development, lives in the same plugin_development/ workspace as Crosswalker) provides bidirectional sync between folder paths and Obsidian tags with regex-based rules. A note in Frameworks/NIST-800-53/AC/AC-2.md can automatically carry #framework/nist/ac-2 and vice versa.
Why it matters for Crosswalker: the filesystem is a rigid hierarchy, but compliance knowledge is inherently polyhierarchical — a control can belong to multiple NIST families, a technique to multiple MITRE tactics, and an evidence note to multiple framework controls across multiple frameworks. folder-tag-sync’s pattern (primary folder location + synthesized parallel tag hierarchy) is a proven working solution to this problem. Crosswalker’s generation engine could reuse the mechanism directly, or at minimum cite it as the reference implementation.
See the 04-10 prior-art log for the full list of reuse opportunities and the roadmap research item tracking the reuse decision.
PARA + Taxonomies
Section titled “PARA + Taxonomies”The classic PARA system (Projects, Areas, Resources, Archive) can be extended with a Taxonomies/Ontologies category for framework structures. In a Crosswalker context:
| Category | Content |
|---|---|
| Projects | Active compliance assessments |
| Areas | Ongoing security domains |
| Resources | Reference materials, policies |
| Archive | Completed assessments |
| Taxonomies | Imported framework hierarchies (Crosswalker output) |
Design implications for Crosswalker
Section titled “Design implications for Crosswalker”- Output path should be configurable — different users organize differently
- Frameworks should be self-contained — each import in its own folder subtree
- Cross-references via links, not folders — crosswalks don’t need shared folder hierarchy
- Metadata enables querying — frontmatter properties make frameworks queryable without specific plugins
- Tags for cross-cutting concerns — framework categories that span multiple hierarchies