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: v0.1 implementation (design phase closed 2026-05-04)

Section titled “Current phase: v0.1 implementation (design phase closed 2026-05-04)”

v0.1 implementation milestones (active work)

Section titled “v0.1 implementation milestones (active work)”

The v0.1 implementation phase breaks into 10 sequenced milestones. Each has its own page with concrete tasks, dependencies, and success criteria. This table mirrors the milestone hub — that page is the live source; if the two ever disagree, the hub wins.

MilestoneTitleEffortStatus
v0.1.1Type system + validation foundation1–2 days✅ Done (2026-05-04)
v0.1.2render() v1 — folder + file + heading3–5 days✅ Done (2026-05-05)
v0.1.3Generation engine integration3–5 days✅ Done (2026-05-05)
v0.1.4Junction notes + crosswalk edges2–3 days✅ Done (2026-05-05)
v0.1.4.5Iterator-ready engine boundary (wizard remains eager)1–2 days✅ Done (2026-05-05)
v0.1.5Tier 2 sqlite-wasm sidecar projector5–8 days✅ Done (2026-05-06)
v0.1.6Bases query layer + SSSOM import + recipe UX3–5 days (ran long — absorbed the shape-workbench side-arc)🚧 In progress — Phases 1–6.4 ✅ + Phase 7 (shape-workbench side-arc) ✅ 2026-07-11; v0.1.7 is active. See CHANGELOG.md [Unreleased] for delivery detail
v0.1.7Portability: exporters, reusable configurations, source bindings, MappingSetsExpanded🚧 In progress — exporter first slice ✅; recipe-fidelity foundation ✅ 2026-07-21; recipe library slice ✅ 2026-10-02; Run again and source-change status ✅ 2026-10-02; full NIST replay proofs ✅ 2026-10-03; mapping set release record slices 1 and 2 ✅ 2026-10-03; exporter completion remains, now gated on the save-and-replay + primitives decision registers (2026-07-25). See CHANGELOG.md [Unreleased]
v0.1.8Execution records, audit, and package manifestsExpanded📋 Planning; depends on v0.1.7
v0.1-RCArtifact-chain acceptance, bundle, polish, ship2–3 days📋 Planning

Status last verified: 2026-10-03 (v0.1.7 row only, re-checked against CHANGELOG.md [Unreleased] and the milestone page). The rest of this table keeps its 2026-09-05 verification below.

Status last verified: 2026-09-05 — every cell above was re-checked against the milestone pages, CHANGELOG.md [Unreleased], and the commit log. No milestone status changed in this documentation update; the fix/d1-per-import-root safety work remains unmerged branch work, not a shipped milestone. If today is far past this date and no newer verification line has replaced it, treat this table as unverified.

Delivery posture: functional correctness and a usable, explicitly supported workflow come before optimizing every ingestion path. The eager in-memory wizard can remain the initial path where it works honestly; silent data loss, crashes on declared-supported inputs, and false completion are blockers. Advanced streaming, parser migration, and replay integrity for mutable multi-pass sources are staged, measured improvements, not automatic blockers for v0.1.7. See ingestion safety and staged performance.

Total estimate: ~3–6 weeks of focused work (running a bit long — v0.1.6 absorbed an adjacent import-wizard rebuild). The closing acceptance chain is source bytes → reusable configuration → Knowledge Set/MappingSet → Execution Record → Package Manifest; see artifact roles and authority and the artifact-role synthesis. See the milestone hub for full sequencing and dependencies.

Deterministic avenues: command line and live demo (near term)

Section titled “Deterministic avenues: command line and live demo (near term)”

Every lifecycle stage should be reachable both from the UI and from a deterministic script, with the same output either way. The UI stays primary and the command line is the escape hatch, per the UI parity rule. Decision log

  • Command line first slice: headless commands (run without opening Obsidian) over the same engine the plugin uses: import with a recipe, export, validate against spec/tier1.schema.json and spec/recipe.schema.json, and replay a saved recipe. Runs from the repo with bun against a plain folder of Markdown. Does not wait for the monorepo restructure: a thin filesystem vault adapter now, extraction into packages/core and packages/cli later as an additive move. Decision · Distribution architecture
  • Live demo workspace: a full multi-framework demo (several frameworks, crosswalks between them, evidence junction notes, saved queries) built by the command line from content the repo may redistribute, then loaded into an OpenClast workspace (real Obsidian running in a browser tab) so anyone can open it. Regenerated by one command, never hand-built. Decision

