Add readme

README.md

@@ -0,0 +1,70 @@
+# WorkFlow: industrial process simulation and monitoring tool
+
+## Aim
+
+The aim of this work is to create a toolset to monitor and simulate industrial processes like production and processing plants, 
+resource management for project-based teams, budgeting in complex cases, etc. 
+
+The model could be used for:
+* project monitoring;
+* project optimisation;
+* project automation;
+
+## Not-aim
+
+Creating GUI is currently out of scope.
+
+Technical process simulation is done with Controls-kt.
+
+Project strategy management is currently out of scope.
+
+## Concepts
+
+The project is based on several main constructs:
+
+### Resource/object graph
+
+The current state of the system is described as a graph structure where each node is a separate entity. Each node has a type
+and unique ID. Some node types could also have **parameters**, that could not be changed after node creation.
+
+Node can have any number of **attributes** (they could be added, removed and replaced). Attributes define the current node state.
+
+Node can have external descriptor that stores meta-information about the node. Like access rights, visualization preferences, etc.
+
+### Attributes
+
+Attributes are strongly typed containers for values. An attribute key stores information about attribute name and attribute type.
+Also, it could store information about default values and serialization rules.
+
+Some attributes are **relations** that connect two nodes with specific directed connection. Currently, we use only one-to-one relations.
+
+**To be discussed:** attributes could have their own attributes either defined in themselves, or in schema. 
+
+### Work
+
+Work is a list of events that contains rules to modify object graph. Basically it has the following events:
+* add node;
+* remove node;
+* modify attribute (add/remove/replace);
+
+Work also could have events that do not modify resource graph but still should be monitored. Like change of external balance.
+
+Work events are consumed by a work graph with respect to attached **processes**. It is possible that the process rejects node change.
+It is also possible that the process adds new node changes based on the graph state.
+
+**To be discussed:** In case of event rejection, part of work could still be completed based on rules and event relations.
+The specific rules should be further discussed.
+
+### Process
+
+A "smart-contract" (no blockchain yet) that defines automatic changes to object graph based on **work** being done.
+
+### History
+
+The log of all changes in object graph. It could be used to construct "time machine" and reverse the state of the graph to any state in the past.
+The history events mirror **work** events.
+
+## Further discussion
+
+Time management is out of the scope for now, but it should be considered in the future. For example, there should be possibility to 
+add delay to the process and allow it to propagate in a virtual time. Timeline from *simulations-kt* could be used for that.

workflow-core/src/commonTest/kotlin/center/sciprog/workflow/WorkFunctionTest.kt

@@ -1,9 +1,6 @@
 package center.sciprog.workflow
 
-import center.sciprog.workflow.entities.Organization
-import center.sciprog.workflow.entities.Person
-import center.sciprog.workflow.entities.rubles
-import center.sciprog.workflow.events.transaction
+
 import kotlinx.coroutines.test.runTest
 import kotlinx.datetime.*
 import kotlin.test.Test