🚧 Early alpha — building the foundation. See the roadmap →
Terminology
A glossary, not a textbook: one or two lines per term, with a link to the page that owns the depth. Formal words carry a plain-English gloss in italics.
Status last verified: 2026-10-30 — referenced-framework note row checked against src/import/stack/referenced-frameworks.ts and tests/cli/referenced-framework-takeover.test.ts; 2026-10-03 — MappingSet record row checked against spec/tier1.schema.json SchemaVer 1.7.0 $defs.mapping_set_frontmatter; 2026-09-23 — implied concept checked against spec/recipe.schema.json $defs/layout_entry.implied_concept, src/generation/enrich.ts, and src/generation/generation-engine.ts; earlier glossary checked against spec/tier1.schema.json, spec/recipe.schema.json, and the current generation/reconciliation modules under src/generation/.
Looking for the two kinds of link (concept ↔ concept crosswalks vs. document → concept evidence links)? The side-by-side diagram lives on Mapping into Obsidian · the two kinds of link; the definitions are in Core terms below.
Artifact roles and authority
Section titled “Artifact roles and authority”Crosswalker separates what an artifact means from where or how it is stored. Owning page: artifact roles and authority.
| Term | Plain English | Definition |
|---|---|---|
| Schema Contract | the rules for what counts as valid | Plainly: the machine-checked rulebook that spells out which properties a valid note or recipe may carry — the plugin, an outside script, and an agent all validate against the same rulebook before writing, which is what makes external producers first-class. Formally: a normative, versioned representation contract answering “what is valid?” The JSON Schema files in spec/ carry these. A Schema Contract governs artifacts; it is not content itself. |
| Knowledge Set | the actual content — what exists | A named, versioned, governed collection of concepts or assertions. A conceptual superclass, not a claimed generalized KnowledgeSet file format. |
| Recipe | the instructions — what should be done | A portable, schema-validated declaration of repeatable behavior. ImportRecipe is the concrete source-to-Tier-1 subtype. A Recipe is not a Knowledge Set, a run receipt, generated output, or a package. |
| Referenced-framework note | an identifier known from a crosswalk, not a copy of the framework | An ordinary concept note containing only a target identifier, framework label and the explanation that full text has not been imported. It is not a new artifact authority or schema kind. Identity and explicit import-set ownership allow a later full import to replace its managed content without replacing links. Private-demo binding and takeover limits |
| Import set | the collection of notes one import owns | A durable ownership boundary with a meaningless id minted at first import and stamped into every note that run produces. Refreshes select and reuse the set; ownership is never derived from recipe, source, destination, or note identity. Decision and rationale |
| Execution Record | the receipt — what actually happened | A future historical record of one run: verified inputs, exact recipe identity, outcomes, validation, warnings, output inventory. Today’s per-note provenance is not yet a complete Execution Record. |
| Package Manifest | the shipping label — what was distributed | A future distribution and attestation envelope: resolved artifacts, dependencies, hashes, licenses, signatures, install rules. No normative contract is claimed yet. |
| Tier 1 | the real copy, on disk | Crosswalker’s canonical managed Markdown representation of Knowledge Sets. A representation and authority tier, not a peer root artifact class. See tiers. |
Recipe roles
Section titled “Recipe roles”Roles around the Recipe family — not four new artifact classes.
| Role | Meaning |
|---|---|
| Recipe specification | The canonical machine-evaluable declaration, governed by a Recipe Schema Contract. |
| Recipe template | Parameterized or default policy to instantiate a specification from. A Shape Preset is one. |
| Recipe binding | A recipe reference plus concrete parameters, source identity, or other selected bindings. |
| Recipe execution | One run of a bound recipe. The Recipe states intent; a separate Execution Record reports the outcome. |
Mapping disambiguation
Section titled “Mapping disambiguation”| Term | Definition |
|---|---|
| MappingSet | Plainly: one published crosswalk release — the whole collection of mapping assertions shipped together (e.g. NIST’s 800-53 Rev 4 → Rev 5 mapping). Formally: a Knowledge Set subtype with its own identity, version, membership, provenance, license, and publication state. Not an ImportRecipe, and not a folder inferred from edge rows. Record: kind: mapping-set (source: spec/tier1.schema.json), one release record per set. |
| MappingAssertion — also: assertion | Plainly: one claimed fact about how two things relate — a single crosswalk row, “AC-2 is equivalent to A.9.2.1.” Someone asserted it, so it can be right, wrong, disputed, or superseded — which is why every assertion carries where it came from. Formally: one subject–predicate–object correspondence inside a MappingSet, optionally carrying confidence, justification, provenance, and review metadata. |
| Release record — also: release file | Plainly: the one note or header that says which crosswalk release a mapping set is (id, version, both frameworks with versions, provider, license, how many mappings, and two fingerprints that say whether the set is intact). Formally: the Tier 1 kind: mapping-set record (source: spec/tier1.schema.json), stored as one note per set in notes form and as the mapping_set header key in table form; exported beside a typed mapping table as the release file <name>.mapping-set.json. See the slice 1 and slice 2 decision logs. |
| ImportMapping | An editable, source-bound workbench projection of how source fields map into Recipe-owned regions. Implementation state around an ImportRecipe — not a MappingSet or a portable artifact. |
Representation and distribution terms
Section titled “Representation and distribution terms”| Term | Definition |
|---|---|
| Live view | A query-backed view recomputed from current data on read or refresh. Bases views are live views, not stored results. |
| Materialized snapshot | Query results computed once and persisted — reproducible, potentially stale. Useful for publishing, audit, and comparison; storing one does not make it canonical. |
| Package | A semantically resolved release described by a Package Manifest: selected artifacts plus dependency, integrity, license, and install meaning. |
| Carrier | The physical container that moves the bytes — a zip, directory, or git repo. A carrier is not a Package by itself. |
| Projection | Always use with a qualifier: field projection, read/view projection, Tier 1 → Tier 2 projection, or editable UI projection. ImportRecipe generation is broader than projection — it decodes and re-embodies source structure. |
Core terms
Section titled “Core terms”| Term | Definition |
|---|---|
| Ontology | A structured representation of knowledge — categories, relationships, rules. A governed one is a kind of Knowledge Set. |
| Reification (plain: making implied structure into first-class things) | Turning structure that is only latent in a source, such as a hierarchy encoded in an ID column, a crosswalk encoded in a “maps to” column, or a category encoded in a tags column, into addressable vault objects: concept notes, junction notes (edges as notes), tags, and typed wikilinks. Crosswalker’s core verb; the ontology lifecycle page states the product in these terms. Honest scope: hierarchy, tags, frontmatter, body, inbound cross-mapping columns, nested record lists, and nested levels folded into their parent note as sections now reify through the wizard; the tag and wikilink layout mechanisms remain deferred to v0.2. The import wizard is the control surface for reification: what becomes a folder, a tag, a link, an edge note, a nested note, or a section inside a note is decided there. |
| Framework | A specific ontology: NIST 800-53, CIS Controls, MITRE ATT&CK. |
| CURIE | A compact URI — prefix:local, e.g. nist-800-53:AC-2. Crosswalker’s stable concept identity: the same CURIE means the same concept no matter where the note sits. W3C CURIE Syntax 1.0 · mapping into Obsidian |
| ConceptIdentity | A concept’s CURIE plus its source attributes — the input to render(). Identity is fixed; vault layout is a recipe choice. |
| ImportRecipe | A Recipe subtype governing deterministic source-to-Tier-1 generation: the closed 5-mechanism grammar (folder | file | heading | tag | wikilink) × ordered layout × also_emit × enrichment × graph_edges. Distinct from a SavedConfig, a MappingSet, and the generated notes. Recipe grammar · fidelity boundary |
| render() | The pure function render(Recipe, ConceptIdentity) → Address — the single coupling point turning a concept + recipe into its path, heading anchor, wikilink target, tags, frontmatter, and body regions. Deterministic and reproducible. System model |
| Tier 0 / 1 / 2 | Storage tiers, not peer artifact classes. T0 = upstream source data · T1 = the canonical Markdown in your vault (the real copy) · T2 = a deletable SQLite cache derived from T1. System architecture |
| managed / user_preserve | The frontmatter ownership split: managed keys belong to the recipe (overwritten on re-import); user_preserve keys are yours (never overwritten). Rationale |
| Data morphology | The output-layer language: data shape plus three knobs — transform · reshape · draw — for describing any view or query. More |
| Lens | A subgraph of the vault read for one purpose. General capability; the GRC application is the Control / Assurance / Risk lenses of the Unified Risk Model. |
| Crosswalk | An edge where both ends are ontology concepts: “these two correspond.” NIST 800-53/AC-2 ↔ ISO 27001/A.9.2.1, or a framework mapped onto a synthetic spine. Committed edge vocabulary: STRM predicates inside an SSSOM envelope. Diagram · interlingua pattern |
| Crosswalk column role | A source column that says which concepts in another framework each row maps to. The import wizard offers this role and lets the user name the target framework and relationship. Generation reifies each cell as separate Crosswalk edge notes rather than as concept-note frontmatter. Machine contract: target.crosswalks[] in schema spec §4.13. |
| Nested record level | One record type that lives inside another in the source, such as controls inside groups. Each emitted row carries its lineage in the reserved _cw object: its level, root-first identity path, immediate parent, and carried ancestor fields. Machine contract: source.nest[] in schema spec §4.15. |
| Section record — also: body projection of a nested level | A nested record written as a heading with text inside its parent’s note, not as a note of its own. A nest level declaring leaf: section attaches each record to its nearest emitted ancestor; the record renders as a heading region inside that note’s managed body and gets no note, CURIE, provenance, Tier 2 row, or orphan tracking, because it is content of its host concept, not a concept. Chosen in the wizard with Below the note or a nested row’s Placement. Machine contract: leaf: section in schema spec §4.16. |
| Evidence link — also: implementation link, junction note, link metadata, dotKey metadata (legacy) | An edge from a user-authored document to an ontology concept: “this note attests to that concept, at such-and-such status.” Not a crosswalk. Stored as junction notes — one markdown file per edge, 13-field flat YAML isomorphic to OSCAL’s by-component, with three orthogonal status dimensions (status · freshness · evidence_type); git history is the audit trail. Decision log · Challenge 07 · diagram. Supersedes the inline-field link metadata system. |
| Typed link | Umbrella term for any link carrying relationship metadata. Covers both crosswalks and evidence links. |
| Endpoint | The two things at either end of a relationship — in “MFA-Policy implements AC-2,” the policy and the control are the endpoints. The shipped contract keeps clickable addresses separate from stable identity: concept hierarchy uses parent + parent_curie; junction notes use subject/object + optional subject_curie/object_curie; crosswalk edges use identity CURIEs directly. Identity decision |
| Facet note | A generated index note collecting every concept that shares one property value — in a GRC vault, all controls carrying a given theme tag. Carries kind: facet and a members list of wikilinks. Emitted by import enrichment (source: src/generation/enrich.ts) when facet hubs are enabled. Honest status: these notes are written by the generator but have no branch in the note contract yet and skip validation — closing that gap is open decision P4. |
| Implied concept — a first-class thing named inside other rows, without a row of its own | A source may encode an upper-level concept only as an identifier prefix in its child records. The recipe can make that level an addressable concept note with its own stable CURIE, provenance, children, and parent links, rather than a hub note. Recipe contract §4.17. |
| Hub note — also: level hub | A generated table-of-contents note for one folder level, listing that folder’s direct children as wikilinks. Carries kind: hub. Emitted by import enrichment (source: src/generation/enrich.ts) when level hubs are enabled. Same contract gap and same open decision P4 as facet notes. |
| Hierarchy column | A source column whose values define nesting levels. |
| Frontmatter | YAML properties at the top of a markdown note. Obsidian calls them properties. |
| Fingerprint | A hash of a data file’s structure, used to match a source against saved configs. |
Data flow and implementation terms
Section titled “Data flow and implementation terms”Objects that support editors and runtimes. They do not become first-class artifacts merely by being persisted or passed between functions.
| Term | Definition |
|---|---|
| ParsedData | Parser output: columns plus eager or streamed rows. Not a tier, not a contract. |
| ColumnInfo | Analysis of one source column — type, unique count, samples. |
| CrosswalkerConfig | Legacy full import configuration shape. Not the portable Recipe authority. |
| SavedConfig | Legacy fingerprint-bound wizard convenience state in plugin settings. May restore a past mapping; is not an ImportRecipe, a Recipe binding, or a share/open lifecycle. |
| WizardDraft | Resume state for an unfinished interaction. Workflow state, not a Recipe or Execution Record. |
| RecipeDocument | The preservation/editor transaction boundary: original validated ImportRecipe + editable ImportMapping + session-only origin/dirty state. It patches workbench-owned regions into the original rather than rebuilding it and dropping opaque fields. More |
| GeneratedNote, Address, RenderedBodyRegion, RenderReport, GenerationResult | Runtime results and diagnostics produced while applying a Recipe. Not separately governed artifacts. |
Framework terms
Section titled “Framework terms”| Term | Example |
|---|---|
| Control family | AC (Access Control) in NIST 800-53 |
| Control | AC-2 (Account Management) |
| Enhancement | AC-2(1) (Automated System Account Management) |
| Safeguard | CIS Controls’ equivalent of a control |
| Technique | T1059 (Command and Scripting Interpreter) in MITRE ATT&CK |
| Diagnostic statement | CRI Profile’s equivalent of a control — a testable assertion |
| Informative reference | NIST’s term for a crosswalk between frameworks |
Ontology evolution terms
Section titled “Ontology evolution terms”Owning pages: ontology evolution · framework versioning.
| Term | Definition |
|---|---|
| Ontology evolution | How a knowledge system changes over time — concepts added, removed, restructured. Distinct from versioning (which release you have). More |
| Schema evolution | Changes to the structure of data (fields added, columns renamed) rather than to the data itself. |
| Deprecation chain | A sequence of revoked-by links from old concepts to their replacements. MITRE ATT&CK does this with STIX 2.1. More |
| SemVer | MAJOR.MINOR.PATCH. OSCAL guarantees content valid under a MAJOR version stays valid in later releases of it. More |
| SchemaVer | MODEL-REVISION-ADDITION versioning for data (Snowplow). MODEL = can old consumers read new data? REVISION = the reverse? ADDITION = non-breaking. More |
| SCD (Slowly Changing Dimensions) | Warehouse pattern for records that change over time: Type 1 overwrite · Type 2 keep history · Type 3 alias column · Type 6 hybrid. More |
| SKOS | Simple Knowledge Organization System (W3C). Natural fit on paper — ConceptScheme = framework, broader/narrower = hierarchy — but its 5 predicates carry no confidence, provenance, or negation, so it was rejected as the crosswalk base. Why |
| SSSOM | Simple Standard for Sharing Ontological Mappings. The row-schema envelope for crosswalk edges: required mapping_justification plus optional confidence, author_id, mapping_date, mapping_tool, predicate_modifier. Predicate-agnostic — you supply the vocabulary (see STRM). More |
| STRM — Set Theory Relationship Mapping | The 5-relationship edge vocabulary — equivalent-to · subset-of · superset-of · intersects-with · no-relationship — that NIST IR 8477, SCF, and OSCAL’s Control Mapping Model converged on independently. Crosswalker’s predicate_id vocabulary, paired with SSSOM as envelope. More |
| OSCAL | Open Security Controls Assessment Language (NIST). Machine-readable controls with built-in versioning; also adopts STRM in its Control Mapping Model. Registry |
| OLIR | Online Informative References (NIST) — a submission-based crosswalk registry using the same STRM relationship types. Registry |
| Interlingua / pivot — also: pivot ontology, synthetic spine, hub-and-spoke mapping, meta-framework | One “universal” framework everything else maps through, like a pivot language in translation. Map to SCF once, get crosswalks to 175+ frameworks. The five names are the same pattern from five disciplines. Open question: Challenge 06 · more |
Architecture & evolution primitives
Section titled “Architecture & evolution primitives”From the Foundation phase research. Each carries aliases that appear across the knowledge base.
| Term | Aliases | Definition |
|---|---|---|
| Ontology diff primitives | Graph change atoms, structural change primitives, structural diff engine | The 9 provably complete atomic operations describing what changed between two versions of a labeled directed graph — the mathematical answer to “what changed?” (graph edit distance, algebraic graph transformation). |
| EvolutionPattern | Framework handling profile, stewardship profile, evolution taxonomy | Per-framework classification of how an ontology evolves; sets defaults for handling strategies. Open: may be replaced by transformation recipes. |
| Transformation recipe | Version transition map, migration spec | The record of what changed between two specific versions and how to handle each change — “NIST r5→r6: AC-19(2) merged into AC-19, AC-24 added.” |
| Handling strategy | — | What to do when a change type is detected: overwrite, archive, alias, merge, split, skip, or flag for review. |
| Decisioning | Strategy selection | Choosing handling strategies per change type — by default, per framework, or per user/org. Layered model |
| Pluggable layer | Extension point, opinionated layer | Any behavior that is opinionated and swappable rather than first-principles. Keeps the system tight to first principles while allowing extension of opinionation. |
| Progressive depth | Progressive complexity | Start with guided UI, graduate to config-as-code, add CLI — each interface wrapping the same core primitives. Applies to import and migration alike. |
| Entity | User, agent | Any actor using the system — people or agents. Both must be first-class. |
Data model terms
Section titled “Data model terms”Owning pages: file-based graph database · consistency models.
| Term | Definition |
|---|---|
| Property graph | A graph where both nodes and edges carry key-value properties. An Obsidian vault is one: notes = nodes, wikilinks = edges, frontmatter = properties. More |
| Edge metadata — also: link metadata, typed link metadata, inline field metadata, dotKey metadata | Structured data attached to the relationship between two notes rather than to either note. The umbrella data-model concept behind both crosswalks and evidence links; both now have committed shapes. Diagram |
| Denormalization | Deliberately duplicating data to make reads fast at the cost of write complexity — e.g. storing both forward links and frontmatter arrays. More |
| Referential integrity | The guarantee that every link points at something that exists. Obsidian vaults have none — delete a note and the links stay broken. More |
| ACID | Atomicity, Consistency, Isolation, Durability. File-based systems give you only Durability. More |
| CAP theorem | A distributed system gets at most two of Consistency, Availability, Partition tolerance. Vaults are AP. More |
| Eventual consistency | Copies converge given enough time. In Crosswalker, re-import achieves it — but you have to run it. More |
| Event sourcing | Storing the sequence of changes rather than only the current state. A future _crosswalker.history field would enable it. More |
Matching & alignment terms
Section titled “Matching & alignment terms”Owning page: schema matching.
| Term | Definition |
|---|---|
| Schema matching / schema alignment / ontology matching / ontology alignment / crosswalking / data integration / framework mapping | Seven names for one broad concept: finding correspondences between elements of different structured datasets. Each name comes from a different discipline — databases, semantic web, library science, ETL, GRC. Within one field they have precise distinct meanings (distinctions table); Crosswalker straddles all of them, so which name a page uses depends on which community it’s drawing from. |
| Schema matching (narrow) | Database sense: finding corresponding elements (columns, fields, keys) between schemas. Crosswalker’s column-type detection is a simple case. |
| Schema mapping (narrow) | The executable transformation implementing a match — “split column A by comma, map each into column B.” |
| Ontology alignment (narrow) | Semantic-web sense: finding corresponding concepts with confidence scores. “AC-2 corresponds to CIS 5.2 at 0.85” is ontology alignment. |
| Ontology merging | Combining two ontologies into one. SCF folding 175+ frameworks into a single canonical set is the example. |
| Crosswalk edge semantics stack | Crosswalker’s layered commitment: STRM as the required predicate vocabulary + SSSOM as the required envelope + SKOS rejected as base but kept as an export format. Decision |
| OAEI | Ontology Alignment Evaluation Initiative — the annual benchmark for alignment algorithms. Recent LLM-based systems hit 0.83–0.95 F1. More |
| Formal Concept Analysis | Lattice-theory approach to finding structural correspondences between hierarchies without string similarity. Candidate for spine distillation. More |
Query engine — three layers
Section titled “Query engine — three layers”The query engine keeps three orthogonal layers apart (settled 2026-05-08; synthesis):
| Layer | What it is | Concept page |
|---|---|---|
| A — Query primitives | The 8 irreducible query verbs: filter · traverse · bind · project · aggregate · anti-join · set-op · diff (locked by Ch 29) | Query primitives |
| B — View shapes | Mechanism-neutral presentations: table · list · pivot · graph · hierarchy · timeline | View shapes |
| C — Recipes / reports | Instances composing primitives + a view shape — “Coverage Matrix” = filter + traverse + anti-join, drawn as a pivot | Recipe registry |
Query primitives is the single source for the verb definitions; this page does not restate them. Two names that used to live here are gone: standalone closure folded into traverse(depth=*), and pivot is a Layer B view shape, not a primitive.
| Term | Definition |
|---|---|
registerBasesView | Obsidian 1.10+ API letting a plugin register custom Bases view types. API reference |
crosswalkerPivot | The one custom Bases view shipped in v0.1.6 — renders the pivot shape, parameterized by recipe. “Coverage Matrix” is the launch recipe. |
| CQRS framing | Command Query Responsibility Segregation. Here: the query layer (Bases + codeblock + sqlite sidecar) is not the snapshot layer (materialization + timestamping + git). Don’t conflate a live read with point-in-time evidence. |
Query language & engine terms (engine internals)
Section titled “Query language & engine terms (engine internals)”Recurring in the Tier 2/3 engine research wave. Quick reference only.
| Term | Definition |
|---|---|
| Datalog | Declarative logic programming — write rules (derived(a,c) :- mapping(a,b), mapping(b,c)) and the engine derives all consequences. “SQL with built-in recursion.” Used for SSSOM chain rules; engine choice is Nemo. Verbose entry |
| SPARQL | The W3C query language for RDF — the SQL of the semantic web. Native fit for SSSOM (which is RDF-shaped); supports federation via SERVICE. |
| Recursive CTE | SQL’s WITH RECURSIVE for transitive closure and graph walks. The fallback when Datalog isn’t available; tractable to ~10⁵ mappings, collapses on full SSSOM expressivity. Ch 18 |
| Stratified negation | Datalog’s ability to negate another layer’s conclusions in a defined order — “find A→C mappings NOT derivable through any intermediate B.” Recursive CTE can fake it; Datalog optimizes it natively. |
| SPARQL property paths | Recursive operators inside SPARQL (?x (skos:exactMatch)+ ?y). Datalog-lite: no stratified negation, no rule-level aggregation. Ch 14 |
| OWL inference | Reasoning that derives implicit class/property relationships. Crosswalker does not currently rely on it. |
| SHACL | Shapes Constraint Language — W3C standard for validating RDF graphs (“every mapping_set MUST have a creator_id”). Used for SSSOM validation at the Tier 2/3 boundary. |
| WOQL | TerminusDB’s Datalog dialect (path(), dot(), slice()). Relevant only if TerminusDB is adopted. |
| HDT | Header-Dictionary-Triples — binary RDF distribution format, ~10–20× smaller than Turtle. Used by Comunica federation. |
Metadata ecosystem terms
Section titled “Metadata ecosystem terms”Owning page: metadata ecosystem.
| Term | Definition |
|---|---|
| Inline field | Legacy key:: value syntax in a note body. Not queryable by Bases; Crosswalker uses YAML properties and explicit edge records instead. |
| Properties | Obsidian’s native YAML frontmatter system (since v1.4). First-class and Bases-queryable. |
| Obsidian Bases | Native .base live views over vault properties. Bases filters and presents frontmatter; it does not by itself do multi-hop typed-edge traversal. More |
Related
Section titled “Related”- Artifact roles and authority — governing, extensional, intensional, administrative, representation, and carrier distinctions
- Mapping into Obsidian — source row → note on disk, and the two-kinds-of-link diagram
- Ontology lifecycle — where artifacts cooperate across recurring capabilities
- System model — picture-first artifact and tier relationships
- System architecture — representation tiers, logical layers, and components
- ETL and import — schema-as-primitive and Recipe-driven generation
- v0.1 schema spec — governing Tier 1 and ImportRecipe Schema Contracts