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

Roadmap

Updated

Crosswalker is a meta-system for ontology lifecycle management, not just a framework importer. The roadmap reflects this — architecture decisions come first, features are built on that foundation, and every significant decision is logged with rationale.

See vision alignment decisions for the philosophical foundations.

Current phase: Foundation

Section titled “Current phase: Foundation”

Foundation — “Get the architecture right”

Section titled “Foundation — “Get the architecture right””

Architecture decisions before more code. The three interconnected schemas (_crosswalker metadata, FrameworkConfig, EvolutionPattern) must be designed together — getting any wrong is expensive to fix later. Decision: architecture first

Research & spec (iterative, philosophical, first-principled):

  • Ontology diff primitives — define the 9 atomic operations + 4 recognized composites (also known as: graph change atoms, structural change primitives). Provably complete per graph edit distance literature. The mathematical foundation — “what changed?” First principles · Glossary
  • EvolutionPattern vs transformation recipes — investigate whether the EvolutionPattern taxonomy (also: framework handling profile, stewardship profile) is needed alongside per-version-transition transformation records. Could storing the actual transformation per version change (e.g., “NIST r5→r6: these IDs renamed, these merged”) replace or complement the framework-level classification? Both may coexist — research item. User-first maintenance
  • SEACOW + folder-tag-sync prior-art integration — the project owner has already built two tools that wrestle with the hierarchy-vs-graph tension Crosswalker is facing. SEACOW is a meta-framework for knowledge organization inside filesystem primitives (lives in cyberbase), and folder-tag-sync is a working Obsidian plugin that layers polyhierarchy onto the filesystem via synchronized tags. Decide what Crosswalker reuses (SEACOW vocabulary, folder-tag-sync regex engine, the “primary folder + parallel tag hierarchy” UX pattern) vs. lets evolve in parallel. Research item — see 04-10 SEACOW + folder-tag-sync prior-art log.
  • Evidence-framework edge model (the other edge type) — Direction committed per the 2026-04-10 evidence-link edge model synthesis log, which distilled 2 research sessions targeted at Challenge 07. Evidence links are stored as junction notes (one markdown file per edge, edge-as-note reification) with a 13-field flat-YAML frontmatter schema isomorphic to OSCAL’s by-component assembly. Three orthogonal status dimensions: status (5 OSCAL values: implemented/partial/planned/alternative/not-applicable) + freshness (4 computed values: fresh/stale/expired/not-set) + evidence_type (8 values: policy-document, automated-scan, test-result, configuration, log-export, interview, architecture-review, attestation). Git history with 3 hardening measures (signed commits, branch protection, periodic external snapshots) is the audit trail. SSSOM dual-confidence scoring is borrowed. The original link metadata system inline-Dataview syntax is superseded by this commitment. Remaining open sub-decisions (design work, not research): (1) UUID enterprise resilience scope, (2) Tier 2 sql.js sidecar SQL schema mapping, (3) synthetic spine (Challenge 06) integration question — direct or through-spine, (4) tested vault scale threshold documentation, (5) mandatory vs optional field marking, (6) multi-editor conflict resolution, (7) inline-Dataview migration script for v0 vaults.
  • Evidence mapping workflow — the broader surface around the edge model above: how evidence gets imported / authored / linked, how status transitions work (covered → partial → planned → deprecated), how reviewer attribution and review dates are captured, how coverage gaps are surfaced, and what the UX looks like for a GRC analyst mapping a policy document to multiple controls across multiple frameworks. The Python tool’s original link-metadata system sketched one approach; the Obsidian plugin needs a refreshed version informed by the edge-model decision above and the Obsidian Bases direction research (how evidence queries get surfaced as tables/dashboards). Evidence mapping for GRC teams is the user-facing slice; this roadmap item tracks the design commitment behind it.
  • Crosswalk edge semantics commitment (STRM + SSSOM) — lock in the vocabulary and metadata envelope every crosswalk edge must carry. The 04-10 synthesis identified two layers that work together: STRM (the 5 set-theory relationships from NIST IR 8477 + SCF + OSCAL) as the required predicate_id vocabulary, and SSSOM (Matentzoglu et al., Database, 2022) as the row-schema envelope that every edge sits inside — mandatory mapping_justification, optional confidence, author_id, mapping_date, mapping_tool, and predicate_modifier for negation. SKOS is rejected as the base vocabulary (deliberately too vague for compliance-grade audit) but kept as an export format via YAML-LD / LinkML. Decision has to be made before any crosswalk authoring features ship.
  • Pairwise crosswalks vs synthetic spine architecture — the biggest open architectural question from the 04-10 foundation synthesis. Every mature compliance meta-framework (SCF, UCF, DESM, Hyperproof) converged independently on hub-and-spoke mapping through a canonical intermediate ontology (the “spine”) instead of O(n²) pairwise crosswalks. Investigate whether Crosswalker should adopt a spine, which candidate (inherit SCF, distill via FCA, handcraft), and critically — the long-term resilience and audit-grade trustworthiness of synthetic mapping spines (governance longevity, error-propagation blast radius, provenance-chain trust for transitively-derived crosswalks, exit strategy if the spine maintainer disappears). Research challenge brief · Synthesis log section
  • FrameworkConfig v2 schema — evolution metadata, sheet selection, custom transforms, crosswalk definitions. Config-as-code format (JSON/YAML) as source of truth; UI edits config files. Current schema design
  • _crosswalker metadata v2 — version tracking, source hash, status field, evolution profile reference, migration history. Progressive metadata tiers (minimal → standard → extended → temporal)
  • Migration strategy matrix — given evolution pattern + old/new version → recommended SCD type + handling strategy
  • As-code data format research — define primitives for representing configs, evolution profiles, and migration rules as version-controllable files
  • Layered architecture design — spec (universal) → library/SDK (implementations) → integrations (Obsidian plugin, CLI, framework drivers). Architecture vision
  • Progressive tier architecture (pillar) — Tier 1 (files only + validation) → Tier 2 (files + sidecar SQLite via sql.js WASM) → Tier 3 (server-based: PocketBase, Postgres). Files always source of truth. Each tier shares the same schemas. This is the committed answer to Tier-1 file-canonical ceiling limits (Obsidian query-layer performance, graph-view caps, V8 heap) — we accept the ceiling at Tier 1 and scale through tiers when needed, rather than abandoning files. Pluggable layers · Ceiling documented in 04-10 synthesis
  • Distribution architecture — pnpm monorepo: @crosswalker/core (pure logic) + plugin (Obsidian wrapper) + CLI (Node.js fs wrapper). VaultAdapter interface bridges platforms. Research
  • Graph scope decision — directed graphs now (covers 95% of use cases). Research DAGs and hypergraph support for future extension. Pluggable layers: Thread 2
  • Obsidian Bases direction research — Dataview is deprecated. Understand Bases API for building the viewing/querying layer on top of native Obsidian capabilities instead of custom UI. Datacore is a backup option to investigate if Bases turns out to be insufficient. Reconciling the “3–5K note” ceiling the research literature cites against Dataview with what Bases can actually handle is part of this item. Context in 04-10 synthesis
  • Monorepo restructure — extract ~50-60% of current codebase into packages/core/, keep plugin UI in packages/plugin/, create packages/cli/. After spec work, not before. Sequence rationale
  • Transform engine — custom build (14 engines evaluated, none fit). 24 transform types, ChunkyCSV-style operations, optional Arquero/JSONata escape hatches. Ontology lifecycle: Import · Research

