Merge pull request #101 from Phuire-Research/UI

Graph Computation Note

ActionStrategy.md

@@ -7,7 +7,7 @@ The staked effect of this data structure is one that is capable of mapping the i
 As the original pursuit of this data structure was to utilize the data parameter to formalize a transformation of said data over a period of steps. To map the exact transformation of data through an application, versus a series of factories. This chain like pattern of design is represented as a separate concept within this framework. As the framework is designed to be wholly responsible for itself. As the main issue would be the change of data that the chained behavior may be dependent upon. To allow for that data to transformation across any number of nodes on a graph, we introduced the spatial ownership design pattern. Where the final destination for such could be the original axium, the client's screen, or even the database of some server. This is a formalization of a greater than the sums approach to programming by way of composition, decomposition, and recomposition of sets of concepts, contained within some axium that interacts with other axiums.
 
 ### How STRX allows ActionStrategies to be a Data Oriented Format for Graph Computation.
-Since STRX uses semaphores over strings types to formalize its own inner workings. The main functionality of strings throughout this system are for readability and being able to isolate some additional functionality at run time. Due to this approach, the net run time of a "Axium" is just a series of entities(actions/state/concept), arrays (staged plans), trees(action strategy), and graphs(staged plans + punted/sequence strategies). That can be made numerically pure with a compilation process to set the semaphores ahead of time. Therefore this system is functionally just a graph programming framework that uses strings for user comprehension, and such can be stripped.
+Since STRX uses semaphores over strings types to formalize its own inner workings. The main functionality of strings throughout this system are for readability and being able to isolate some additional functionality at run time. Due to this approach, the net run time of a "Axium" is just a series of entities(action/state/concept), arrays (staged plan), trees(action strategy), and graphs(staged plans + punted/sequence strategies). That can be made numerically pure with a compilation process to set the semaphores ahead of time. Therefore this system is functionally just a graph programming framework that uses strings for user comprehension, and such can be stripped.
 
 The only blocker in the scope of this current implementation, is that we find faulty actions, plans, and the concluding strategies via a type comparison. This can be further extrapolated away, but would save that work for a low level programming language. As the choice of Typescript in this project was due to familiarity and as the fastest path towards creating a MVP. This is mainly as a note for later as graph computation hits parity.