Foundation commitments and follow-on research — pairwise+pivot, junction-notes-by-tier, StewardshipProfile, meta-schema lifecycle

How to read this log

This is a decision log, not a synthesis or orientation log. Read this together with the morning orientation log: the orientation log frames the open Foundation problems; this log captures the commitments, clarifications, and new research callouts that came out of re-reading the orientation pass plus the Challenge 06 research deliverable that landed in .workspace/ today.

A separate direction log is planned next — that one will reform the roadmap based on what’s committed here. This log deliberately does not edit the roadmap.

Why this log exists

This morning the orientation log reframed Foundation in the web-of-webs metaphor and listed the 6 forced-but-unmade decisions. Reading it back through made several things clearer; one of those decisions also resolved itself, because a fresh-agent research session against Challenge 06: Pairwise vs synthetic spine produced a concrete deliverable, preserved verbatim at Ch 06 deliverable: Pairwise vs synthetic spine and load-bearing input for §2.1 below.

Today’s pass:

• Commits five positions (§2): pairwise + optional pivot, junction-notes-by-tier, evidence-link schema as default + marketplace direction, tier-aware reporting/rendering, and the meta-level commitment that every Crosswalker-internal schema is versioned and migration-aware
• Clarifies four points where the morning orientation log undersold or mis-framed the picture (§3)
• Renames EvolutionPattern → StewardshipProfile (§3.2)
• Spins up three new research challenges that surfaced (§4)
• Archives the two resolved challenges (06, 07) (§5)
• Defers roadmap edits to the upcoming direction log (§6)

Commitments

2.1 Pairwise + optional inheritable pivot (Challenge 06 resolution)

Terminology note: this project uses pivot as the primary term — also known as spine, hub, interlingua, canonical intermediate ontology, common controls (compliance literature), or canonical pivot (schema-matching literature). All refer to the same architectural pattern: a single intermediate ontology that source ontologies map to, instead of mapping pairwise to each other. See §3.4 below and the schema-matching concept page.

Commitment: deferred-pivot hybrid. Pairwise crosswalks are first-class. A pivot/spine is optional and inheritable, not authored. SCF (v2025.4+) is the default inheritable pivot. Persistence is SSSOM-on-markdown. Derived mappings are computed on demand from pivot-routed composition; never stored as primary facts.

Concretely, per the Challenge 06 deliverable:

• Pairwise mappings are SSSOM-style records in markdown frontmatter. Mandatory: subject_id, predicate_id, object_id, mapping_justification. Predicates are drawn from the STRM / NIST IR 8477 set-theory vocabulary (equivalent-to, subset-of, superset-of, intersects-with, no-relationship).
• A user can optionally import a pivot bundle (default: SCF). Pivots live in their own vault folder, content-addressed by sha256 of the imported snapshot. Multiple pivot versions can coexist.
• Derived mappings carry a derivation_path, an inherited mapping_date (the minimum of component dates), and a downgraded predicate per the SSSOM RCE chain rules. They are visually distinct from authored mappings in any rendering.
• Authored mappings always outrank derived ones for the same subject/object pair. Conflicts surface as explicit “review needed” items.
• Exit strategy: pairwise data is the source of truth, so SCF disappearing degrades Crosswalker to a pure pairwise tool with stale derived edges — not a catastrophe. Fallback options (graceful degradation): (1) freeze last SCF snapshot, (2) community fork, (3) migrate to OSCAL Control Mapping Model when stable, (4) FCA-reconstruct a pivot from in-vault pairwise data.

Validity stamp (reproduced verbatim from the deliverable): “This recommendation holds until (a) the OSCAL Foundation publishes a v1.0 stable Control Mapping Model with a public derived-mapping convention, (b) SCF Council changes its license terms or ceases monthly STRM releases for >12 months, or (c) Crosswalker users routinely import >10 frameworks per vault. Re-evaluate at the earliest of those events, or no later than Q4 2027.”