Infrastructure:

  • PII scanning in CI/CD — automated detection of personal paths, secrets, API keys before push
  • Bug fixes and polish on current MVP
  • Expand E2E smoke tests minimally (don’t test wizard UI — it will change)
  • Fluid layout scaling — replace rigid Nova breakpoints (768/1152px) with clamp() CSS so spacing adapts to browser zoom. Current fix: extended breakpoint to 1152px. Full fix: fluid custom properties for --sl-nav-height, --sl-content-pad-x, typography scale. ~3-5 hours.

Formats — “Import anything, transform it properly”

Section titled “Formats — “Import anything, transform it properly””

Built on the Foundation spec. The wizard UI is redesigned around FrameworkConfig v2.

  • Complete import wizard UI — steps 2-4 redesigned around the new config schema
  • Complete settings tab — all 8 sections reflecting new schema
  • Complete config browser modal — search, select, delete, import/export
  • XLSX parser — integrate xlsx package into wizard with sheet selector
  • JSON/JSONL parser — structured data import
  • Transform system — implement 20+ transform types defined in schema (string, array, type conversion, conditional). Current types
  • Improved preview — expandable folder tree, full note preview in Step 3
  • E2E test suite — full import wizard workflow tests, built from spec

Crosswalks — “Link frameworks to each other and to evidence”

Section titled “Crosswalks — “Link frameworks to each other and to evidence””

The evidence mapping workflow — the core value proposition for GRC teams.

  • Cross-framework linking engine — generate typed WikiLinks between imported frameworks using crosswalk data. Crosswalk specs
  • Link insertion commands — “Insert framework link” with search modal and metadata form. Link metadata system
  • Batch re-import — update existing framework folders with version awareness and diff preview. Resilience patterns
  • FrameworkConfig presets — per-framework configs with sheet selection, custom transforms, column overrides. Community-contributed via the as-code format.
  • CLI implementation — headless import, crosswalk generation, batch operations

Evolution — “The meta-system”

Section titled “Evolution — “The meta-system””

Implement the ontology evolution classification system designed in Foundation. This is the novel contribution — no existing tool solves this.

Community — “Share and scale”

Section titled “Community — “Share and scale””

Build the ecosystem around the spec.

  • Community config registry — start with GitHub repo, evaluate built-in registry later
  • OSCAL export — export to Open Security Controls Assessment Language for GRC tool integration
  • Compliance dashboards — Bases views for gap analysis, coverage tracking
  • Report generation — exportable compliance reports for auditors
  • Custom migration transforms — user-defined transformation logic for version migrations. From inline expressions to named transforms to custom scripts. Progressive depth applied to migration.
  • AI-assisted transforms — LLM-based property mapping using templates (like Obsidian web clipper AI templates but for ontology node properties). Map source schema to target schema via AI suggestion.
  • Extended graph support — research and implement DAG and hypergraph support beyond basic directed graphs
  • Community plugin submission — publish to Obsidian plugin registry
  • Spec publication — publish EvolutionPattern taxonomy and structural diff engine as standalone specifications

Decision log

Section titled “Decision log”

Every significant architectural decision is captured with rationale in the log:

See also: ROADMAP.md on GitHub

Archive

Section titled “Archive”

Past roadmap versions are preserved here for reference: