Cross-space references: linking entities across schemas and spaces

[mindsocket]

Background

Originally framed as "compound OSTs" for org/product/team matrix hierarchies, this issue is now better understood as a broader question: how should entities in one space reference or relate to entities in another space?

The matrix cascade use case (an org strategy space laddering into a team opportunity space) is one instance of a more general need. A goal space may reference a strategy space. A delivery space may plug into an opportunity space. A landscape or context space may serve as shared background for multiple other spaces.

See also #48 for the framing of context trees as durable structures that carry organizational meaning — the cross-space linking question is partly about how those structures interrelate.

Original motivation (still valid)

Cutler points out that organizational operating systems have "matrix cascades": a business unit's goal stack doesn't just ladder up to the org strategy — it has connections across to the BU strategy, possibly something else entirely. Some relationships are up/down ladders; others are zoom in/out; others link across context.

A flat forest of trees is wrong (disconnected). Fractal doesn't quite fit either. What's needed is a way to express directed relationships between entities that live in different spaces, which may have different schemas.

Generalised framing

Three overlapping cases:

1. Same schema, multiple instances (original case): an org, business unit, and team each run the same schema but their nodes relate to each other — e.g. a team goal rolls up to a BU goal. This is a space configuration question: how to declare that space A's goal type links to space B's goal type.

2. Different schemas, related entity types: a solution in an opportunity space links to a ticket or epic in a delivery space. The schemas are different, but the relationship is meaningful and worth capturing.

3. Context or landscape spaces as shared anchors: a shared strategy space, product taxonomy, or capability map that multiple other spaces reference. This is Cutler's "context tree" use case directly — the durable background structure that other spaces connect into.

What this probably looks like

This is a layer above individual schemas — either:

• Multi-space configuration: space config declares inter-space link fields and which remote space/type they resolve to
• Composite schemas: a schema that declares relationships between two complete schemas (as opposed to partial $ref composition within a single schema, which is more of a current convention)
• Or both, at different layers of formality

The current $ref composition model (schema built from partials) handles intra-schema building blocks. Cross-space references are an inter-schema / inter-space concern and likely need separate tooling support.

Open questions

• Where does the cross-space link declaration live? (space config, a top-level multi-space config, or in the schema itself?)
• How are dangling cross-space wikilinks validated? (requires loading both spaces at validation time)
• Should this be resolved at schema level (composite schema) or at runtime (multi-space validation mode)?
• How does this interact with the show command and Miro sync?

Relates to

• Schema composability: shared building blocks and team-composed schemas #17 (schema composability — the intra-schema building block layer this would sit above)
• Clarify purpose of hierarchy, consider a more general relationships construct to complement it. #31 (clarifying hierarchy vs. general relationships)
• Review JC post #48 (cross-space linking is partly motivated by the context tree framing — spaces of different types need to interrelate)
• Original issues: Reorganize schema files into schemas/ directory with shared refs and space-level config #13, Create strict_ost schema aligned with Teresa Torres' Opportunity Solution Tree model #15, Provide guidance for adapting the general model to a team's specific approach #9

[mindsocket]

Exploratory prompt, WIP...

Use /structured-context to configure with a schema. It is a combination of knowledge wiki, opportunity solution tree, and a new to-be-discovered schema based on Simon Wardley's ideas on wardley mapping, landscape, doctrine, etc (there's another doc to be found in the vault that elaborates on these). Consider the partial schemas that exist and can be resued as well as new partial schemas that encapsulate parts of these different knowledge domains. We might end up with a super-schema for the whole space that includes large parts of a _wardley_mapping, _wardley_doctrine, strategy (based on bundled _sctx_base.json or general.json), and bundled knowledge_wiki.json. If there are any issues encountered with doing this we have the option of raising new suggestions against the structured-context project (which I maintain). Note that there's an existing "" space configuration focused just on the /Opportunities directory. That should be renamed to _opps. That in itself will be a good test of whether nested spaces can co-exist, and what the pitfalls might be.

[mindsocket]

Follow up thoughts...

This continues to come up. From the previous comment i now have a composite schemas for a space that combines knowledge and strategy schema elements through composition. This works ok and is suitable for certain constrained situations.

A use case that remains unresolved is multiple somewhat distinct spaces that want to refer to each other and should be able to without giving up their own identity. For that a multi-space config sounds appealing. This could involve:

• Flagging spaces that are known to be subspaces. This signals that validation should not treat broken links as an error as they could well exist in another space (unstated assumption: spaces can and should be a subset of what Obsidian considers a vault)
• Flagging superspaces as being allowed to have unrecognised types (ignore instead of error)
• space config allowing a multi-space - list of other space names instead of usual config
• conditional parsing and validation of multi-space configs. Parse each space separately. Validate unified set (removing exact duplicates from overlaps).
• unified schema (similar to partials) with multi space config allowing augmentation/replacement of schema hierarchy and relationship defs - eg wire delivery entities into strategy entities (unifying hierarchy), relate knowledge entity to strategy entity, add matrix strategy relationships

Alternatives:

• do nothing. declaring multiple overlapping spaces with combined schemas etc, instead of composing, is already possible. More config overhead and potential for drift in return for greater control. Assumes other content in common base path isn't in conflict.
• do little
  • make it easier to work with composite-schemas and/or standard spaces. Embrace multiple space definitions that overlap but are complementary for different purposes (eg all knowledge composite, domain-specific knowledge+strategy composite) - allow a) multiple paths in space config to cherry pick folders across a bigger vault, and/or b) path exclusions to cover "most but not all" of a bigger vault.
  • standardise some common composite schemas (strategy+ost, knowledge+ost, wardley+...) ... Or provide partials that do this for pairs of standard schemas (can glue together 2 or more schemas consistently this way!?)
• force spaces too be organised more closely together / embrace large spaces with mixed types and ignored nodes as being valid (potentially including allowing unrecognised types)

My takeaway from this, start with slightly more flexible space config (do little) with some thoughtful schema composition conventions (schema combo partials)