breakdown Knowledge and Planning modules into sub files, plus ProductBatch & Process into their own
new modules (and where it was removed from)
- Fulfillment (Planning)
- Intent (Planning)
- Commitment (Planning)
- Satisfaction (Planning)
- Process (Observation)
- ProductBatch (Observation)
- Action (Knowledge)
- ProcessSpecification (Knowledge)
- ResourceSpecification (Knowledge)
- in most cases, by default, decompose into a single file per class
- exceptions: in cases of 'second class classes' (e.g. nested or uncouple-able classes, such as ProductBatch) leave in the same file as the first class it relates to
- keep recipe because it has the 4 RecipeX classes
- keep scenario which has Scenario and ScenarioDefinition
- keep Observation having EconomicEvent EconomicResource
- create a separate file process for Process class (ripping out from observation), and relatedly create bridging files for that.
- keep measurement as is. it groups some types, but not in a way that makes sense to decompose
- decompose knowledge into action, resource_specification and process_specification per the recommendation to decompose by default, and the fact these have no intrinsic relationship. For "usefulness" purposes they can be recombined at a higher level of the technical stack. Create the necessary bridging files
- decompose planning into commitment, intent and satisfaction and create the necessary bridging types, which would include Fulfillment which is a bridge type between commitment and observation module