The basic principle of RegenCHOICE, for finding other people, is that instead of one person looking though a catalogue of other people, only to find that most of the people they are interested in are not interested in them, the interest is checked both ways round at the same time, so that you only get to see other people when you are interested in them and they in you.

But of course it would be an amazing coincidence if two potentially well-suited people happened to be seeking at exactly the same time. RegenCHOICE, like other systems, looks after both sides. The person who is currently actively seeking on the system can try asking for different things from the other person, who is currently standing and waiting to be found. But it's not only the other person's answers that need to be stored somewhere, but also their own enquiries must be as well, so that when the person is not online, both sides of them can be found: what they want and what they are.

What will typically happen is that one person will start off an enquiry and see if anyone else has a corresponding standing enquiry — where A's wants are met by what B says about themself, and B's wants are met by what A says about themself. If there is a fit, all well and good; but if there isn't straight away, A's enquiry stays standing on the system while A is otherwise occupied, and B may be actively searching.

If, then, some information about an enquiry needs to be stored when people are offline, it's easy enough to extend that to any number of enquiries. A person may be looking for several different kinds of thing at the same time. They may even be looking for different kinds of people — for instance if they are trying to form a team, or fill a number of gaps in shared living accommodation or a business.

I hope it helps to give an outline of the essential ontology of RegenCHOICE.

First, there are three potential “things” that exist in the “real world”, independently of this whole system and approach:

1. the party who is actively seeking someone or something — I'll call this party “the enquirer”
2. the party who is in some sense waiting to be found — “the respondent”
3. in many cases, but not necessarily all, the nature of the relationship or opportunity.

I call them “things” as they are not all the same kind of thing. The two parties can be, on the one hand, individual people; or on the other hand, some collective of people such as a company, an organisation, a community or any group. The enquirer and the respondent are likely to swap roles during the course of seeking a good fit. The two parties have the nature of entities, while the third has the nature of a relationship. I do not privilege one kind over the other.

If we compare this with old-fashioned newspaper “small ads”, perhaps surprisingly, the advertiser is the respondent and the person reading the newspaper is the enquirer. For common recruitment, the employer is the respondent, putting out a job opportunity, and the jobseeker is the enquirer. In head-hunting, the roles are reversed, except that the employee is often not even looking for a new position, but is asked if they are interested.

Then there are the information entities that are inherent parts of this system. They are:

1. a potentially large set of criterion questions, whose nature is explained elsewhere, and which are envisaged as held and governed as a commons
2. a large, ephemeral set of enquiries, each of which is owned by one party (as above), which consist of “requirements” (i.e., what they want) over zero or more questions, specifying the characteristics of the other party, and/or the relationship / opportunity, that are being wanted / sought / looked for / required
3. a set of answers to the criterion questions given by parties about themselves — “property” questions — and about what kind of relationship they are looking for: relational questions.

Finally, there are the processing and storage facilities that are necessary to make such a system actually work. These are:

1. stores for the questions, that may best be distributed
2. places to store the characteristic answers of each party
3. places to compose active enquiries and store standing enquiries
4. places to perform the processing to compare active and standing enquiries to determine if there is correspondence, and to gather and feed back information about unanswered questions.

The processing to achieve this is quite distinct and different from existing database approaches. I've given the outline in words on the processing page, but it's clear that's missing a whole lot of explanatory strength. So I'll be trying to put together something that is as clear as I can possibly make it, complete with plenty of diagrams to illustrate what is happening.

I'll call this processing explained.