The Adaptive Market Pattern - A first pass at a framework - Part 1

          First in thread      Previous in thread      Next in thread

Winging it

I first came up with the ideas that have led to the adaptive market pattern when I was doing my doctoral research.

The problems that I needed to solve and these ideas as a response to them kept resurfacing, and I eventually put a name to my haphazardly patterned response.

A few years ago, I wrote up my current thinking about the adaptive market pattern with paper and pencil while sitting in one of my favorite coffee houses. I remember being pretty happy with what I'd written - it captured my intent.

I'm fairly certain that it is somewhere in my apartment. I haven't been able to find it. What I've been writing so far is consistent with what I remember writing years ago, so I don't think anything has been lost.

I'm sitting in my favorite coffee house, the Wilde Roast Cafe in Minneapolis, and about to start writing up the pattern rather than just leading up to it. I'm winging it - I haven't taken the time to think a lot of this through before, let alone write it up. Fun and a bit scary.

I've had several people ask me to write something about the adaptive market pattern - I've alluded to it for years and they seem to have some use for it in mind. Some of them are researchers who have extended and put some of my doctoral work to use. I hope you find this of interest. Please let me know where it should go next.

The Realm

I need a world in which to embed the market. I've used the term 'realm' for this in other work and will adopt it here. It carries a sense of place and extent.

While there could be multiple realms, I'll assume that there is a single realm and that it hosts all of the components and entitities that comprise the market, including participants, registries, and directories.

The Bank

If participants in the market are to be motivated by profit, as I believe they should be, some mechanism for keeping score is needed.

I'm not trying to model all aspects of an artificial economy, so I'm going to keep things simple for now and use a single bank as the accountant of record.

Directories

One of the questions that I raised yesterday was, "Does there need to be / should there be any central authority, repository, or adjudicatory institition?"

I don't think that there needs to be, and I don't think that there should be, any such central authority, repository, or institution (apart from the convenience of the bank) with one exception : I think it would be very useful to have a single central directory.

A directory is a collection of advertisements of services offered. As such, it should provide the means of accessing each party that has placed an ad in the directory.

An advertisement should contain the semantic classification of each service being offered in addition to sets of keywords and, possibly, descriptive text. It should contain a reference that provides access to the advertiser. It should contain enough information (explicitly or by reference) about capabilities, capacity, resources, certification, protocols, processes, standards, experience, and pricing framework to enable potential clients to decide whether the advertiser should be given serious consideration as a potential agent.

I think there will be a few flavors of directory.

One provides a simple mapping from service to service provider. It should be as complete as possible. The ads would be placed by the service providers, who would be expected to maintain the ads and ensure their accuracy. This is mostly likely to be a public and free directory. The central directory is the best, and probably the only, example of this variety.

Another variety of directory will add elements of reputation and other annotations to advertisements. The ads may not be placed by the service providers, although they'll probably contain information derived from the ads in a central directory. The directory publisher will determine what other value-added information to mix into each ad. These directories may be similar to X's List sites or to collections of annotated bookmarks - they provide some information not obtained from a service provider to help others decide whether to consider making use of that service provider's services. Clients of this type of directory should expect to pay for its services. These directories would probably be public.

A third flavor of directory is one that contains the results of an analysis process. It might be a blacklist, in which each service provider listed is to be avoided, or it might be a preferred-vendor list, in which each service provider on the list has been vetted or has shown through experience to enter into and to carry out contracted tasks in a professional and trustworthy fashion. These directories may be public or private and there may be a charge for use if public.

In order for a directory to be useful, it needs to be efficiently browsable. Directories of the second flavor will probably use browsability in addition to the quality of its value-added information to their competitive advantage.

The reputation of a directory will depend upon the accuracy of its information, the completeness of its coverage (if flavor 1 or 2), the ease of searching, the quality and specificity of search results, the quality and usefulness of value-added elements, the availability and responsiveness of the directory, and the competitiveness of its pricing framework.

This also touches on the public vs. private issue. I think that competition between service providers will tend to result in the evolution of more effective service providers, and that the development of private information can be used to a service provider's advantage. I also think there is a place for a large variety of public information (hence this blog) that can also lead to the advantage of many, for equal access to public information does not imply equal effectiveness in the use of that information.

