Tagged: Architecture
System design, architecture decisions, and data flow
Pages with this tag
Ch 12 deliverable B: Beyond the known engine landscape — long-horizon directions
49Fresh-agent research deliverable that expanded well beyond Challenge 12's narrow Datalog-vs-SQL scope into a long-horizon architectural survey. Identifies engines absent from Challenges 10/11 (Stoolap, Minigraf, HelixDB, Comunica, sqlite-vec, cr-sqlite, Ascent, Percival, declarative-dataflow, Feldera/DBSP), proposes LinkML as canonical schema substrate (auto-generates JSON Schema, OWL, SHACL, Pydantic, TypeScript), proposes IPLD content-addressed crosswalk distribution, and proposes a Tier 1.5 compilation pipeline producing Parquet/HDT/JSON-LD/OSCAL/IPLD-CAR artifacts.
Ch 19 deliverable: Over-engineering stress test — radically simplify with narrow tiered escape hatch
50Fresh-agent adversarial research deliverable for Challenge 19. Bottom line: the architecture has lost the property of 'simpler thing becomes default because it's more adoptable.' Five concrete arguments: (1) competitive landscape (Hyperproof/Drata/Vanta hide crosswalk complexity from users; Excel + SharePoint baseline is what Crosswalker actually competes with); (2) SSSOM has zero GRC adoption (~50K downloads/month all biomedical); STRM (NIST IR 8477) + OSCAL is what NIST OLIR / SCF actually use; (3) audit trail wildly over-specified vs FRE 902(13)/(14) requirements (hash + qualified-person cert + git is the legal floor); (4) 5 MB three-engine WASM bundle is 10–50× Obsidian plugin median; SCF (1,400 controls × 261 frameworks) ships as one Excel file; recursive CTEs handle 3-hop closures over 10K edges in single-digit ms; (5) concrete 'simple default' proposal: markdown + YAML frontmatter (STRM) + git + signed releases + Dataview + STRM-TSV/OSCAL export, under 500 KB. Layered engines as separate opt-in companion plugins.
Consistency models
51ACID, CAP theorem, eventual consistency, and BASE — applied to Obsidian vaults and Crosswalker imports.
Embedded vs server substrates — the file-IS-the-database pattern
52SQLite's quiet revolution was bringing database semantics into the file-based world — "the library, not the server." Crosswalker's three-tier architecture leans hard into that philosophy. This page maps the embedded-database landscape across every data model (relational, RDF, property graph, document, key-value, vector, Datalog, multi-model) and shows which engines are file-based, which are server-only, and which Crosswalker has evaluated.
File-based graph databases
53How markdown vaults function as property graph databases — formal model, trade-offs, and patterns for storing structured relationships in files.
Institutional landscape
54The entities, relationships, and dynamics of who creates, maintains, maps, mandates, and consumes structured ontologies — the human side of ontology management.
Ontology lifecycle
55The lifecycle of an ontology within the Crosswalker ecosystem — from acquisition through import, enrichment, maintenance, and sharing.
Operational landscape
56Who does what work across the ontology ecosystem — institutions × components × resources. The combined view of effort, ownership, and sustainability.
System architecture — components, tiers, and data flow
57One-page canonical view of Crosswalker's architecture. Three storage tiers (source, canonical Markdown, derived SQLite); six logical layers (import, storage, projection, query, export, audit); the components inside each layer; what reads what; where to look in code + docs. Simplified TL;DR up front, progressively more detail below.
What makes Crosswalker unique
58The core differentiators and novel contributions — why this isn't just another importer, and what the short vs long term vision looks like.
Architecture
59Core components, data flow, and system design.
Config selection
60How Crosswalker matches and suggests saved configurations.