Ontology lifecycle
Six recurring capabilities
Section titled “Six recurring capabilities”Crosswalker supports ontology lifecycle management through six recurring capabilities: Acquire, Shape, Connect, Understand, Share, and Maintain. They are not a one-way pipeline or six artifact classes. A team can revisit any capability whenever sources, questions, mappings, release needs, or upstream versions change.
The lifecycle operates through linked artifacts with distinct roles and authority: governing Schema Contracts, extensional Knowledge Sets, and intensional Recipes. Execution Records and Package Manifests remain later, separate administrative envelopes.
| Capability | Core question | Current state |
|---|---|---|
| Acquire | What source material are we bringing under management? | Largely implemented for local acquisition; CSV is strongest, with XLSX and JSON support shipped and JSONL still open. |
| Shape | How should source structure be embodied as canonical Markdown? | Largely implemented through the wizard, ImportRecipe grammar, render(), enrichment, validation, and generation. |
| Connect | What semantic relationships should be asserted? | Partial; hierarchy, generated links, crosswalk-edge records, and evidence-link foundations exist, while full authoring workflows remain incomplete. |
| Understand | What questions and navigational views should the knowledge answer? | Partial; Bases live views, custom pivot, Tier 2 queries, and generated navigation exist, with broader view/report coverage still developing. |
| Share | What should leave the vault, in what representation, with what portability? | In progress; first exporter and portable ImportRecipe fidelity slices are implemented, while packaging and full recipe-library UX remain open. |
| Maintain | How do authority, mappings, and local work survive change? | Planned; research and primitives exist, but end-to-end update, diff, migration, and revalidation workflows are not yet shipped. |
Acquire
Section titled “Acquire”What: obtain structured source material and establish enough identity, version, and provenance to work with it safely.
Current: local file acquisition through the import wizard is established for CSV, XLSX, and JSON, with CSV as the strongest path. Acquisition is broader than selecting bytes: it should eventually identify the upstream publisher, source version, hash, license, and expected compatibility.
| Concern | Today | Direction |
|---|---|---|
| Local files | CSV, XLSX sheet/header selection, and JSON record/iterator selection | Add JSONL and continue hardening large-source readers |
| Source recognition | Headers, fingerprints, bundled-recipe matching | Publisher/version-aware recognition and source verification |
| Remote/community inputs | Manual download or local handoff | URL acquisition and curated registries without weakening provenance |
| Authority | Source reference and hashes captured during import | Explicit upstream authority distinct from local Tier 1 authority |
Acquired files are upstream inputs, not automatically Knowledge Sets or Packages. A file becomes a governed package member only when a future Package Manifest deliberately resolves it.
The retained #import anchor points here because import is now understood as the central write-side part of Shape, not the whole lifecycle.
What: decode source shape, normalize values, and re-embody concepts and assertions in Obsidian-native primitives.
| Piece | Role |
|---|---|
| Tier 1 Schema Contract | Governs valid Tier 1 record representations. |
| ImportRecipe | Intensional Recipe subtype governing deterministic source-to-Tier-1 behavior. |
| Import wizard / headless harness | Two interfaces over the same Recipe-driven generation path. |
render() | Pure coupling point from Recipe + concept identity to address and content regions. |
| Tier 1 | Canonical Crosswalker-managed representation/authority tier for local Knowledge Sets. |
Shape includes parsing, bounded transforms, hierarchy recovery, target-primitive selection, body/frontmatter emission, enrichment, pre-write validation, and re-import-safe merge behavior. The current implementation is largely complete for the v0.1 recipe grammar; format breadth and durable user Recipe storage remain active work.
Connect
Section titled “Connect”The retained #enrich anchor points here because enrichment is one way of connecting knowledge, alongside hierarchy, crosswalks, evidence, and other typed relations.
What: create or import semantic assertions among concepts, evidence, systems, observations, and other entities.
| Relationship level | Precise artifact term | Example |
|---|---|---|
| Governed collection | MappingSet | A released NIST-to-ISO mapping collection with identity, version, provenance, and license |
| Member assertion | MappingAssertion | nist:AC-2 subset-of iso:A.5.16 with confidence and justification |
| Source-to-vault editing | ImportMapping | Workbench state mapping source fields into Recipe-owned layout/frontmatter/body regions |
| Evidence relation | Junction/evidence assertion | A policy note implements a control with status, review date, and evidence metadata |
A MappingSet is an extensional Knowledge Set; an ImportRecipe is intensional policy. Keeping them separate prevents crosswalk content from being mistaken for instructions about how to generate it.
Current: generated hierarchy and navigation links, crosswalk-edge records, STRM/SSSOM semantics, and junction-note foundations exist. Authoring, review, MappingSet identity/membership, and full evidence workflows remain partial.
Understand
Section titled “Understand”What: project canonical knowledge for a question, then present the answer in a useful shape.
| Mechanism | Result | Authority/freshness |
|---|---|---|
| Obsidian Bases | Live view over current Tier 1 properties | Re-evaluated from current vault data; not a materialized result |
| Tier 2 SQL helpers | Qualified Tier 1 → Tier 2 projection used for joins and traversal | Derived and deletable; rebuildable from Tier 1 |
| Custom views / query processors | Interactive rendition | Derived from current data; renderer-dependent |
| Materialized snapshot | Persisted point-in-time query result | Reproducible but potentially stale; useful for publish/audit/comparison |
Crosswalker uses projection only with a qualifier: field projection, read/view projection, Tier 1 → Tier 2 projection, or editable UI projection. The wider product action is understanding structured knowledge, not turning every output into a new authoritative artifact.
Current: Bases live views, the custom pivot surface, Tier 2 query helpers, and generated hubs/navigation are available or partially available. Multi-shape reporting, richer traversal UI, and snapshot workflows remain incomplete.
What: export, publish, report, or distribute selected knowledge and reusable policy without collapsing content, instructions, and packaging into one object.
| Shared thing | Semantic role | Possible representation/carrier |
|---|---|---|
| Ontology or MappingSet | Extensional Knowledge Set | Tier 1 Markdown, STRM/OLIR TSV, SSSOM TSV, OSCAL JSON |
| ImportRecipe | Intensional Recipe specification | Canonical JSON |
| Live view definition | Recipe/query policy or binding | .base file or query declaration |
| Point-in-time report | Materialized snapshot | Markdown, JSON, PDF, or another export format |
| Resolved release | Future Package described by a Package Manifest | Zip, directory, or git repository as the physical carrier |
A Package has semantic resolution, integrity, dependency, license, and installation meaning. A zip, folder, or repository is only a carrier unless a manifest gives the collection package semantics.
Current: Share is in progress. Exporters and canonical ImportRecipe fidelity have landed in v0.1.7; durable Recipe library UX, broader round-trip proofs, package semantics, and signed distribution remain later work.
Maintain
Section titled “Maintain”What: preserve usable authority as upstream sources, local knowledge, mappings, schemas, and Recipes change.
| Maintenance concern | What must remain distinct |
|---|---|
| Upstream change | Publisher authority and source versions |
| Local regeneration | Canonical Tier 1 managed authority plus managed / user_preserve ownership |
| Mapping review | MappingSet identity, assertion membership, provenance, and publication state |
| Recipe evolution | Recipe specification version, compatibility, ancestry, and bindings |
| Runtime history | Future Execution Record rather than mutable Recipe fields |
| Distribution update | Future Package Manifest rather than assumptions based on a carrier filename |
Maintain includes diffing, stale-link detection, migration, revalidation, re-import, conflict handling, and release continuity. Research exists for ontology evolution, diff primitives, and consistency, but the integrated capability remains planned.
Maintain can send work back anywhere: changed source material returns to Acquire; changed structure to Shape; invalidated mappings to Connect; changed questions to Understand; and a new release to Share.
Linked artifacts cooperate across the lifecycle
Section titled “Linked artifacts cooperate across the lifecycle”No single config governs the whole lifecycle. Different artifacts cooperate through explicit relations while retaining separate authority.
| Relationship | Meaning | Lifecycle examples |
|---|---|---|
| Schema Contract governs representation | Defines what validates | Tier 1 Schema governs Tier 1 records; Recipe Schema governs ImportRecipe |
| Recipe describes intended behavior | States what should be done | ImportRecipe drives Shape; query policy drives an Understand view |
| Recipe binding selects concrete inputs/parameters | Makes reusable policy applicable | Source identity + chosen Recipe + parameters |
| Execution applies a bound Recipe | Performs work | Import run, query run, export run |
| Execution Record records outcome | Future separate receipt | Verified inputs, warnings, outputs, validation results |
| Tier 1 represents Knowledge Sets canonically | Holds authoritative local managed knowledge | Concepts, MappingAssertions, and evidence assertions |
| Qualified projection derives a rendition | Selects or reshapes authority for a purpose | Tier 1 → Tier 2, live view, materialized snapshot |
| Package Manifest resolves a release | Future distribution envelope | Selected Knowledge Sets, Recipes, dependencies, hashes, licenses |
This separation keeps the schema-as-primitive architecture intact: Schema Contracts govern, Knowledge Sets assert, Recipes intend, executions happen, records report, and packages distribute.
Related
Section titled “Related”- Artifact roles and authority — the governing artifact model used by this lifecycle
- Terminology — Knowledge Set, Recipe, MappingSet, live view, snapshot, package, and carrier definitions
- System model — picture-first relationship among artifacts, tiers, and runtime components
- System architecture — representation tiers and logical layers
- ETL and import — Shape capability and schema-as-primitive details
- Ontology evolution — Maintain capability research
- Roadmap — implementation sequence and current delivery status