For planning material manipulation through time by laying out courses of action for individual-s work in a challengable manner as well as providing control over automated manipulator-s, to achieve certain material configuration-s provided by the user

---

one will be able to use the software to plan their own work and also programmatically merge efforts with other-s using the same system

---

in merger with other-s, one will retain the ability to direct any action planned for themselves as they see fit

---

focus is given to planning of material nescessary for an individual~s survival as opposed to material which is not nescessary to an individual~s survival

whilst production can often be generic-cised like in a factory environment, it is assumed as of writing that the complexity of the world requires an equal amount of complexity in a system which wishes to interface with it.
The complexity involved in interacting with survival production is different to the complexity involved in interacting with non survival production
Generic-ising an approach is assumed vital to achieving a interacting mechanism that is produced within a feasible timespace, however if the creation of this generic solution is to encode preference to a specific field, it should be towards production field-s which are the most important.

---

the software will be distributed gratis unless any of those critical to the software-s production require compensation for the work to obtain their own survival mean-s

If such a scenario does arise, it is important that effort-s are quickly made to restore the project into a configuration where it can again be distributed gratis

---

the code will be freely study-able so that user-s are not nescessitate-ed to draw a mental line between usage and development

---

departures are made from solution-s which assume one~s special-ise-ed position in a large market economy

focus is put into worldly mobility through decision-s of material manipulation and not through market competition
in a general sense, any power gained using the technology should be power over material and not other-s

as pressing economic circumstance-s appear, it is assumed to be in ones best interest to be able to self manage their economic circumstance as much as possible, as to avoid subjecting oneself to command out of economic nescessity

---

this is possile by withdrawing from technological economy but if one wishes to maintain the complexities of modern production, it is not feasible

---

this project aims to add to infrastructure in this field

---

for relation to existing project-s, it is somewhat like a commercial enterprise resource planning software

---

• Data store abstraction: `LongTermStoreInterface ( LTSI)`, supporting bulk data retrieval using filters and prescence manipulation. Current implementations are:
  • Mongo db, this project~s filters are translated into mongo db query mappings
  • Json documents stored on the filesystem
• Autogenerated editing gui for a given data type including container type-s such as ( list, dict, set, class structures) and types such as ( union, typed dict)
• Graphical data editor using the generated data gui, also store specific editing gui
• Data filtration mechanisms. There exists different implemented filter types. ( DataHasTag, DataAtPathOfType, Combination) are examples. The ability to alter data to be compliant or uncompliant with a filter exists, A data structure/ functionality element exists called FilterList. This can cache results, have incremental inputs and outputs. Structures which allow selective synchronization of filtration exist
• Versioning structure: given two data instances and a direction, a uni or bi directional transformation can be generated between them, these save space and the delta data structure can be used as an delayed alteration applicator
• Data which is stored in a long term data store is represented in ( short term, quick retrieval) memory using the `LongTermStorageData ( LTSD)` container, this contains functions to save data, obtain information about it~s storage. LTSD-s can be unversioned or versioned. Versioned LTSD-s have a delta version calculated between them upon save and they emit signal-s on various events
• Mechanism for providing one indexing description and having that description be used to index into containers across different formats
• Mounting data using `fuse` and an `ArbitraryHierarchyDefinition`, a directory tree is simulated using directories with a sequence of filters assigned to each, this can then be used to mount data from a LTSI on a filesystem in an expected manner and can more importantly mount codebases in this manner, combined with , this is then used for Ŧ. Existing filesystem based tooling can therefore interact with data store data.
• LTSI-s maintain knowledge of withdrawn data which is used to facilitate cross-process communication and forms part of the input of a function which can be defined to determine whether each requested LTSD save will sucseed
• The `DataForTypes` structure allows specifying arbitrary pieces of information about a specific data type.
• Data can be converted between types and between formats. Format conversions do not require a custom definition for each type and can use generic methods for conversion which can then be overriden
• Each machine has a store which is local to it, this machine store can store the interface to a seperate store which could be held in common between many different machines

