Operational landscape
The operational landscape shows who does what across the ontology ecosystem. It combines three dimensions:
- Institutional actors — who creates, maps, regulates, consumes
- Ontology components — frameworks themselves vs crosswalks vs evidence vs interchange formats
- Resource intensity — one-time investment vs periodic updates vs continuous operational work
This is the combined view that determines what to build into software, what to crowdsource, and what requires ongoing resources (money, people, tooling, expertise).
The gradient
Section titled “The gradient”The gradient runs from teal (build once, rooted in first principles) through yellow (community-maintained, evolves slowly) to red (ongoing operational work that never ends).
The responsibility matrix
Section titled “The responsibility matrix”Who owns what across the ontology lifecycle? This matrix maps institutional actors against ontology components, colored by resource intensity.
Color key: ● One-time/rare — ● Periodic updates — ● Continuous ops — ● N/A
| Ontology definitions | Ontology versioning | Crosswalk definitions | Crosswalk maintenance | Evidence mapping | Standards/ formats | |
|---|---|---|---|---|---|---|
| Standard bodies NIST, ISO, MITRE | Creates frameworks 800-53, CSF, ATT&CK | Publishes versions Versioning patterns | Some official crosswalks CSF↔800-53 | Rarely maintains others’ crosswalks | N/A | Creates OSCAL, STIX |
| Industry groups CRI, OWASP, PCI SSC | Creates domain frameworks CRI Profile | Publishes versions ad-hoc cadence | Provides crosswalks in Excel workbooks | Updates when upstream frameworks change | N/A | Rarely |
| Regulators SEC, FFIEC, NYDFS | Doesn’t create — mandates adoption | References specific versions in mandates | N/A | N/A | N/A — requires you to do it | May mandate specific formats |
| Mapping orgs OLIR, SCF, CTID | N/A | Tracks upstream version changes | Creates crosswalks OLIR, SCF STRM, CTID | Continuous re-mapping Staleness problem | N/A | Uses SSSOM |
| GRC vendors ServiceNow, Drata | Implements in software | Updates libraries when versions release | Bundles crosswalks in product | Ongoing library maintenance | Provides UI for customer mapping | May support OSCAL import/export |
| Your organization | Imports via Crosswalker | Re-imports on update Resilience strategies | Consumes community crosswalk configs | Staleness detection Constraint enforcement | Core GRC work Evidence mapping | Uses for import/export |
| Auditors | N/A | Verifies version compliance | N/A | N/A | Verifies your evidence links | May require specific formats |
Reading the matrix: Each cell shows what that actor does for that component, with links to relevant KB pages. The left border color indicates resource intensity — green (one-time), yellow (periodic), red (continuous), gray (not applicable).
Key insights from the matrix:
- Crosswalk maintenance is red for mapping orgs, GRC vendors, AND your org — it’s the most resource-intensive ongoing work across the ecosystem. Mapping orgs like SCF and UCF reduce this burden with a synthetic spine (also: hub-and-spoke mapping) architecture — mapping each framework once to a canonical intermediate instead of authoring O(N²) direct pairwise crosswalks. Whether Crosswalker should consume, inherit, or build such a spine is an open Foundation question — see Challenge 06 and the 04-10 synthesis.
- Evidence mapping is your org’s continuous burden — no one else can do it for you
- Standard bodies do the one-time creation work but rarely maintain crosswalks to OTHER frameworks
- Regulators mandate but don’t create or maintain — they add requirements without resources
The five tiers of work
Section titled “The five tiers of work”Tier 1: First-principles software (build once)
Section titled “Tier 1: First-principles software (build once)”Work rooted in the fundamental nature of the problem domain. Once solved correctly, this rarely changes because the underlying principles don’t change.
| Work item | Why it’s resilient | Related |
|---|---|---|
| EvolutionPattern taxonomy | Ontologies have always evolved these ways — the patterns are structural | Ontology evolution |
| Core parser/transform/generate library | CSV/XLSX/JSON parsing is a solved problem; generation is deterministic | Layered architecture |
| VaultAdapter interface | The abstraction between vault operations and platform is stable | Why files |
| SCD type strategies | Data warehouse patterns from the 1990s — proven, unchanged | Data model resilience |
| Config-as-code schema | JSON/YAML schema design is durable; migrations handle evolution | Config schema |
Business analogy: This is R&D. High upfront cost, near-zero marginal cost afterward.
Tier 2: Refined software (evolves slowly)
Section titled “Tier 2: Refined software (evolves slowly)”Built on first principles but adapts as the ecosystem shifts. Changes on the order of years, not months.
| Work item | What causes change | Related |
|---|---|---|
| Transform engine (24 types) | New data patterns emerge; new framework formats appear | Ontology lifecycle: Import |
| Migration strategy engine | New SCD type combinations discovered through practice | Constraint enforcement |
| Plugin UI (wizard, settings) | Obsidian API changes; UX improvements from user feedback | Roadmap: Formats |
| Typed link syntax | Metadata ecosystem evolves (Bases, Datacore) | Link metadata |
Business analogy: This is product engineering. Continuous improvement, but the foundation doesn’t change.
Tier 3: Community-maintained (shared work)
Section titled “Tier 3: Community-maintained (shared work)”Work that’s per-framework but shareable. Once someone configures a framework, everyone benefits. This is where community leverage matters most.
| Work item | Who does it | Related |
|---|---|---|
| Evolution profiles (per-framework YAML) | Community contributes; Crosswalker validates | EvolutionPattern spec |
| FrameworkConfig presets (import configs) | First user configures; shares via registry | Config schema |
| Crosswalk mapping data | Often sourced from OLIR, SCF, CTID; community refines | Framework crosswalks |
Business analogy: This is the marketplace/ecosystem. The more contributors, the more valuable each contribution becomes. Like npm packages or Terraform providers.
Key insight: This tier is where Crosswalker’s community config registry would create the most value — the hard per-framework work done once, shared infinitely.
Tier 4: Operational maintenance (ongoing)
Section titled “Tier 4: Operational maintenance (ongoing)”Work that recurs because the external world changes. Cannot be eliminated — only automated or made more efficient.
| Work item | Why it recurs | Related |
|---|---|---|
| Framework version tracking | Framework owners publish updates on their own schedules | Framework versioning |
| Crosswalk refresh | When either framework in a crosswalk updates, the mapping may go stale | Crosswalk staleness |
| Stale detection notifications | Users need to know when their imported snapshot is outdated | Constraint enforcement |
| Community config validation | Submitted configs need review, testing, version bumping | Progressive classification |
Business analogy: This is DevOps / SRE. If you built a business, this is where subscription revenue would fund ongoing labor. The institutional timing problem means this work literally never ends.
Tier 5: User work (your team’s effort)
Section titled “Tier 5: User work (your team’s effort)”Work that’s specific to YOUR organization. No tool can eliminate it — only make it more efficient.
| Work item | Why only you can do it | Related |
|---|---|---|
| Evidence mapping | Only your team knows which policies satisfy which controls | GRC teams |
| Assessment documentation | Only your team knows your implementation details | Evidence mapping |
| Audit trail maintenance | Only your team can answer auditor questions | Institutional landscape |
| Custom crosswalks | Your org may have unique mapping needs between internal and external ontologies | Schema matching |
Business analogy: This is the customer’s work. The tool makes it faster and more reliable, but it’s fundamentally human judgment.
Why this matters architecturally
Section titled “Why this matters architecturally”The gradient directly maps to the layered architecture:
| Tier | Architecture layer | Investment type |
|---|---|---|
| Tier 1 (first principles) | Spec | One-time R&D |
| Tier 2 (refined software) | Library/SDK | Continuous engineering |
| Tier 3 (community) | Framework drivers | Ecosystem building |
| Tier 4 (operations) | Registry/infrastructure | Ongoing operations |
| Tier 5 (user work) | Plugin UX | Customer success |
The goal of Crosswalker’s architecture: Push as much work as possible toward Tier 1 (solved once, resilient forever). Where that’s impossible (Tiers 3-4), build community infrastructure so the work is shared. Only Tier 5 is irreducibly the user’s burden.
The sustainability question
Section titled “The sustainability question”If this were a business:
- Tiers 1-2 are funded by initial development (open source contributions, grants, or VC)
- Tier 3 is self-sustaining once the community is large enough (network effects)
- Tier 4 is the ongoing cost that requires either subscription revenue, sponsorship, or dedicated volunteers
- Tier 5 is the value proposition — you sell efficiency, not elimination, of this work
The EvolutionPattern taxonomy is a Tier 1 investment that reduces Tier 4 costs — by classifying evolution patterns upfront, stale detection and migration become more automated and less human-dependent.
Resources
Section titled “Resources”- Ontology lifecycle — which lifecycle phases map to which tiers
- Layered architecture — spec → library → integrations
- Institutional landscape — who does the work at each tier
- Ontology evolution — why Tier 4 work never ends
- Vision alignment — decisions that shape the tier distribution
- Roadmap — what’s being built in which order