Foundation — “Get the architecture right” (closed)

Section titled “Foundation — “Get the architecture right” (closed)”

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

After three research waves on 2026-05-02 and the v0.1 stack-pivot, Foundation is now organised around a concrete v0.1 build target plus the genuinely-still-open spec items.

v0.1 build target — what ships first

Section titled “v0.1 build target — what ships first”

Concrete, shippable. ~1.2 MB total. Tier 1 + Tier 2 sqlite-wasm sidecar bundled together.

Build against the unified v0.1 schema spec — the four interconnected schemas (_crosswalker metadata, FrameworkConfig v2, junction note 13-field schema, Tier 2 sidecar SQL) in one place.

v0.1 stack (full commitment):

  • Tier 1 storage: markdown files with YAML frontmatter; STRM predicate vocabulary (is_equivalent_to, is_broader_than, is_approximate_to, intersects_with, no_relationship); junction notes (13-field schema, Ch 07 resolution) for evidence links
  • Tier 1 in-memory index: plain JS Map built at vault-load time over frontmatter; works without Tier 2 (slow on large vaults but functional)
  • Tier 2 sqlite-wasm sidecar projector: @sqlite.org/sqlite-wasm (~600 KB) + sqlite-vec; auto-projects from Tier 1 on vault load; deletable; reprojected on next load. Per Ch 18 expressivity matrix, 4 ✅ tractable rule types + 4 ⚠️ caveat-tractable cover the realistic GRC workload comfortably under 100K mappings
  • Crosswalk-render plugin: Dataview-style queries on frontmatter for the Tier 1 path; recursive CTE over Tier 2 sidecar for transitive closure / multi-framework joins / coverage matrices / perspective views
  • Portability chain: STRM/SSSOM/CSV export; explicit OSCAL target-shape decision; reusable ImportRecipe library (library slice landed 2026-10-02 under _crosswalker/import-recipes/; each import also keeps the recipe it ran under _crosswalker/import-sets/); separate exact source/run binding (Run again slice landed 2026-10-02); minimal MappingSet identity/membership/integrity/provenance/license envelope. Hybrid SSSOM↔STRM resolution per v0.1 pivot §6
  • Execution records, audit, and package manifests: one terminal Execution Record per run; execution-linked provenance/events; git + Ed25519 + FRE 902(13) consume that receipt; a separate Package Manifest inventories and attests each distributed release. Per v0.1 pivot §8
  • Bundle target: under 500 KB plugin core + ~600 KB sqlite-wasm sidecar = ~1.2 MB compressed total

Plugin scope: a single, focused import wizard + crosswalk-render plugin + Tier 2 sidecar projector. Performance enhancements (DuckDB-WASM, Oxigraph, Nemo, Comunica federation) live in separate companion plugins released later.

✅ Resolved Foundation decisions

Section titled “✅ Resolved Foundation decisions”

These are committed direction, with deliverables and decision logs. They feed v0.1 and beyond.

Genuinely-still-open Foundation items

Section titled “Genuinely-still-open Foundation items”

These are design / spec items that need work before/during v0.1 implementation. Most are documentation or schema specifics, not architectural questions.

Schema spec work:

  • Unified v0.1 schema spec (2026-05-03) — the four interconnected schemas designed together as the v0.1 build target. Implementation of the four schemas below proceeds against this spec.
  • ImportRecipe v1 schema (formerly FrameworkConfig v2 — see naming history) — implement the recipe shape in src/types/config.ts; migration script for legacy saved configs
  • _crosswalker metadata v2 — extend src/generation/generation-engine.ts to write the v2 fields (ontology_id, ontology_version, recipe_id); idempotent migration for existing notes
  • Junction note 13-field schema — implement junction-note generation as new code path in the generation engine; non-destructive, git-history-preserving
  • Tier 2 sidecar SQL schema — new packages/core/ projector module; auto-runs on vault load; lazy closure cache
  • Migration strategy matrix — given StewardshipProfile + old/new version → recommended SCD type + handling strategy

