Skip to content
Crosswalker
🚧 Early alpha — building the foundation. See the roadmap →

What makes Crosswalker unique

evolving Updated

Crosswalker helps GRC teams bring frameworks into Obsidian, shape them into useful notes, connect controls and evidence, and understand coverage in plain Markdown. Its longer-term ontology lifecycle direction extends that foundation into version comparison, migration support, and shared community work.

Current versus roadmap: guided import, flexible note shapes, connected output, and vault-native queries are the active product. Comprehensive sharing of reusable import rules and long-term framework update workflows remain roadmap direction.

This page captures what’s genuinely novel, what exists now, what remains directional, and why the underlying design choices matter.

The core insight

Section titled “The core insight”

An ontology’s evolution is not a property of the ontology itself, but of how it’s stewarded by its community.

MITRE publishes biannual ATT&CK releases with STIX changelogs — automation is possible. CIS publishes infrequently with prose release notes — human intervention required. NIST CSF went from 1.1 to 2.0 with a complete restructure — every crosswalk broke.

No existing tool classifies these patterns. Crosswalker does, using the EvolutionPattern taxonomy — a novel specification that maps stewardship patterns to handling strategies borrowed from Slowly Changing Dimensions in data warehousing.

This is the secret sauce: the meta-layer that understands how knowledge structures change over time.

What’s genuinely novel

Section titled “What’s genuinely novel”

Individual pieces of the puzzle exist elsewhere — OSCAL for machine-readable controls, SCF’s STRM for framework mapping, MITRE’s STIX for deprecation chains, SSSOM for ontology-mapping metadata. But no tool combines them:

CapabilityExists today?Crosswalker’s approach
Classify how an ontology evolvesNoEvolutionPattern taxonomy — 8 fields, community-contributed profiles
Auto-select migration strategy from that classificationNoMigration strategy matrix — evolution pattern + SCD type → handling
Community registry for reusable framework importsPartially (SCF)Roadmap: portable rules and mappings shared through a registry
Detect stale crosswalks automaticallyNoRoadmap: version comparison plus review of affected mappings and evidence
Crosswalk edge semantics committed as a layered stack (STRM vocabulary + SSSOM envelope)Partially (SCF uses STRM, no PKM tool combines with SSSOM)Set-theoretic predicates with full audit envelope, not SKOS’s vague closeMatch semantics
Evidence-link edge model distinct from crosswalk edgesNoJunction notes with 13-field schema, isomorphic to OSCAL by-component, Bases-queryable
File-based compliance knowledge graphNoObsidian vault as a property graph — plain markdown, zero vendor lock-in
General ontology-web query engine, GRC as launch marketNo (BioPortal/OLS are platform-locked; GRC tools are domain-locked)Three-layer architecture (primitives / view shapes / recipes) — same engine queries compliance frameworks, MITRE ATT&CK, SKOS taxonomies, OBO Foundry biomedical ontologies, NIST OLIR data web — without vendor lock-in. Compliance recipes ship first; the architecture is general-domain

Five core differentiators

Section titled “Five core differentiators”

1. Files, not databases

Section titled “1. Files, not databases”

Crosswalker chooses files and folders over proprietary databases. This isn’t a limitation — it’s a deliberate architectural decision:

  • Version control: git diff between framework versions, not custom export tooling
  • Data ownership: you own the bytes, air-gapped environments work
  • Tool-agnostic: the query layer is Obsidian Bases (we explicitly committed against Dataview as it’s deprecated), but plain-text frontmatter means any tool can read the data — no lock-in
  • CI/CD friendly: read files directly in pipelines

The tradeoff: eventual consistency and manual re-import instead of real-time sync. For compliance knowledge management, where auditability matters more than real-time collaboration, this is the right tradeoff.

2. Platform architecture, not plugin monolith

Section titled “2. Platform architecture, not plugin monolith”

Crosswalker is designed as a three-layer system:

LayerWhat it isWho uses it
SpecEvolutionPattern taxonomy, SCD mapping, config-as-code formatAnyone — other tools can implement it
LibraryParsers, transforms, crosswalk resolver, migration plannerDevelopers building integrations
IntegrationsObsidian plugin, CLI, future web UIEnd users

The spec is publishable as a standalone standard. The library has zero Obsidian dependency. The plugin is just one wrapper around the core.

3. Evolution-aware from the ground up

Section titled “3. Evolution-aware from the ground up”

Most tools treat frameworks as static snapshots. Crosswalker treats them as living documents with predictable evolution patterns:

  • EvolutionPattern taxonomy: 8 fields classifying how each framework changes — release cadence, breaking change policy, ID stability, deprecation mechanism, and more
  • SCD type mapping: each pattern maps to a Slowly Changing Dimension strategy (overwrite, keep history, alias old IDs, or maintain history tables)
  • Migration strategies: given old version + new version + evolution pattern → recommended handling with diff preview

4. Roadmap: community-multiplied value

