Quality and accountability, in my experience have much in common. When done right people love them; when done wrong people hate them.

On Quality:

Quality grows our of work people take personally. People take their work personally when a payment system credits their account for their action. The credit can be monetary, or applause, but that credit has to appear.

On Accountability:

Accountability is embraced when the system of assignment is positive and fair. People reject accountability when biased, inferior reporting is held against the accountable person. Few things in life are more disheartening than actions taken out of context and then held against the actor.

What quality and accoutability have in common is a need for a positive focus relative to the individual and integrity relative to the common application of the system. Note the binary nature of individual and common.

Bookkeeping follows a definite pattern relative to its own quality and accountability.

I believe the bookkeeping pattern would work in your system too (perhaps it already does and I don't know it). Bookkeeping is about artifacts and their ownership. Artifact and ownership have a binary relation. A binary relation means that when the artifact changes ownership changes. In an unbiased accounting if I improve your artifact, the system will credit me with a share of that artifact's ownership. If you pay me for my contribution to your artifact, the system gives the credit for ownership back to you.

In an information system, artifact is the message and ownership is the speaker. In the bookkeeping pattern this would not be enough to create a positive accounting. One must also track the context in which the words are spoken. In bookkeeping this would be in analogy to which contract--read artifact--work has been applied. The more detailed and fair the accounting the better it will be accepted and used.

Rod Welch wrote...

Let me do a quick run through of the bookkeeping universal pattern and perhaps you can better tell whether this pattern can be helpful in your architecture.

Bookkeeping's final goal is to generate accurate reports relative to artifact and ownership.

It simply reports the expenses incured producing an artifact, or artifacts, in relation to the revenue those same artifacts generate in the marketplace. When revenue exceeds expense, artifact[s] are profitable.

It simply reports the state of ownership at a specific point in time. If ownership is a company, the Balance Sheet tells who owns that company and how the equity in that company is distributed. For example accounts receivable or payable, inventory, work in process, cash, buildings, stock, and etc.

As simple as the Profit Statement and Balance Sheet might seem, when there are both many users and contracts that have numerous artifacts, producing a fair and accurate accounting is no trivial task. So bookkeeping sticks to a very simple pattern I call The...

In the company, or contract, the artifact is *subject matter* and ownership is an *object image*. Subject matter is tracked in a system of *debits* while the object image is tracked in a simultaneous system of *credit*.

Subject matter is *resources* coming into the artifact and *production* going out of the artifact. So, again, we have The Binary Unit of Artifact made up of Resource/Production.

Obect image is *history* composed of ownership assignments and *policy* by which those assignments are made. So again we have The Binary Unit of Ownership made up of History/Policy. Policy rules get a lot more attention today because the computer allows for policy to be much more specific than it ever was in the past.

And so we get a diagram that looks like this:

Instead of applying this binary pattern to commerce let's apply it to communication.

The "subject artifact" is what was said in the message. "Resources" are the words, "Production" is the context; the contract of which the words are a part. The product may be a combination of one or more resource messages.

The "object ownership" is who said what. "History" is an image composition -- database with linked interface -- able to report a system of context within context (this is just what a balance sheet in a network architecture must do in reporting the balances of just an artifact, just a contract, or just a particular company). "Policy" is the rules by which ownership data can be accessed.

Rod Welch wrote...

Dave's complaint is valid.

But by using the binary unit pattern above, Dave could access only the messages in that part of the composition of links associated with a particular contract context. And he could only do so if policy so allowed.

When this level of accountability and control is in place, your communication product would be extremely valuable in a number of context I can think of, most particularly software developement.

But notice too how naturally the pattern applies to the law, where contracts are cases.

Sincerely,

Dan

Dan Palanza
dan@capecod.net

Copy to:

1. jcservo
   jcservo@dawnbreaker.com

2. Nerlove, Sara B"
   snerlove@nsf.gov