Implementation infrastructure:

Documentation tasks (surfaced 2026-05-02; non-blocking but valuable):

  • OSCAL ↔ Crosswalker mental model — extend reference/registry/oscal to map OSCAL terms (catalog ↔ source-ontology web, Control Mapping Model ↔ crosswalk edges, Assessment Result ↔ junction notes) into Crosswalker’s vocabulary. Per TL;DR §3.3
  • DB-choice architecture page — extend architecture/file-based-graph-database explaining why Tier 1 + sqlite-wasm sidecar is the right choice (and why not pure graph DB). Per third-wave §3.3
  • Comunica honest+practical assessment — per third-wave §7.2, Comunica federation conditional confirmation pending honest assessment before v1.0 companion plugin work
  • StewardshipProfile rename ripples — propagate the rename across ~24 docs files where the old “EvolutionPattern” term still appears

Research items remaining (not v0.1-blocking):

Infrastructure (non-blocking):

  • PII scanning in CI/CD — automated detection of personal paths, secrets, API keys before push
  • 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. ~3-5 hours.

Formats / Acquire — “Import anything, transform it properly”

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

Built on the Foundation spec. This phase expands both source-format breadth and acquisition while preserving exact-source replay semantics.

  • 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 — sheet picker + header-row offset, shipped 2026-06-12
  • JSON parser — iterator path + row filter + record picker, shipped 2026-06-12
  • JSONL (newline-delimited JSON) parser — not yet supported
  • Source fetch automation — background acquisition helpers for known publisher files. Before this can ship, define a per-framework rights model because fetching a restricted workbook on a user’s behalf is a different act from telling the user where it lives, and define a staleness/pinning story so automation does not silently replace the exact source version a recipe or replay expects
  • Remote acquisition — acquire supported sources over explicit remote references without merging acquisition policy into ImportRecipe transformation/layout semantics
  • Content-hash pinning — bind runs to exact acquired bytes; detect upstream drift before refresh or replay
  • Cache, refresh, and offline replay — retain verified source bytes and metadata so users can refresh deliberately or reproduce a prior run without network access
  • 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

Recipe authoring with AI assistance

Section titled “Recipe authoring with AI assistance”

A canonical recipe is already plain JSON: every bundled recipe under recipes/import/ uses the closed 5-mechanism grammar, and an assistant can already read and propose edits to that JSON directly. This is a distinct file and code path from the config browser’s saved-config export/import, which round-trips wizard state (SavedConfig) — the config browser’s file import does not read or accept canonical Recipe JSON today. What is missing for recipe editing specifically is the packaging that makes an assistant round trip feel native instead of a manual copy-paste through the filesystem. Doing that safely means preserving the full canonical RecipeDocument rather than reconstructing a recipe from a smaller edited fragment, and giving the user an explicit preview and opt-in before any source content leaves the vault — none of this packages or sends anything automatically.

  • Paste-JSON entry — accept a pasted recipe alongside the existing file import, so an edited recipe comes back without a download-and-re-upload hop
  • Context-pack command — one action that copies spec/recipe.schema.json, the recipe being edited, and the current source’s column headers as a single block to hand an assistant. The schema plus a worked recipe is already the context an assistant needs; this only packages it
  • Validate-on-paste — report schema violations in the UI at paste time with the offending field named, rather than failing later during generation. Follows the actionable-errors rule: name a cause and an action

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.
  • Command line crosswalk and batch operations: crosswalk generation and batch runs from the command line, built on the near-term command line first slice (headless import, export, validate and replay live there). Decision

Performance — “v1.0+ companion plugins”

Section titled “Performance — “v1.0+ companion plugins””

Performance enhancements and integration capabilities researched on 2026-05-02 (third research wave) and reframed by the v0.1 stack-pivot as opt-in companion plugins that ship after v0.1 lands. Each is fully researched; the deliverables are ready-made designs.

