Its ground state is where no interaction has yet taken place between the two parties of a yet-future transaction. There is no tension. It is relaxed.
A transaction is an action which takes place between two parties. It is triggered by a unilateral approach by one to the other. It then follows a formal protocol of action and response. This progresses until all requirements of the protocol have been fulfilled. A transaction is therefore like a living thing. It has a birth, a life, and eventually dies. An account is a collection of biographies of transactions. However, the analogue in nature which I originally used as my conceptual model for a transaction is the atom. More specifically, I likened the sequence of events which make up a transaction's life to the discrete changes in energy in an atom when it becomes ionised through an external impact and then drops back to its ground state again. This analogy is loose but useful.
This analogy is given body through the little finite-state logical machine shown below. It represents the supplier's side of a transaction. One representing the customer's side would be identical, but things would happen in a slightly different order.
Its ground state is where no interaction has yet taken place between the two parties of a yet-future transaction. There is no tension. It is relaxed.
Suddenly, like a high-speed electron hitting an atom, a customer enquiry is received like a bolt out of the blue. As the electron would knock the atom into a higher energy state, so the customer enquiry knocks our machine into a higher state.
For want of a name, I have called this the tendering state. This is an active state for the supplier. He must now respond to the customer enquiry by preparing and sending a tender or quotation to define in a formal way the business which is to take place between them. The tendering state is terminated by the issue of a tender or quotation document to the potential customer, and then transmuting to the awaiting order state. This is analogous to the atom in its high energy state emitting a photon, and as a result falling to a state of lower energy. The machine is now in what is known as a wait state. The supplier must now wait for his customer to respond.
Every energy state of an atom (other than its ground state), has a built-in time-out. Left to itself, an atom will, after a prescribed delay, revert to its ground level state. Likewise, every wait state possible within a finite-state transaction machine (again, apart from its ground state) also has a built-in time-out mechanism. If the customer does not respond to the supplier's tender within a certain time, the supplier's machine automatically drops back to its ground state and the transaction dies. Interestingly, the atom is far from the only natural mechanism to embody this time-out principle. A cell in the body self-destructs if it does not receive a prescribed chemical signal from its environment within a pre-determined time limit. This principle is also built into artificial systems of law in the form of a device called a statute of limitation.
Hopefully, an order will arrive before the time runs out. In this case, the arrival of the order knocks the machine into a even higher state. This is called the production state. It is another active state. The supplier now actively fulfils the customer's order. This includes producing and delivering what was ordered. The upshot is the emission of an invoice in the direction of the customer, so to speak. This is co-incident with a 'fall' to yet another wait state - the anxious state of awaiting payment.
The awaiting payment state also has an in-built time-out mechanism. If payment is received before the first time-out expires, the machine simply falls all the way back to its ground state and the transaction has reached the end of its life. On the other hand, the expiry of this first time-out triggers the emission of a legal summons in the direction of the customer and the machine transmutes to an awaiting due process of law state. When the process of law has run its course, the finding - whatever it may be - triggers a final return to the machine's ground state. The transaction's life is brought to a close.
The notion of the energy level of each of the various states of the transaction machine are perhaps better illustrated in the following diagram. However this does not neatly segregate the incoming from the outgoing message types as does the first diagram.
The states illustrated above are, in most cases, each made up of sub-states. Perhaps the most obvious is the awaiting due process of law state (which hopefully we do not have to go through very often). This state is made up of three sub-states: awaiting response to summons, awaiting judgement, awaiting enforcement. The effect of the first one timing-out (ie payment has not arrived in the meantime) is the 'emission' of an application for judgement. Of course there is more to it than this, but it does illustrate the principle of a composite state. The internal complexity of the other states depends heavily on the nature of the business to which the machine is applied.
My finite-state transaction machine is implemented as a software object class [Java-speak]. Inputs from the outside world, namely the receipt of an enquiry, order, payment etc. are manifested internally as incoming messages. All constructors and methods in the class are implemented as message processors. They each take a single reference to a message object. They each return a reference to an object called an output message. Output messages are converted into real documents - tenders, quotations, invoices, etc. and passed to the outside world.
A message comprises an action and an object on which to act. The action is held as a reference to a method. An incoming customer enquiry message triggers a call to the constructor which creates a new machine object. This object is the framework of the machine. The class's methods are its functionality or mechanism. The object contains all the fields necessary to describe the life of the transaction machine. It is placed as a line entry of a database table. Almost all its fields are indexed to allow methods from presentation classes to present account status and statistics in whatever form the user may desired. At the end of its life-cycle, the dead transaction machine object is 'mummified' to preserve it for later reference for as long as is expedient or legally required. The statutory documents (in effect, the inter-party messages) are of course preserved according to normal practice. [Relax: end of Java-speak. Ed]
This is all very formal and self-sufficient, but what kicks off the whole process? Is the market radio-active? Does it spontaneously emit strange particles called sales enquiries which somehow rain down on your in-tray? "Not in my experience," says Rob, "You have to become as a flower to a bee. More than this, in what is for the most part always a buyer's market, it is the flower which must go to the bee."
The task of stimulating the market to emit sales orders in your direction is one which can be readily separated from other business functions. It works rather like the pumping lamps used in the old gas lasers to stimulate co-ordinated photon emission. But this is another subject.
See also my special-application operating system called Robos which is based on message-driven finite-state machines and goes into their principles in greater depth.