Section titled “4. Roadmap: community-multiplied value”

Crosswalker is building toward portable import rules and mappings that can be reviewed, versioned, and shared as files. The preservation foundation exists, but the complete save/open/share experience and community registry do not yet ship.

The roadmap direction is:

  • A community registry for reusable framework imports
  • Versioned rules that declare which source versions they support
  • Mapping files that can be reviewed and reused independently
  • An entity registry documenting who publishes and maintains each source

5. Domain-neutral core, GRC-first launch surfaces

Section titled “5. Domain-neutral core, GRC-first launch surfaces”

Crosswalker is ontology lifecycle tooling that launched into compliance, not a compliance tool with a general-purpose veneer. The two halves of that are worth stating precisely, because they are easy to confuse:

LayerDomain postureWhy
Note contract, type system, render() engine, query primitivesDomain-neutral. Nothing in the data model names a control, a framework, or an auditorA concept, its identity, its place in a hierarchy, and its typed edges are the same primitives whether the source is NIST SP 800-53 or an OBO Foundry biomedical ontology
Bundled recognized-source recipes, starter view shapes, docs and settings copyGRC-first, deliberately. The recognized sources that ship today are all compliance frameworksA launch market you can be concretely excellent for beats a generic tool that is nobody’s first choice

The mechanics are honest and worth being explicit about: the recognized-source registry is a convenience layer, not a capability boundary. Every bundled recipe (source: recipes/import/ — NIST CSF 2.0 in three export shapes, NIST SP 800-53 Rev 5, CIS Controls v8 controls and safeguards, MITRE ATT&CK techniques, CRI Profile v2.2, SCF 2026, plus OLIR-style crosswalk edges) is an ordinary import recipe that ships in the box and gets fingerprinted against your file on selection. A confident match skips straight to the review screen. A taxonomy, standards catalog, skills matrix, product hierarchy, or research ontology produces the same Tier 1 notes through the same guided import — it simply has no bundled recipe to recognize it yet, and you save your own setup instead.

So the correct inverse framings are both true, and each belongs on its own surface: user-facing pages say “built for GRC first; works for any structured framework or taxonomy”; the architecture says domain-neutral contract, with compliance convenience privileged first. What is privileged is the fast path, never the model.

Short term vs long term

Section titled “Short term vs long term”

Now: get the architecture right

Section titled “Now: get the architecture right”

The Foundation phase focuses on spec before code. The three interconnected schemas — _crosswalker metadata, FrameworkConfig, and EvolutionPattern — must be designed together. Getting any wrong is expensive to fix once users have generated notes.

What exists today (v0.1 in progress):

  • An import workspace for CSV, XLSX, and JSON sources
  • Flexible folder, heading, tag, link, property, and body output
  • Source-bound setup save/load/match convenience
  • Typed crosswalk and evidence relationships plus Bases-native queries
  • Portable-import preservation foundations, without the full sharing UI

Roadmap direction:

  • Durable save/open/share workflows for portable import rules
  • Framework-version comparison and review-assisted updates
  • A community registry for reusable imports and mappings
  • Broader automation and integration surfaces

Medium term: the Obsidian-native experience

Section titled “Medium term: the Obsidian-native experience”
  • Complete import wizard with XLSX/JSON support and transform system
  • Cross-framework linking engine with typed WikiLinks
  • Batch re-import with version awareness and diff preview
  • CLI for headless operations and CI/CD integration
  • E2E test suite

Long term: platform-agnostic core

Section titled “Long term: platform-agnostic core”

The VaultAdapter pattern ensures the core logic is portable:

crosswalker/
├── packages/core/      # Pure logic — zero Obsidian dependency
├── packages/plugin/    # Obsidian wrapper (UI, vault adapter)
├── packages/cli/       # Node.js CLI (fs vault adapter)
└── packages/web/       # Future web UI

Obsidian is the first and best integration — its plugin ecosystem, WikiLinks, graph view, and Properties API make it ideal. But the core library can power a CLI, a web UI, a VS Code extension, or any tool that processes structured knowledge.

The endgame: a community registry of 100+ framework evolution profiles, a CLI for CI/CD compliance checks, and a published specification that other tools can implement — whether or not they use Crosswalker’s code.

The bread and butter

Section titled “The bread and butter”

What makes Crosswalker defensible and unique in the long run:

  1. The EvolutionPattern spec — a novel classification system that doesn’t exist anywhere else. Once published and adopted, it becomes the lingua franca for describing how ontologies change.

  2. The community config registry — network effects. Every framework config contributed makes the tool more valuable for everyone. The first tool to build this critical mass wins.

  3. File-first philosophy — while competitors build databases that lock users in, Crosswalker produces plain markdown that works with any tool. Users who value data ownership choose this.

  4. SCD-for-ontologies bridge — applying well-understood data warehouse patterns to a domain that hasn’t formalized them yet. This insight is simple but powerful.

Section titled “Related”