The user’s added emphasis: most of the engineering work for this commitment is not in the underlying data structure (which stays simple — pairwise SSSOM records + an optional content-addressed pivot/spine folder). It’s in the reporting and rendering layer: pulling multi-hop pivot-traversal results into merged tabular views for an analyst, with the right disclosure (authored vs derived), the right staleness signal, and the right blast-radius indicator. That problem is its own research item — see §4.3 Challenge 10.

2.2 Junction notes confirmed — but feasibility is tier-aware

Commitment: junction notes (edge-as-note reification) for evidence links, with the explicit caveat that practical feasibility is tier-bound.

The 04-10 evidence-link edge model synthesis committed the architecture: one markdown file per evidence→ontology edge, 13-field flat-YAML frontmatter, OSCAL by-component round-trip. That direction is right. Today’s commitment adds the operational caveat:

• Tier 1 (files-canonical only) — junction notes are usable up to small-to-medium framework counts (per the Challenge 06 deliverable and the user’s own analysis: ~3–5 frameworks comfortably; 5–10 painful but tractable; >10 not realistic without a pivot reducing proliferation pressure). The Tier 1 ceiling is real but not catastrophic if the vault stays under it.
• Tier 2 (sql.js sidecar) and Tier 3 (server-backed) — junction notes scale comfortably to GRC-grade volumes (tens of thousands of evidence links) because the index, query, and cross-tabulation work happens off-files in the sidecar/backend.
• The pivot reduces junction-note proliferation pressure proportionally. With a pivot/spine, you don’t need to author N×N pairwise evidence links for analogous controls in different frameworks — one evidence link to the pivot concept covers the long tail through derivation.

Practical implication: a small GRC team running 3 frameworks can ship on Tier 1. A larger compliance team running 7+ frameworks needs the Tier 2/3 backend to be performant. We tell them this honestly in the docs.

2.3 Evidence-link schema is our shipped default; architecture supports a marketplace

Commitment: the 13-field junction-note schema from the 04-10 evidence-link synthesis is Crosswalker’s default, shipped-out-of-the-box evidence-link schema. The architecture should support user-loadable alternative schemas (a “schema marketplace” concept) so different teams or domains can choose schemas that match their workflows.

Examples of why someone would want a different schema:

• Healthcare teams may want HIPAA-specific status vocabularies
• Financial-services teams may want SOX 404-aligned field semantics
• Public-sector teams already on FedRAMP may want OSCAL by-component directly with no Crosswalker layer
• A research lab running biomedical ontologies may want full SSSOM with no compliance-flavored fields

Open meta-question — partly answered today: “Can you change the schema of that schema?” — i.e., is the schema marketplace itself versioned and migration-aware? The general principle is committed in §2.5 below: every Crosswalker-internal schema (the default evidence-link schema, every marketplace-distributed alternative, plus all the others Crosswalker invents) is versioned and migration-aware. The marketplace-specific sub-questions — can two schemas be merged, can a user inherit-and-extend, what’s the conflict-resolution UX when an installed alternative schema gets a new version — are deferred to the upcoming direction log.

Out of scope today: marketplace mechanics (Obsidian’s plugin-distribution constraints, signing, sandboxing of user-loaded schemas). Today commits the direction and the meta-schema constraint (§2.5); mechanics follow.

2.4 Tier-aware reporting / rendering

Commitment: Crosswalker’s three tiers correspond not just to storage (files vs sidecar vs server) but to rendering capability.

• Tier 1 (files only) — extensive performance limitations. The user’s specific framing: the plugin generates Bases-compatible folders with materialized joined/merged data inside them. Custom plugin logic walks the graph (ontology nodes + crosswalk edges + evidence links), materializes a flattened view for a given report, and writes it to a folder Bases can render. This is essentially “materialized SQL views, but as folders of notes.”
• Tier 2 (sql.js WASM sidecar) — the materialization moves into SQL. Pivot tables, cross-tabulation grids, and ad-hoc analytical queries become tractable. The sidecar is rebuilt from files on import / on demand; files remain the source of truth.
• Tier 3 (server-backed) — same model, scaled out; multi-user editing, real-time dashboards, externally exposed APIs.

