Tuesday, February 17, 2004

Compliance Machine - functional requirements

Apologies for lack of response for the last couple of weeks, but life has been very hectic on all fronts. I have read the recent postings, and will respond briefly in two postings. This one is on the subject of the Compliance Machine:

I agree with Richard that the best way forward is to demonstrate enough of the technology to sell the idea to someone who is serious about applying it, in order to gain their trust, and to run a pilot scheme to attack a real-world issue. What we have working is the following:

1) Ability to build a machine to the specification I have already described.

2) Database technology and tools which enable us to build task-based user interfaces on the fly without any programming work. There are rough edges, but this is real, working technology.

3) Database with capability to view data as at any point in the past. This means that intelligent audit trails can be constructed without duplication of data. Such audit trails are the raw material for identifying the patterns of activity which presage the onset of instability, or identifying existing odd patterns of behaviour.

4) The nature of data to be captured is a matter of plugging in data feeds and defining the specifics of the case.

5) Our database can "assimilate" existing sources of data, so it can be fed from systems which already exist.

6) Within our team, we do not have the statistical knowledge to do the pattern analysis. However, I am sure that, within our collective network, there are people who have the necessary knowledge. From our perspective, we need the mathematical tools to be wrapped up inside one or more software components with defined interfaces through which we can request them to do their work. Between us, we ought to be able to define those interfaces and find or write the necessary components.

The most important missing element is the chance to get to work on a real problem.