• Ŧ= Application of function hooks on the save of source code which then updates instances of a modified data type with modifications nescessary for those instances to continue to interact with the software, conform them to the new protocol
• LTSI bulk editing operation using delta data application
• Documentation performed in a manner that allows viewing of the original notes but offers the main point of entry as a curated perspective like structure which can sometimes reference the in process notes
• To resolve qualms with modelling the material world as a collection of discrete things with discrete properties which are instances of discrete base types
• Ð= a modelling protocol to facilitate Ħ, it can model ( at least material systems) and can facilitate differing human perspectives on what constitutes structue.

  To allow for multiple different abstract concepts to be used to describe real and hypothetical systems, two apples are not in truth two apples, that is a mental construct applied to material. With a current lack of a replacement of thought, one must allow multiple arbitrary concepts to be applied to the same “thing” It is designed to allow for elaboration, for example: decay modelled in a general manner which can then be parsed to plan management such as maintenance of an item in an environment which slows decay; the simplistic model of decay can then be elaborated on to describe the systemic dynamics that constituted the previous generalisation, such as the decay now being described as the dynamics of micro organisms, this elaboration is then used to better plan micro organism defensive procedure. To avoid creating yet another general modelling language if it need not exist, this could manifest as a protocol which is followed using a general programming language.

• Ħ= ( Initially algorithmic) software aspect capable of analysing a model Ð and producing the results:
  • ability to produce a set of proposed material modifications that need to occur through time in order to:
    • maintain a described system e.g. maintenance of the mind and the body~s material interactor-s,
      maintenance of a described material dynamic such as rain water capture and filtration,
      maintenance of any real or currently hypothetical system,
      
    • fulfil a variaty of system configuration demands e.g: receive x quantity of an item at a given interval at this spatial location,
  • predictions of future system states
  • the design of the protocol of interaction between Ð and Ħ is the same development process
    this should be informed by “systems science”, including concepts such as regulatory subsystem design
• resolution of the question: how does one abstract these desired operations of the Ħ as to not require an overhaul when a new one arises, to produce a thing which produces a result interpretable in different ways, in order to produce this, ( complexity not coming without work ..) then all possible desired needs may need to be explored before production of a somewhat generic software aspect.
• an interactive environment in which one can propse different potential outcomes through time ( including any alterations to the current reality model), e.g. one picks a base as currently known material with some modifications, then one can scroll through time, deciding on different possible outcomes. As real time progresses, paths taken on this timeline become realized and can be scrolled back and observed.
  At any point in time this environment resolves to a world state model Ð
• A guided environment utilizing or part of Ħ which can produce plans for oneself, overview of automatic material manipulation, viewed from the perspective of one to overview all necessary tasks to perform
• robotics are not modelled in a separate manner as other material and as such are treated as a system requiring maintenance, only it is known to Ħ that they are manipulable in the interface that they provide
• automatic application of Ħ to alter a plan upon any change to reality model, such as unfulfilment of a described task, failure of automative equiptment
• reality recording mechanisms into reality model using Ð, ( temperature, time, moisture) measurers are examples
• Ħ allowing specification of optimisations to use in its calculations: how may any determinations which are output distinguish between different output possibilities, or express those variations in a traversable continuum
• figure out interaction between individuals, computers, compute power, system controllers

currently oriented around python programming system

the work that has already been completed is not there to compete and should a project exist which has done work in areas which this are in this project-s scope and wishes to merge, some software systems have difficultly merging, difficulty increased by software being heavily born from personal mental structurings but..

I am hesitant to advertise the project until aspects akin to Ð and Ħ take shape,
giving off the impression that the main purpose of the work lies in currently realized parts is significantly undesirable.
Collaboration with those who are interested prior to the aforementioned state is welcome
interaction-s with people of differing motivation-s
important that a relationship relevant to the desried interaction is formed between the new worker and the existing
important as will not pay,
additional motivation will be to be familiar with the software and can use it for ones own means
those of minor interest are still very much welcome but the project must be resistant to ( people with low stakes) significantly changing the course of the work if people are not invested enough to self famliliarize themselves with the project but still wish to aid then they must take commands from those who know the structure more.
should one be invested enough to self familiarize and then it is in this project~s management~s interest to share governance
whilst the current idea is assumed to be malleable to better fit the core aims, the project should not deviate from the core aims of:
individual self governance, bringing computerised planning into that space, maintaining a software environment that is editable by those using it
in short, if these aim-s do not fit your idea of what a project like this should be then you should not work on this project
if wish then use contact on right side

• maximise individual freedom within their own production and maximise effective desired collaboration
• be restrictive against it being used as a tool for management of the work of those other than the user
• not be viewed a replacement for careful thought and in-person communication
• aim not to regidify the software structure as much as possible to facilitate future developments
• aim not to let built structures influence the mental flexibility of those desigining
• keep an open mind to neural network techniques for complex procedure but not implement them without having the
• project development body know a great deal about
• contribute to the set of many existing examples, that technological endeavors do not inherently provide an exponential source of power accumulation
• view similar work as a potential point of effort merger and collaboration
• allow shared knowledge stores between users, facilitate the creation of common repositories of knowledge which are directly compatible with the software ( and/ or the ability to transform existing knowledge bases in known formats into a compatible format)