Multi-hop pivot renders (per §2.1) — when a render needs to show subject control + pivot/spine concept + object control merged with metadata from all three legs, that’s a graph traversal followed by a flatten. Tier 1 produces it as a folder; Tier 2 produces it as a SQL query result; Tier 3 produces it as a live dashboard. Same semantics, different storage.

The bridging engine question — what engine does the graph-traversal-then-flatten work? That’s its own research challenge; see §4.3 Challenge 10.

2.5 Crosswalker eats its own dog food — every Crosswalker-internal schema is versioned and migration-aware

Commitment: Crosswalker invents schemas to manage ontology lifecycle — StewardshipProfile (the rename from EvolutionPattern), the 13-field junction-note schema, FrameworkConfig, the _crosswalker metadata block, the pivot snapshot manifest, the lifecycle change record schema, the SSSOM-on-markdown crosswalk record. Each of these schemas itself has a lifecycle. When Crosswalker decides to change one of its own schemas — to add a field, deprecate a status value, restructure a sub-schema — that’s a real change with a real cost to vaults that already encode user data in the prior shape.

This is the meta-level concern that the morning orientation log’s “lifecycle meta-web” was genuinely pointing at — see §3.3 for the framing fix.

Architecturally, this means:

• Every Crosswalker-internal schema is versioned. The exact mechanism (a schema_version field, a namespace+version pair, a content-addressed hash) is deferred to the direction log; the commitment is that no Crosswalker-internal schema ships unversioned.
• Every internal schema has a documented migration path when it changes — automated where mechanical (rename a field), interactive where ambiguous (split one field into two), with explicit user consent for anything destructive.
• Backward-compatibility windows are a published policy, not implicit. When a schema changes, the prior version is read-supported for at least one minor release; write-supported until users have a path off the deprecated shape.
• The schema-marketplace meta-question from §2.3 (“can you change the schema of that schema?”) is one specific instance of this general principle. The marketplace is not exempt — user-loadable alternative schemas are also subject to versioning and migration concerns, just played one level up.

Concrete list of Crosswalker-internal schemas in scope (non-exhaustive; the principle applies to anything Crosswalker invents to manage ontology lifecycle):

Schema	Where it lives	Status
StewardshipProfile (renamed from EvolutionPattern, see §3.2)	Per-framework YAML/JSON config	Foundation — schema design in flight
Junction-note 13-field schema	Markdown frontmatter on every evidence-link junction note	Committed shape; evolution policy TBD
_crosswalker metadata block	Top-of-file YAML on every Crosswalker-generated note	v1 today; v2 planned per roadmap
FrameworkConfig	Per-framework JSON/YAML import config	v2 in design — see config-schema-design
Pivot snapshot manifest	Per-imported-pivot folder, content-addressed by sha256	Committed shape; future spine drivers may extend
Lifecycle change record schema	Per-version-transition record (the 9 atomic ops + composites)	Foundation — schema design in flight
Crosswalk SSSOM-on-markdown record	Markdown frontmatter on each pairwise crosswalk file	Committed today (§2.1)

This is a constraint, not a research challenge — it should ride along with every Foundation schema decision from this point forward. Whenever a schema lands or changes, document its versioning policy and migration story in the same pass. The direction log will translate this into a concrete versioning-and-migration policy spec that every internal schema must comply with.

Open sub-question deferred to direction log: do all internal schemas use the same versioning convention (e.g., semantic schema_version: 1.2), or do different schemas use different conventions (semver vs. content-addressed vs. release-tag-aligned)? Probably one convention per category (data schemas vs. config schemas vs. log records), but worth deciding explicitly.

Clarifications

3.1 STRM/SSSOM and graph edit/transformation language are not the same thing — and they are not in tension

