Some organizations have developed what they call operating value streams. Sometimes these arise from application of "Lean" methdology. But, they may also arise from a desire to model the creation of value associated with particular product lines and analyze those representations of value with respect to the generic models of value creation provided by value streams.
Specialization of value streams and stages is disallowed by the BIZBOK (to avoid the common methodological mistake of conflating value streams and processes). Is there a need for operating value streams? Is there a way to represent this that does not violate the BIZBOK?

The ability to associate products with customers is important. In the current metamodel, this connection can only be made by joining a customer targeted by a value proposition with a product offering where the value proposition is of the product offering. Should the metamodel include a direct relationship between product offering and customer? Should this relationship be a shortcut?

The BIZBOK introduces the notion that value streams include the concept of a binding business object(s) whose state, together with entry and exit criteria controls the sequencing of value stream stages. How should BACM represent this concept? Is it explicit in the metamodel, or is it the result of analysis or some combination of these?

The current draft provides OutcomeRelation as a template for the model level definition of relations between outcomes. Recent work on entry and exit criteria for value streams as well as capability and process flows has informally used logical relationships that instance/specialie OutcomeRelation and effectively define an Outcome that is the logical union or other Outcomes. The issue is whether the metamodel should define a set of specifically logical relations. For example include, exclude, include complement could be used to create an Outcome by conjunctive composition where the semantics of the Outcome is the union of all facts from included Outcomes, no facts from excluded Outcomes (i.e.not known whether these are true or false), complement facts from included complement Outcomes. This is just an example; specific proposal to be worked out.

The justification for namespaces is to permit parts of the model to be used independently. The current packaging is close, but crossmaps between value stream and capability are defined in Capability and crossmaps between ValueItem and Outcome are defined in Customer. Customer mixes together Journeys and Value Streams. Consider repackaging to eliminate crossmaps from the core packages and add new packages with just the crossmaps. This would also benefit use of the OWL as a group of ontologies instead of one large one.

JSON is an increasingly popular serialization format. JSON-LD provides some key additional capabilities.