Registries

A registry is a repository of record for protocols, standards, processes, contracts, statements, complaints, and judgements, as well as other documents that I haven't thought of yet.

A registry is maintained and provided access to by a service provider. Being privately held, there will probably be a charge for access to a registry.

A registry should be expected to retain and make available true copies of the documents with which it has been entrusted. I prefer that the identity of participants submitting a document to the registry be recorded as part of the registry record for that document, as well as the submission timestamp. If modified documents are added to the registry, it should use a versioning mechanism to associate the modified document with its earlier version.

The reputation a registry depends primarily upon the faithfulness with which it retains and makes available true copies of the documents in its trust, as well as the ease of searching, the quality and completeness of search results, the availabilty and responsiveness of the repository, and the competitiveness of its pricing framework.

There may be a role for a central repository for certain types of documents, but I haven't found this to be necessary - I think repositories owned and operated by service providers that can be held accountable for their proper operation would work just fine.

History

The history of a participant is recorded in the registries and is woven from the contracts, statements, complaints, judgements, and other documents on record. Being documents in a registry, all of these documents are attributable based upon submitter and submission timestamp. The reputations of the registries consulted in assembling a history is of paramount importance.

Reputation

In order to be useful in this digital realm, reputation will need to be formalized and carefully constructed.

Reputation is a more complex idea than credit score, though it will have some similarities with that concept.

Many elements from a variety of sources will be used to construct an estimate of a reputation.

I do not know what the components of reputation might be. Their relative importance depends upon the consumer of the information and the need it currently has of the information.

There is no central authority for reputation - multiple service providers may offer reputation elements or summaries, and the reputation of the service providers must be taken into consideration when using information obtained from them.

Many participants will weave their own estimates of the reputation of others by using some information derived from a variety of sources and weighting various components and elements as they see fit.

Registries will provide several elements of reputation. Claims of history can be validated against registry records (e.g. claims of experience on certain types of projects can be validated against registry copies of contracts). The outcomes of contracts will be recorded in the statements, complaints, and judgements that registries will associate with each contract.

Directories will serve as great collectors and summarizers of reputation elements. Some of them will offer new elements (e.g. unattributed comments, reviews). Some will express opinions by their inclusion or exclusion of service providers from their listings.

Elements that can contribute to reputation may be grouped into those that have some bearing on or relevance to the selection or contracting of agents and those that don't. I'm assuming for now that most if not all elements available within the realm will be deemed relevant to the operations of the market, but this won't always be the case.

I think that the nature of reputation, its analysis and structure, and its use within an automated digital community is a lovely collection of interesting issues. I hope to spend more time thinking about it and hope that others figure out how to make it work. It is a crucial component of the adaptive market pattern as I envision it.

Contracts and outcomes

A contract is a formal agreement, freely entered into by two or more parties, to perform certain tasks as specified in the contract subject to the conditions specified in the contract. While registration of a contract with a registry is not required, it certainly makes sense, since otherwise there is no reliable copy of the contract that may be referred to in adjudication.

I am not a lawyer or terribly informed about the law, so I won't attempt to explain very much about contracts at this time.

I will say, however, that the purpose of contracts in this realm is to state expectations with clarity, to state the consequences of events, and to identify the agency for adjudication and the conditions under which it will be utilized.

Furthermore, a contract in this realm must be something that can be constructed, reviewed, entered into, used to guide execution, used as a standard against which performance will be measured, and consulted as the authority on consequence by fully automated software.

This greatly constrains the structure and representation of contracts at this time.

Because contracts may be registered with a registry, I think it only appropriate that formal statements that reflect the outcome of a contract should also be able to be registered with the same registry by all parties to the contract.

One type of document I'll refer to as a 'statement' - it is a document in which one party to a contract expresses its view how how that contract was executed by the parties to the contract. It express satisfaction, dissatisfaction, explain a delay, explain why it was unable to fulfill its obligation under the contract - pretty much anything that a party wants to say. Keep in mind that this statement is only of use to the extent that it can be understood by other parties (all fully automated software entities).