The user explicitly flagged confusion here. Resolving it:

                    crosswalk
   Ontology web A  ◄────────────►  Ontology web B
                       ▲
                       │  these edges have LABELS and PROVENANCE.
                       │  STRM/SSSOM is the vocabulary for that.
                       │  (= equivalent-to, subset-of, with mapping_justification, confidence, ...)
                       │
                       │
                       ▼
   ┌───────────────────────────────────────┐
   │   Lifecycle (across versions)         │
   │   Same web at time T₀ vs time T₁      │
   │   Connected by graph-EDIT operations  │
   │   (add node, rename, split, merge,    │
   │    delete edge, ...)                  │
   │   The 9 atomic primitives + 4         │
   │   composites are the vocabulary       │
   │   for THIS layer.                     │
   └───────────────────────────────────────┘

The two layers:

Layer	Question it answers	Vocabulary
Edge labels (between two ontology graphs)	“How does control X in framework A relate to control Y in framework B right now?”	STRM (set-theory predicates) + SSSOM (envelope: justification, confidence, author, date)
Graph operations (across versions of one graph)	“What changed in framework A between version r5 and version r6?”	Graph edit / structural change primitives (add, remove, rename, split, merge, deprecate — the 9 atomic ops)

They speak about different things. STRM/SSSOM never describes the act of changing a graph; graph-edit primitives never describe the labels on relationships between two graphs. The user is right that graph-edit/transformation language is a more fundamental description of the lifecycle problem — but that fundamentality applies to lifecycle, not to crosswalks.

Both vocabularies stay; both have a place; they don’t compete.

3.2 StewardshipProfile — the EvolutionPattern rename, committed

Rename committed: EvolutionPattern → StewardshipProfile.

The morning orientation log already framed this concept correctly — it captures how the steward of an ontology (institution, team, person) decides to handle changes — but the original name EvolutionPattern leaked the wrong implication: that it was a model for predicting evolution from data. It is not. It is a declaration the steward makes, not a statistic Crosswalker infers.

What the schema captures (independent of name):

• Fields like release cadence, breaking-change policy, ID stability, changelog format, default ingest behavior — declarations made by the steward, not derived from version history.
• Two stewards managing the same data can choose different profiles; both valid. The choice is institutional, not algorithmic.
• The role of the profile is to set defaults for how Crosswalker handles ingest of a new version of that ontology — auto-migrate, prompt the user, freeze, etc.

Why StewardshipProfile is the right name:

• Stewardship names the right verb (a steward stewards an ontology over time)
• Profile names the right noun (it’s a declarative profile, like a personality profile or a configuration profile, not an inferred model)
• Drops Pattern, which read as “an empirically observed pattern” — opposite of what we mean
• Drops Evolution, which suggested data-driven derivation rather than human declaration

Alternatives considered and rejected:

• FrameworkHandlingProfile — accurate but verbose; doesn’t generalize to non-framework ontologies (taxonomies, registries, schemas)
• OntologyMaintenancePolicy — too compliance-flavored; “policy” implies enforcement when this is more like a default-setter
• VersioningProfile — too narrow; the profile covers more than versioning (also: changelog format, default ingest behavior, breaking-change policy)

Cascading edits — flagged for the direction log:

This rename ripples through:

• The terminology page — definitions need updating
• The original 04-03 EvolutionPattern taxonomy draft log — add a top-of-file rename callout (don’t rewrite history)
• The 04-10 foundation research synthesis — incidental mentions
• The roadmap — at least one Foundation item references EvolutionPattern by name
• Any of today’s prior-pass logs that mention EvolutionPattern (this log, the orientation log) — keep both names visible during the transition window per §2.5 Crosswalker-eats-its-own-dog-food

The direction log will land all the cross-KB rename edits in one pass. Until then, this log uses the old and new names side-by-side as EvolutionPattern → StewardshipProfile to keep links and search working.

3.3 What the “lifecycle meta-web” was actually about

The morning orientation log used the phrase “lifecycle meta-web” in its table of webs. My first instinct was to read that as the obvious-but-trivial claim that every web has a lifecycle problem (source ontologies evolve, evidence ages, pivots get versioned). That reading is true but weak — and it caused me to soften the table cell to “Lifecycle (cross-version) graph” with a note that this isn’t a separate meta-web. That softening was wrong-direction.

The real point — and what meta-web was genuinely pointing at — is the level above: every schema Crosswalker itself invents for ontology lifecycle management is itself subject to change. When Crosswalker changes its own internal schemas, the existing user data in prior shapes needs a migration path. Crosswalker eats its own dog food — the tool that manages ontology lifecycle for users must also manage the lifecycle of its own schemas.

The substantive commitment that follows from this clarification lives in §2.5 above. The orientation log’s table cell will be re-edited to reflect this — the cell that was “Lifecycle (cross-version) graph” now reads “Crosswalker-internal schema lifecycle (the meta-web)” with the clarifying language that this is a level above the first-order ontology-evolution problem, not just a synonym for it.

3.4 Pivot ≡ spine ≡ interlingua ≡ hub ≡ canonical intermediate

These are all the same thing. Different communities settle on different terms; Crosswalker spans the communities, so it’s worth being explicit about which term we lead with and why.

Community	Preferred term	Why
Schema-matching / ontology-alignment / data-engineering	pivot, interlingua, canonical intermediate	”Pivot” is the most familiar in data/ETL/dimensional-modeling contexts; “interlingua” comes from machine translation literature; both predate the compliance use
Compliance-mapping (SCF, UCF, NIST OLIR)	spine, hub, common controls	Anchored in hub-and-spoke imagery; “common controls” is the OLIR vocabulary
Category theory / functorial data migration	apex, pullback object	Pure formalism; rarely used in product docs

Crosswalker’s primary term is pivot, with spine as the most common synonym (especially when the audience is a compliance analyst and the surrounding context is SCF / UCF / NIST OLIR). On first introduction in any new doc, mention at least two of the synonyms in parentheses so a reader from either background can connect the dots — this is an abstract project and overly-narrow terminology hurts.

The schema-matching concept page has the canonical alias callout. Updates to the terminology page ride along with the upcoming direction log.

Follow-on research challenges

Three new challenges spun up today, each as a fresh-agent brief in zz-challenges/. Brief summaries here; full briefs in the linked challenge files.

4.1 Challenge 08 — Git-history audit-trail tenability

The 04-10 evidence-link synthesis assumed git history (with three hardening measures) is a sufficient audit trail. The user is appropriately skeptical: “I’m honestly not sure git history is tenable for audit trail.”

Brief: stress-test against AICPA SAS 142, PCAOB AS 1105, ISO 27001, HIPAA 164.312(b), legal admissibility (FRE 901/902, SOX 404), and how mature GRC tools handle the same problem (Hyperproof, Drata, Vanta, Auditree). Identify failure modes (force-push, lost branches, signature-verification gaps, clock-skew). Recommend either a reaffirm-with-conditions, an augmentation (RFC 3161 timestamping? WORM tier?), or a replacement.

Full brief: Challenge 08: Git history audit-trail tenability

4.2 Challenge 09 — UUID / CWUUID cross-cutting strategy

The 04-10 evidence-link synthesis flagged “UUID enterprise resilience scope” as one specific deferred sub-decision. Today’s commitment broadens the scope: the user’s framing is that we will need UUIDs in many ways across the entire web-of-webs, not just on evidence-link junction notes.

Brief: enumerate every place a persistent identifier matters (ontology nodes, crosswalk edges, junction notes, evidence notes, framework versions, pivot/spine snapshots, mapping authors, vault identity, schema definitions, lifecycle change records). Compare options (UUIDv4/v7, ULID, CID, OSCAL UUIDs, custom CW- prefix). Recommend a minimum viable scheme for Foundation with explicit OSCAL round-trip mapping.

Full brief: Challenge 09: UUID / CWUUID cross-cutting strategy

4.3 Challenge 10 — Graph→tabular bridging engine

Crosswalker’s data is fundamentally a graph; most useful outputs are tabular. The user’s framing: “need to research and/or develop logic that can pull in everything to be represented as graphs and then be able to query into merged tabular or structured or whatever views.”

