Tagged: Architecture
System design, architecture decisions, and data flow
Pages with this tag
Challenge 06: Pairwise vs synthetic spine — architecture, resilience, and trustworthiness (archived)
13Investigate whether Crosswalker should architect cross-framework crosswalks through a canonical intermediate spine (hub-and-spoke) or continue with direct pairwise mappings. Go deep on long-term resilience and audit-grade trustworthiness of synthetic spines. RESOLVED 2026-05-01 — see callout.
Challenge 07: Link metadata / edge model for evidence mapping (archived)
14Design the edge metadata model for evidence→framework implementation links — the "other" edge type Crosswalker has to support that's NOT a crosswalk. Bases-compatible storage, custom or inherited schema, reviewer attribution, status transitions. RESOLVED 2026-04-10, archived 2026-05-01.
Challenge 09: UUID / CWUUID cross-cutting identifier strategy
15Where exactly does Crosswalker need persistent identifiers? Survey every place a UUID-class ID would matter (nodes, edges, junction notes, evidence notes, framework versions, spine snapshots, mapping authors, vault identity), evaluate options (UUIDv4/v7, ULID, content-addressed CID, OSCAL UUIDs, custom CW prefix), and recommend a minimum viable identifier scheme for Foundation.
Challenge 10: Graph → tabular bridging engine for the web-of-webs
16Crosswalker's data is fundamentally a graph (ontology nodes + crosswalk edges + evidence-link junction notes + lifecycle change atoms). Most reporting needs are tabular (compliance matrices, gap dashboards, coverage reports). Survey existing engines (DuckDB, KuzuDB, Apache AGE, Neo4j+Cypher, oxigraph, sql.js+materialized joins, Datacore graph queries) and design the bridging architecture across Crosswalker's three tiers.
Challenge 11: Tier 2/3 graph + analytical engine deep survey
17Re-evaluate the Tier 2 and Tier 3 engine choice from Challenge 10 against the full design space — Datalog engines, production triple stores, versioned graph databases (TerminusDB especially), other property graphs, embedded analytical engines, vector+graph hybrids, streaming/incremental MV systems, virtual/federated approaches, and query unification layers.
Challenge 12: Datalog vs SQL for SSSOM chain-rule derivation
18Narrow fork-in-the-road. The core spine derivation engine — the thing that composes pairwise mappings through a pivot using SSSOM's 22 chain rules — could be Datalog (cleaner provenance, native fit) or recursive CTE (broader engine support, simpler ops). Pick one, with rationale.
Challenge 14: Missed engines evaluation — Grafeo, Minigraf, CozoDB, SurrealDB, Comunica, cr-sqlite (archived)
19Phase 2 engine evaluation. Multiple engines surfaced during Challenge 11 research that were absent from the original brief — most consequentially Grafeo (pure-Rust LPG+RDF, all major query languages, vector index, WASM bindings, potentially collapses the layered Tier 2 stack to a single engine). RESOLVED 2026-05-02 — see callout.
Challenge 16: Tier 3 stack reconsideration — alternatives to Apache AGE (archived)
20Apache AGE was Challenge 10's Tier 3 default but the 2026-05-02 research wave surfaced concerns: Bitnine→SKAI Worldwide pivot, PG 17.1 ABI break, slow release cadence. RESOLVED 2026-05-02 — see callout.
Challenge 18: Tier 2-Lite SSSOM rule subset and scale ceiling
21Ch 14 recommended a Tier 2-Lite alternate stack (sqlite-wasm + sqlite-vec + simple-graph + recursive-CTE SSSOM reasoning) for Obsidian Mobile, low-end laptops, and restricted-CSP environments — but did not define which SSSOM rules are tractable under recursive-CTE evaluation, where the scale ceiling sits, or what the migration-up-to-Tier-2 trigger should be. This challenge fills that gap with a concrete rule-by-rule expressivity matrix and a measured scale ceiling.
Challenge 19: Over-engineering stress test — is the architecture justified by the problem?
22Honest, adversarial assessment: is Crosswalker's accumulated tech stack (layered Tier 2: DuckDB-WASM + Oxigraph + Nemo; layered Tier 3: Fuseki / oxigraph-server / DuckDB-on-server; 4-tier audit-trail with OpenTimestamps + RFC 3161 + Sigstore Rekor + eIDAS QTSA + in-toto + W3C VC Data Integrity; SSSOM + STRM + junction notes + StewardshipProfile + LinkML-considered + IPLD-considered) actually justified by the problem Crosswalker is solving, or has the architecture grown beyond what the user audience can adopt? The challenge is to reach an honest verdict — could be 'yes the complexity is necessary because the problem demands it' OR 'we've over-engineered; here's the radically simpler stack that serves 90% of users'.
Project ops setup
23Initial git setup, Bun migration, CI/CD, Starlight docs scaffold, test infrastructure.
Architectural direction exploration
24Defining what Crosswalker actually IS — meta-system for ontology management, not just a framework importer.