Extending Ledgrr to model "Model-Feed-Engine" value chains

[djwork]

Extending Ledgrr to model "Model-Feed-Engine" value chains

Graph Data Model
Primative Types

• Engine
  • A process/algorithm/workflow that takes in both “Model” & “Feed” and produces “Product”
  • Long lived, evolves over time
  • Wardley Association = Activity
  • Subclass
    • Software Engine
    • Human Agent
• Model
  • A model of a thing
  • Long lived, evolves over time
  • Usually has a team dedicated to ongoing alignment with the changing state of the entity being modelled
  • Model Versioning is not rigorously applied, or not up to the standard of modern software versioning
  • The structure/content of the model more reflects the needs of the “Engine” than the reality of the entities being modelled (ie power system being modelled as linear equations for use by a linear solver)
  • Wardley Association = Data
• Feed
  • A stream of data
  • Only relevant for a specific slice of time
  • Normally requires a continuous information network connection to another system or an outside entity
  • Streams frequently required a chain of internal and external networks/systems, if any element of the chain breaks the steam is out of service
  • Stream values only make sense in context of the associated Model
  • Wardley Association = Data
  • Subclass
    • Feed Embedded Model
• Product
  • The output ready for delivery
  • Information Based, not a physical thing
  • The Product's Payload is an instance of type "Feed" or "Model"
• Supplier
  • Entity external to the Organization
  • Supplies the Organization with 1 to many "Feed" or "Model" -
• Consumer
  • Entity external to the Organization
  • Receives 1 to many "Product" from the "Organization"

Compsite Types

• Organization
  • Singleton
  • Owner of all "Value Chain"
• Team
  • Workunit of 1 or more Human
  • Belongs to another "Team" or "Organization"
• Component
  • Input 1 to many "Feed"
  • Input 1 to many "Model" or "Feed Embedded Model"
  • Each Input should come from an Output of another Component or from a Supplier
  • A single "Engine"
  • Output 1 to many "Product"
  • Each Output should go to another Component Input or to a Consumer

[elasticdotventures]

Agent: search existing codebase ledgrrr may already have many if not all of these types by different names ex: flux capacitor.

These are high level diagramming & simulation node constructs that represent named repetitive black box containers of abstract logic which have their own modelling & layout rules. The current system being used for modelling these is vision but it would be better to have a DSL such as rhai or equivalent for version controlled modelling and visualization via ledgrrr; ultimately we are building a next generation mbse style tool that includes many different visualization layers (not just physical, logical, and functional)

consider how to use comptime parameticy
https://noelwelsh.com/posts/comptime-is-bonkers/

[elasticdotventures]

the conceptual modelling is in the domain of visualization of https://en.wikipedia.org/wiki/Information_architecture

[elasticdotventures]

Answering the "Agent: search existing codebase" ask directly — searched, not deciding whether to adopt this proposal.

Short answer: no direct match, but there's a ready-made pattern to build on

Nothing in the codebase already models Engine/Model/Feed/Product/Supplier/Consumer/Organization/Team/Component by another name. The closest things are structurally adjacent but semantically different:

crates/arc-kit-au/src/node.rs — the typed domain-node pattern this repo already uses for a different vertical (bookkeeping/requirements evidence): a NodeType enum (SourceDoc, Transaction, Classification, Requirement, Decision, Cost, ...) backing individual structs, each #[derive(SysmlBlock)] (the same macro from tonight's #195/#204 work — real, grammar-validated SysML v2 output) plus Blake3 content-hash identity (content_hash()). This is the concrete template this repo already has for "add a new typed node kind with SysML export and stable identity" — if Engine/Model/Feed/Product etc. were added as real types, this is the existing pattern to follow, not a new one to invent.

crates/holon-viz/src/holon.rs — a generic Holon/HolonKind container abstraction (id, label, kind, parent_id, children: Vec<String>, free-form metadata) explicitly described as "simultaneously a part and a whole (holarchy)". This is the closest existing structural analog to your composite types' containment relationships (Organization owns Team owns Component, Component has an Engine) — but it's currently a visualization-layer abstraction (feeds the Cytoscape graph I got working end-to-end tonight, see #206) with untyped metadata, not a typed domain model. HolonKind today only has 5 variants (SysmlBlock, OwlClass, CapsuleGroup, ProcessNode, AuditEvent) — none map to Engine/Model/Feed/Product.

What this means concretely

If this proposal moves forward, the honest framing is: two existing systems, neither is "Engine by another name." arc-kit-au has the typed-node-with-SysML-export machinery but the wrong domain vocabulary (finance/requirements, not value-chain/Wardley). holon-viz has the right shape of containment/holarchy relationship but no typed domain vocabulary at all, just an untyped kind enum + metadata bag. Adding Model-Feed-Engine types would mean either extending arc-kit-au's NodeType with a new vocabulary (reusing the SysML-export machinery, but stretching a bookkeeping-evidence crate into an unrelated domain), or giving holon-viz's HolonKind real typed variants (more natural fit for the containment/visualization framing in your proposal, but currently has no evidence/audit-trail machinery arc-kit-au has).

Not making that call — flagging it as the concrete fork in the road once/if this gets prioritized, per your own request to check first.

🤖 Drafted during an overnight session with Claude Code, per an explicit "search existing codebase" request in this issue's own thread.