Brief: survey relevant engines (DuckDB-WASM, KuzuDB, Apache AGE, Neo4j+Cypher, oxigraph, sql.js, Datacore, Polars). Design the bridging architecture across all three Crosswalker tiers — including the Tier-1-specific suggestion of “plugin-generated Bases-compatible folders with pre-joined/merged data.” Define the data-flow contract: files canonical, derived stores at Tier 2/3, queries can touch either tier, writes always land in files.

Full brief: Challenge 10: Graph→tabular bridging engine

Housekeeping — resolved challenges archived

Two challenges have produced research deliverables and have corresponding committed positions. Today they move to zz-challenges/archive/ so the active list stays focused. Briefs are preserved verbatim (re-runnable) with resolution callouts pointing to the resolving log.

Challenge	Resolved by	Archived path
06: Pairwise vs synthetic spine	This log §2.1 + research deliverable in .workspace/	zz-challenges/archive/06-synthetic-spine
07: Link metadata / edge model	04-10 evidence-link edge model synthesis, reaffirmed by this log §2.2	zz-challenges/archive/07-link-metadata-edge-model

Stale internal links across the KB have been updated to point to the new archive paths in this same commit.

Where this is going next

The user has signaled an upcoming direction log that will reform parts of the roadmap based on what’s committed here. That log is not this log. Today’s pass is decisions and clarifications; the direction log will translate them into roadmap deltas (which Foundation items move to “committed direction,” which become Phase A pure paperwork, which spawn new Phase B challenges, etc.).

Until that direction log lands, the roadmap Foundation section still reads as it did this morning — with Challenge 06 marked as the biggest open question (now resolved by this log) and the evidence-link edge model marked as committed (which it is, with the tier caveat now added).

Related

Today’s pair (read together):

• Foundation state of play (orientation, 05-01 AM) — the morning orientation log; frames the open Foundation problems
• This log — afternoon decisions, clarifications, new research

The 04-10 syntheses (load-bearing for today’s commitments):

• Foundation research synthesis (04-10) — STRM + SSSOM crosswalk vocabulary; surfaced the synthetic-spine question
• Evidence-link edge model synthesis (04-10) — junction notes + 13-field schema; reaffirmed today with tier caveat

The Apr 8–9 cluster (graph-edit / atomic operations background — informs §3.1):

• Atomic operations research (04-09) — 9 atomic ops + 4 composites
• Primitives depth and pluggable layers (04-09)
• User-first ontology maintenance (04-09)
• Ontology evolution first principles (04-08)

The Apr 3 cluster (architectural foundations):

• Vision alignment decisions (04-03)
• Layered architecture vision (04-03)
• StewardshipProfile (then EvolutionPattern) taxonomy draft (04-03) — the draft this log reframes and renames in §3.2
• Why Obsidian, why files (04-03)

Research challenges (active + archived):

• Active: 01, 02, 03, 04, 05
• New today: 08 git-audit, 09 UUID/CWUUID, 10 graph→tabular
• Archived: 06 spine, 07 edge model
• Challenges index · Archived index

Concept pages (vocabulary and conceptual depth):

• Terminology
• Schema matching — pivot / interlingua / spine / hub aliases (canonical alias callout added)
• Ontology lifecycle
• Ontology evolution
• Framework crosswalks
• Metadata ecosystem — Bases / Dataview / Datacore landscape

External references for §2.1 (pairwise+spine commitment):

• SCF — Secure Controls Framework — default inheritable spine
• SSSOM — Simple Standard for Sharing Ontological Mappings — persistence model
• STRM — Set Theory Relationship Mapping (NIST IR 8477) — predicate vocabulary
• OSCAL Control Mapping Model — future eventual default per validity stamp
• Ch 06 deliverable: Pairwise vs synthetic spine — full research preserved verbatim

Roadmap (untouched today; deferred to direction log):

• Roadmap root
• Roadmap: Foundation section — where the next direction log will land changes