These are not v0.1 build target. They are v1.0+ work for users who outgrow the Tier 2 sqlite-wasm sidecar default.

  • “Crosswalker Power Query” companion plugin — DuckDB-WASM + Oxigraph-WASM + Nemo-WASM layered Tier 2 stack (~5 MB compressed). Triggered when a user vault exceeds Tier 2-Lite’s ~100K mapping ceiling (per Ch 18 migration triggers) OR demands recursive SHACL / multi-stratum Datalog / SPARQL property paths. Ch 11 deliverables A/B/C · Ch 14 deliverable
  • Comunica federation companion plugin — Comunica + N3 + HDT for cross-vault, cross-org, external SPARQL endpoint queries. ~250–300 KB gzipped core. Conditional — see third-wave §7.2: user flagged Comunica as “seems bulky or overengineered”; honest-and-practical assessment needed before locking in
  • Compliance-export mode — opt-in profile picker exposing T2 OpenTimestamps and T3 audit options (“US litigation”, “EU regulated”, “Federal ATO”, “Supply-chain”) per the Ch 15 deliverable §E. Each profile pre-configures 4–6 settings. v0.1 default remains T1 (git + signed commits).
  • Migration trigger UX — status-bar indicator and modal prompts for “you’ve outgrown Tier 2-Lite” per Ch 18 §3.2. Detects performance / scale / feature triggers; suppressed on platforms that can’t migrate (Obsidian Mobile)
  • PQC dual-sign migration — Ed25519 → ML-DSA-44 dual-sign starting 2027 per Ch 15 §5.6 crypto-agility plan. Ahead of NIST IR 8547 2035 deadline.

Deployment — “v2.0+ Tier 3 server guide”

Section titled “Deployment — “v2.0+ Tier 3 server guide””

Server-tier deployment options for users who genuinely need a shared multi-team server. Documented as a deployment guide rather than bundled into the plugin.

  • Default recommendation: Postgres + JSONB + recursive CTE — boring tech, broadly operable, “you probably don’t need anything fancier.” Per Ch 16 deliverable §2.3
  • Apache Jena Fuseki + oxigraph-server — same-API alternative for users who want SPARQL natively (oxigraph-server uses the same engine as the v0.1 Tier 2, just with serve mode). Architectural symmetry with Tier 2.
  • Layered Fuseki + DuckDB-on-server — power-user upgrade path for multi-team mixed SQL+graph workloads, multi-million mappings. Federated via SPARQL SERVICE and DuckDB httpfs / postgres_scanner
  • TerminusDB v12 — opt-in vault-mirror for users who want server-side git-style branch/diff. Small-vendor (DFRNT) risk explicitly flagged
  • Apache AGE on Postgres — supported fallback for Postgres-standardized environments. AGE’s killer feature (graph queries inside an existing Postgres instance) has no substitute
  • Migration from AGE — for early adopters who started on AGE during the Ch 10 era. The SSSOM-canonical files-first architecture turns “migrate from AGE” into “re-run the projector against the new engine,” not “translate AGE data” — see Ch 16 §5

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
  • Package lifecycle — discover packages, resolve dependencies/compatibility, verify Package Manifest hashes/signatures/licenses, install, update, and uninstall without bypassing canonical artifact identities
  • Expanded OSCAL support — add catalog or other post-v0.1 models only after the v0.1 crosswalk target-shape decision is explicit and schema-valid
  • 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
  • Mobile Obsidian preview (exploratory) — drive and capture Obsidian’s mobile layout the way the desktop harness (WebdriverIO with a private X display) already drives and screenshots desktop Obsidian. Two uses: agents verify mobile rendering before release, and a visitor detected on a phone, even in a mobile browser, sees the mobile layout. Open issues: Obsidian mobile is a Capacitor app, not Electron, so desktop-side mobile emulation approximates layout and touch but not the real runtime; a real device needs an Android emulator plus Appium; streaming Obsidian itself to visitors raises licence and hosting questions. Supports the mobile-portability constraint behind the TypeScript engine commitment. Raised 2026-09-23.
  • 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:

Latest (2026-10-27): Command line and live demo move to the near term

Recent (2026-05-02 / 2026-05-03) — three research waves + v0.1 stack pivot:

Earlier (2026-04) — first-principles foundations:

See also: ROADMAP.md on GitHub, research deliverables, research challenges

Archive

Section titled “Archive”

Past roadmap versions are preserved here for reference: