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
61Fresh-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
62Fresh-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.
Artifact roles and authority
63Crosswalker's minimal artifact model: governing Schema Contracts, extensional Knowledge Sets, intensional Recipes, planned administrative envelopes, and the authority relations between them.
Consistency models
64ACID, CAP theorem, eventual consistency, and BASE — applied to Obsidian vaults and Crosswalker imports.
Conventional systems in the stack — built and adopted, layer by layer
65The high-level map of the conventional systems layered across Crosswalker's pipeline — the formalized DSLs, schemas, and vocabularies at each layer. Some we built (recipe grammar, render(), Tier 1 schema, data morphology, the lenses), some we adopted and combined (CURIE, STRM, SSSOM, OSCAL, Bases, SQLite, RML/JSONata). One diagram of the whole pipeline, with every layer linking down to the page that goes deep.
Embedded vs server substrates — the file-IS-the-database pattern
66SQLite'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
67How markdown vaults function as property graph databases — formal model, trade-offs, and patterns for storing structured relationships in files.
Institutional landscape
68The entities, relationships, and dynamics of who creates, maintains, maps, mandates, and consumes structured ontologies — the human side of ontology management.
Mapping into Obsidian — from external data to vault primitives
69The front half of Crosswalker: how disparate external data (framework spreadsheets, crosswalks, ontologies) is morphed onto Obsidian's native primitives — folders, files, headings, tags, frontmatter, wikilinks. The conventions that take a source row to a note on disk: transformation primitives, the recipe grammar, render(), the two kinds of link, and the Tier 1 contract.
Ontology lifecycle
70Six recurring Crosswalker capabilities — Acquire, Shape, Connect, Understand, Share, and Maintain — and the artifacts that cooperate across them.
Operational landscape
71Who does what work across the ontology ecosystem — institutions × components × resources. The combined view of effort, ownership, and sustainability.
Producing vaults outside Obsidian
72Can a vault be built entirely on disk, by the command line or a script, and still work like one built with the import wizard? Yes. Valid Tier 1 notes are the contract, the plugin derives every runtime surface from those notes, and only per-vault app config has to be recreated per host. This page maps what is identical, what is derived, what is host config, and the invariant that keeps the three paths equal.