IDEALY evidence is also a db representation, but in a specific
format when you do a evidence->persistant_store etc.. then you can
show homo/iso morpihms for any type of evidence/information.
in a db.. during module launching etc. everywhere.

so a evidence transducer takes evidence and transforms it to another
representation of evidence.. EvidenceRELATIONALDB etc, which then
plugs into a db etc through the knowledgebase.

evidence can really only be mapped to different namespaces. eg
for a relational db. you have a TABLE:COLUMN mapping.. for a hiearchical,
you get a A:B:C:D mapping.  now an evidence can only have 1 atom
in it though. so basically you can only map the prefix to something
else, and change the name to something else (Maybe a prefix).

thus we need seperate schemas for each different represenation of evidence.

-----------

informatns need to declare the evidence they generate. through xml.

<INFORMANT name="ELF32">
	<INPUT>
		<INPUT name = "ROOT:FILE:foobar" />

		<INPUT-BAG name = "ROOT:PROCESS:BinaryImage_MappedFIle>
			<INPUT name="TextImage" />
			<INPUT name="FileName" />
		</INPUT-BAG>
	</INPUT>
	</OUTPUT>
</INFORMANT>

-------------

OK.. evidence decomposition is working nicely.
decompose evidence to knowledgebase looks nice atm (without doing anything).

so..... how does evidence enter the knowledgebase?
who is responsible for the transfer?
** working pretty well.

detectives should definately handle the case where duplicate evidence
comes from the generator.

the judge should handle all unique information, or information that it
has directly requested.

each detective has its own local knowledgebase.
** yup.

the judge has the global knowledgebase.

--------------

evidence is a single instance of something.. eg, a filename, a pid, an image.

a correlation joins two pieces of evidence together.

evidence by itself may be duplicate, it is unimportant.
a correlation my be duplicate, which shows consistancy, and increases
	the chance that this correlation isnt just ~chance.
a correlation my "conflict" showing inconsistancy, and ~problems.

there is a finte set of evidence..  a filename, a process id etc.. the
correlations may grow high (expected).

evidenceroles are unique.. and should specify exactly what the ~thing is.
correlations should not be unique, but should follow a unique schema if the
evidence/correlations are consistant.

eg.. process listing

produces evidence..

process id
process name
process state

they are then correlated (eek.. we need a correlation schema for informants)

id : name
id : state

the correlations are inserted into the knowledge base..

the knowledge base verifies that the correlations are consistant, and
inserts/updates appropriately.

the judge looks at the knowledge base for things that can be
verified with other sources of correlations.

and asks the detectives/informants to investigate.

--

evidence in a single context has automatic correlations.
a graph representing these correlations is statically generated.

the correlations are calculated from the available evidence, and made
into a "statement".

the statement is given to the detective.

the detective introduces these correlations into the knowledge base..

and then it goes to the judge..

who goes back to detectives/informants.


-------------

use a knowledgebase (backend being a db), to store evidence.. rather
correlations (which there is a list of in evidence).

when we have new evidence.. we tell the detective about it. who stores
in the knowledge base.

this is how the detective knows if the evidence is consistant or not
(by checking the schema of the knoweldgebase.. or its contstraints to
stay valid).

the knowledge base has a fixed schema..

the process of investigation is about filling in the DB (which can grow
quite large).  and also to find inconsistancies.

----------

should a generator_elf32 be inherited from binary_elf32_exec ?

is a Signer_Copy actually a Copier (yes) change name?

the authenticator and signature are interwined based on the same underlying
	storage.

--

this is actually starting to look like an ml concept sorta.. but very very
twisted.


-------------------------
-->

"informatants" make "statements" to "detectives"
"informations" have one "detective"
"detectives" have many "informants"
"detectives" find consistanices or inconsistancies in "statements"
"detectives" may ask for "colaborations" from other "informatants"
"detectives" may take the collection of "statements" as "evidence"
"detectives" may pass "evidence" to the "judge"

------------------------

for improving false positives.. you want high level of correlation, to
	identify many consistancies.

for improving false negatives.. you want high level of correlation, to
	identify any incconsistancy.
	
------------------------

