What's the intended pattern for a node whose full definition must be authoritative across many architecture documents?

[MattFriedman]

When the same node appears in multiple architecture documents, what does CALM intend for reuse of its definition? I've worked through the existing mechanisms and none seem aimed at this, so I want to confirm whether there's a pattern I've missed or whether this is out of scope by design.

Three things people mean by "shared node"

These get conflated, so to be precise:

• Decomposition — a node represents a system, and you want to expand what's inside it. detailed-architecture covers this. Not what I'm asking about.
• Boundary reference — the same external system appears at the edge of many architectures, each just needing to say "I connect to it." Re-declaring a thin node (unique-id, node-type, name) in each file seems acceptable here — it's an identifier, not a body.
• Canonical definition — the full node body is authored once and is authoritative everywhere it appears. This is the one I'm asking about.

What I've checked and why it doesn't fit case 3

• detailed-architecture is a drill-down link. The target is meant to contain the node's internal decomposition, not to be the node's definition. Using it to hold one node's canonical body inverts its purpose.
• Patterns enforce shape via validation, not a stored definition that gets reused. Each architecture still carries its own copy of the node.
• Standards constrain structure across files but don't provide the instance.
• CALM Hub addresses architectures, patterns, controls, decorators, flows — not individual nodes. So there's no node-level canonical resource to reference, even operationally.
• The CLI's --url-to-local-file-mapping and --calm-hub-url resolve references at build time, but only for references the spec already permits (whole architectures, patterns, etc.).

Concrete example

Say an org requires governance metadata on every node — things like change status, provenance, deployment tier, region — plus interfaces and controls, all carried in the node body. For a genuinely shared service, that full body currently has to be re-authored in every architecture document it appears in. When it changes, every copy has to change. A standard keeps the shape consistent across files, but the content is still duplicated by hand.

What I'm trying to decide

Whether the intended answer is:

(a) there's a pattern for case 3 I haven't found, or
(b) re-declaration is expected, and instance-level reuse is deliberately out of scope — e.g. because a self-contained document diffs and reviews cleanly, and transclusion would hide cross-document impact from a reviewer.

Either answer is useful. If it's (b), I'd like that rationale stated so we can design around it rather than fight it. If it's (a), point me at it.