If a party to a contract wishes to invoke adjudication, it will submit a complaint to the specified adjudication service provider, which will register it with the same registry that holds the contract under dispute. The judgement of the adjudicator will also be registered with the same registry. For now, the judgement of the adjudicator is final and binding.

Other expressions of opinion

Any participant in the market that wishes to make any kind of comment or statement may do so.

For example, a candidate agent may not like the way that a potential client treated it during pre-contract discussions or negotiations. Perhaps the erstwhile client misrepresented the seriousness of its intent to contract with an agent for the task under discussion, or was discovered not to have sufficient resources to fulfill a contract before it was agreed to. The only way that a service provider has for protesting the wasting of its time is to make a statement denouncing the unworthy client.

Anyone wishing to make a statement that doesn't fall within the mechanism described in the previous section needs to find a service provider that will host the statement and pay for the privilege of expressing one's self.

The host may allow anonymous statements, but those would most likely be utterly ignored. Part of a host's reputation would lie in its accurate attribution of statements to the authors of those statements.

Once again, any participant could make any statement, but if a statement is to have any effect, it must be intelligible to others, and those others are software entities.

All of this ties back to the nature of reputation and how we'll want to structure and represent it and the elements that will be allowed to contribute to it.

Task descriptions and requirements

Everything starts with the need that a participant has to accomplish something. It needs to formalize that 'something' as a task description and will have to have some means of representing that task description so that it can be clearly communicated to other participants.

Task descriptions will surely be domain specific, although it should be possible to make much of the description generic and commonly interpretable.

The representation of task description should be amenable to elaboration, annotation, and versioning - they may be passed back and forth between parties several times during discussions and negotiations.

As discussions move towards bidding and contract negotiations, additional task-related elements will be specified and should be packaged with the task description. Some examples: scheduling, pricing structure, subsequent use of the information in the task description by the agent, use of the information derived from the fulfillment of the contract by the agent. The elaborated task description along with these additional elements will be referred to as the task requirements.

Once again, several issues arise in the representation of the components of a task description and all additional components that may participate in a set of task requirements.

Tasks and subtasks

We like to think in terms of hierarchies, and hierarchies fit very nicely into the adaptive market pattern.

A task may often be split into two or more subtasks in a very natural way. This corresponds neatly with the idea of an agent taking responsibility for the performance of a task, breaking the task into several subtasks, and then hiring other agents to perform each subtask. This is the pattern that we see with general contractors and subcontractors, and it can work quite well.

The responsibility for deciding whether and how to break up a task into subtasks is up to the agent that has accepted responsibility for performing the task.

A client may wish to be informed of how an agent will accomplish a task and, indeed, may wish to micromanage the agent in the performance of that task. For a price, an agent may accomodate the wishes of this type of client. I will point out, however, that this violates a spirit of encapsulation that might benefit the market. I'd be interested in hearing pros and cons of this point of view.

How an agent performs its tasks effectively and efficiently comprise some of the private information that can give the agent a competitive advantage. In performing due diligence, a client may demand evidence of compliance to standards and of certification. Whether there is a benefit of a client gaining more information about the inner workings of an agent's operations is an open question.

One area where I think that a client may expect / demand additional information from an agent (subject to the contract) is in the event of failure. If an agent fails to perform satisfactorily, and that failure is the result of a failure by one or more subagents, it seems reasonable for a client to ask for the identity of these subagents and the agent's description of their role in the failure. While the agent is responsible for hiring these subagents to perform the subtasks and for failing to intervene and take corrective measures when problems became apparent, accurate identification of additional points of failure may help both the client and the agent understand the agent's role in the failure and may provide the client with useful information for future contemplated engagements. For example, if the agent used subagent Y and Y demonstrably failed to perform, the client may wish to add a constraint, "Don't use Y" to other contracts. There are many issues, of course, including fairness, avoiding the passing of the proverbial buck.

To be continued...

Coming up, I'd like to spend some time exploring some scenarios that I think will be common and begin to sketch out some common processes. I'll sharpen up definitions and formalize things over time. I'll also take some time to explore this developing pattern as it applies to effective tool selection and use in problem solving systems. I'll try to move forward on several fronts without getting too confusing.

          First in thread      Previous in thread      Next in thread

Copyright and Legal Notices

All Rights Reserved.