Show Me the Money

After months of study I conclude that I am in total agreement with the AMI and the American Monetary Act as statement of the problem and proposal of the best solution.

Modeling systems at the high level is simple. Listen to the best description of the problem and the proposed solutions made by the best subject matter experts. Parse them into a high level model. Use the models to kill or marginalize the wacko, die hard, bogus thinking, consolidate support for the best and get authority. Then go implement, usually by computer programming the system sometimes re-programming the organization. Do good and get promoted. Continue and get placed in charge of bigger things.

The next important step in presenting and promoting the American Monetary Act is describe it in model form. A model drawn by an information engineer. Nobody argues with an expert engineer. They design form. Then expert workers build. The product is form doing its inherent function.

In the information age design and implementation is done with Object Oriented (OO) thinking. The design phase employs Unified Modeling Language (UML) and the implementation phase employs Object Oriented Programming (OOP). Too bad I can't link here but they are all in Wikipedia. I am sure you worked with those kinds of people.

Information System Engineers take a description of the Problem Domain (PD) made by Subject Matter Experts. They parse it using the Object Oriented Methodology embodied in the UML tool which is really just identifying nouns and verbs, with focus on the nouns, structured in a pyramid of things (Classes) and thing relationships but looking at them as things that know how to do an inherent action (verb) called a method when called upon to do it (messages) sent by another thing. Things inherit the method abilities of their Parent Class thing.

The relationship model of all the big things is called the big picture. In the case of the Unified Model (UM) description, the big picture, when extended in detailed pictures automatically (almost, it is an iterative development human/system process) translates to programming the system to operate.

It is simple. That is how the complex information structures of today are designed and implemented. Different models have different names. Some as fundamental at the simplest presentation level to structured diagrams that are the product of high powered branded "concept processor" UML application programs. Regardless of brand names it is all the same soap, with variations in complexity representation, name branding of a generic thing to a different look and feel and the nature of the target market.

Aristotle was an information engineer. He used the best tool then: Natural Language. Still our best and you have used it so well. Now we have tools to refine what is said into form and implement that form in function, the best of which are Open Source Systems. Public Domain.

I suggest the next step is to model the American Monetary Act at the top level using a UML approach. Challenge other systems to model theirs in the same way. The Act is then framed in formal third party form by which other monetary systems as well can be compared. Otherwise everyone spar swith words as rocks and focus on the throwing. Spar with high level conceptual representation comparisons produced with a common methodology language: UML. That means: Show me your Money Model. (Show Me the Money!)

Money is a big thing. Maybe the problem is that what money is has been so confused with what money does. What money does is economics, a social science. What a thing does is to a great extent a function of what it is, or was designed to be, what it "knows" how to do. If we focus on what a thing is to do, logic and reason determines the nature of the best "thing" to do it with. Otherwise the whole world is a nail if all you have is a hammer.

Money is a conceptual thing with primary relationships. Fundamentally simple just like "one person one vote" is the medium of freedom? Complex perhaps in implementation but when confusing we always go back to the foundation. Money system design and operation is an information domain problem. The tools are OOD and OOP. The thinking is Object Oriented (OO).

The rock solid foundation of all systems is generally the "one to one" basic unit relationship. The uniquely identifiable relationship of two Instances of the Class. Find and describe that relationship key and the whole system of "one to many" and "many to many" falls into place.

There is a very fundamental relationship between one unique person (Economic Agent Unit Identifier Code) and one unique unit of money (serialized, denominated greenback) existing as a computer record. Their relationship is ownership. Greenbacks can be denominated in any amount determined by design. Once created, greenbacks exist forever as fixed uniquely identified unit entities. Macro quantities of unique units change as required. Ownership of money changes as a function of attaching the association with new owning agent in place of an existing owner. All money is always owned by some identified agent.

The next big step might appear to be the introduction of American Monetary Act legislation. The next big step is really presenting a clear concise object oriented picture of the proposal.

Maybe the essence of money has something to do with it existing like a ball on a level playing field. One on which the score keeper and the refs have no interest in the score, other than to provide the ball and keep it constant in terms of fixed size and shape, post the score and assure that the players abide by the rules. Rules must be simple to support play and not hinder it. The players decide by mutual consent who the refs and score keepers are, how they are controlled and paid?

The game of money has to be sold to those that play it, they own it. Make it simple, keep it simple.

Super Bowl. Interesting analogy. Who owns that game and the facilities?

That is another information engineering domain!

In all my research I have never found a UML high level model of money. All I find are low level examples like individual bank accounts and their transactions. I am sure the Fed or big banks have high level models of what money is in their system of debt money. That, of course, is not and never will be public information. That model is really their biggest and most precious asset. One they could never show to the public. They must hide it behind the curtain.

It is so amusing that when the American Monetary Act is presented as a UML model, we can say to the banksters: Show me your money model using standard industry UML methods. They can't show what they must protect as their sacred cash cow!

Drawing their debt money model for them in UML would be just as easy drawing the American Monetary Act system and might be a good strategy since banksters would be reluctant to present their UML model or, most likely, would present a function model which is inherently a more confusing way to represent information. Obviously, confusion serves them, not clarity.

They will no longer be laughing on their way to the bank.