Global Unified Social Structure - Software Technical Specification
The primary objective of GUSS is to create an abstraction layer over top of the world's major infrastructure. This includes local and national governments, economic models, currency, and so on. These concepts and their implementations were okay for the time, but they no longer serve to propel mankind forward. They are holding us back.
If a GUSS project needs a building permit to achieve an objective, GUSS should process this in the background so the project creators don't have to busy themselves with this tedium. Any bureaucratic red tape should be handled by an automated GUSS process.
A project creator doesn't need money, they need skilled labor and resources. GUSS has no internal currency, and instead deals directly with resources. GUSS interacts with the "outside" world using currency, but only as a means to obtain resources for internal projects. Currency is abstracted away from the end user.
The goal here is to build a new platform from scratch, while appeasing the current powers that be.
The priority mechanism will be used in multiple places:
- Overall generalized / conceptual priorities, per individual, aggregated to be shown publicly
- Tangible material priorities
- Insulin, 3ml daily
- Gasoline, 10L per week
Priorities will be the first step in understanding the demand side of the economy.
Resources in GUSS are an arbitrary data structure that describe all attributes necessary or useful about a product as it pertains to its circulation from production to consumption.
Ideally, products of suffcient complexity would self-report their statistics to GUSS, allowing greater efficiency in resource accounting. For example, every time a car pulls into the garage, it uploads its mileage to GUSS. This gives GUSS an understanding of how much gasoline it will need, when it will need an oil change, and when its next service appointment should be.
We can follow this chain to project resource needs of oil, gasoline, and automotive technical labor requirements for not only this vehicle, not only all vehicles connected to GUSS, but all products that are connected to GUSS.
Production facilities should also be plugged into GUSS, outfitting them with sensors that will automatically report resource statistics, providing a full understanding of the resource economy.
Because many resources in the economy are "the same thing", it is logical to create a template for them. Furthermore, it is logical to allow templates to extend each other to create a final product. For example, following is 4 templates stacked together to create a complete description of a final product.
- Lawnmower (has a spinning blade that cuts grass)
- Riding Mower (has 4 wheels and a seat)
- Made by John Deer (painted green and yellow)
- Model 438-C (trim details, etc)
There is a difference between a conceptual 438-C lawnmower and one actually existing. A template is a single entry in the database, and each instance is its own unique row in the database. This is because each individual item has different attributes. For example, each has a unique location, usage history, maintenance history, etc.
Every good and service uses labor to combine and transform resources into products. If GUSS has enough detail, we can query statistics such as "How much electricity was consumed in the production of all 4-door passenger cars in the month of November, in the state of Arizona?"
With detailed resource accounting, we should have a very good idea of what effects our production is having on our home planet.
Each item template should have a detailed documentation consisting of approximations or expected:
- Resource items consumed
- Waste items produced
- Type and amount of labor
- Other details relevant to production not listed here
This topic needs some serious consideration. What follows is purely speculative hypothesis for how this should work. Or maybe, in practice, this isn't even an issue and doesn't need to be implemented at all.
Problem, taken to logical extreme: Literally everyone wants something there is only one of. What is the best and most appropriately fair way to solve this problem? What solution minimize social friction?
All resources available to the GUSS system that are not currently in use should be divided evenly and distributed to all individuals. This means virtually distributing fractions of a whole. Resources can then be virtually traded and distributed as the owner sees fit. Individuals could then "claim" or "order" resources that they own virtually. That is, to cash in their virtual ownership of an item for the real thing.
Honestly, this seems like it would be a massive effort to do right, and maybe not even necessary. This is a topic that is extremely important, however, and should treated very carefully. It is, after all, the very problem that all of capitalism was designed to solve. Perhaps the very nature of GUSS renders this such a minor problem that it doesn't need a solution.
Resource accounting items should have enough data to accurately predict future resource consumption trends. In addition to understanding the trends of resource requirements, GUSS should also be able to predict the environmental impact of the production of these resources.
With solid data describing our consumption patterns, we can plan for eventualities. For example, if we can confidently say that our net production will generate 30 million tons of waste plastics, we can begin to plan a way of appropriately handling this waste.
The more accurate the data collected by GUSS, the further we can see into the future, and the better we can understand how we need to change our behaviors and technologies to sustain our survival.
Projects are the GUSS replacement for companies.
A project has a well-defined objective to produce a good or service. A project can be considered a container that combines resources and labor, and produces waste and products. A project should not be tied to any one person. There can be multiple projects that produce the same good or service.
The production process should be fully and publicly documented. This means there are no trade secrets in GUSS. All product recipes and intellectual property belong to the public. The purpose of this is to allow a corrupt or obsolete project to become defunct while still retaining its recipe.
A task is a discreet, logic unit of work to be carried out by a person or a machine.
Each task has
A task list is a flow/logic diagram comprised of individual tasks executed either in series or parallel, or any combination of the two.
If a task cannot be executed for any reason, the project execution status becomes "blocked", allowing the troubleshooting process to begin.
Labor in a project is requested and never required. The task to be completed, including its time commitment, are laid out in full. An individual chooses to participate only if they want to, and their commitment to the project ends when the objective is complete.
This forces a project to serve its purpose or die. When labor cannot be coerced into working, a project must provide value to its society, or no tasks will be completed. This allows, in effect, for the system to self-police. Projects that become corrupt or are deemed harmful will not be supported.
Human Skill Tree
Each project task that requires human labor must define a skill type and required proficiency.
Individuals participating in GUSS will maintain a skill tree that is used to match an individual with tasks they are capable of completing.
Skill trees are manicured largely outside of the control of the individual they describe. A person may claim they are capable of replacing the brake calipers on a 2007 Honda Accord, but if GUSS took them at their word, it is likely that we put lives in danger.
As such, task completion is a two-way street. Individuals review and grade the project and the task. Was a certain individual easy to work with? Did the task have sufficient documentation? Were all resources prepped and ready? And on the other side, did was the individual capable of completing the task in a satisfactory manner, and in the expected amount of time?
This feedback improves the ability for GUSS to match labor to tasks, creating increased efficiency within the system.
An alternative use of a GUSS project, an individual program is a series of tasks executed by an individual for the express purpose of achieving a goal. As with a standard GUSS project, each task has a discreet amount of resources required for completion, and the program task summation can estimate the total amount of resources required for execution. Furthermore, an individual that participates in multiple programs simultaneously can take advantage of advanced scheduling features. If a person wants to "do all the things", the GUSS scheduler can merge multiple programs into a single schedule.
The program can be executed one or more times, at a given interval, or sporadically.
Groups of individuals may start the program in unison, executing each step/task of the program simultaneously.
It would make logical sense, then, for each task to have a type of comment thread allowing individuals experiencing the same program to be able to communicate at each step.
As an example, a common program might be a weight loss program.
Resource and Labor Scheduling
With the ability to contribute to projects at the individual task level, and knowing approximately how long a task takes to complete, we can schedule labor and task completion very precisely. The net effect of this is being able to accurately predict the rate of production for all resources.
The objective of the scheduler is to organize resources, labor, and time. With enough data, GUSS can determine the availability of resources and labor at a given point in time. By understanding resource and time constraints, GUSS can create schedules and coordinate vast program executions, allowing the lives of individuals participating in GUSS to operate smoothly and effortlessly.
Trust is a fundamental concept of human society. It basically equates to asking "If given the chance, will this person break something?"
A trust score is essentially a network of individuals "vouching" for one another. Trust is also accumulated by scheduling tasks and completing them on time.
The trust score of an individual is used in labor suitability decisions where tasks of a sensitive nature are involved. For example, if I have a plumber coming into my home to fix a toilet, I want them to be trustworthy. Similarly, when hiring labor for a nuclear power plant, we want to be as sure as we can be that the person isn't going to take refined waste home and build a nuclear weapon.
It is imperative that individuals be able to reset their account back to zero. The trade off is that "new" accounts are treated suspiciously, and don't have the trust and access of someone that has participated for a long time.
Individuals, in order to feel safe in their society, must know they will be forgiven, that they will always have a home. It is this level of social security that is required to have a truly cohesive system.