Start defining a formal model of Federated Bookkeeping

[michielbdejong]

We can define a model to help us talk about federated bookkeeping:

There is a network of 'actors', each with a 'bookkeeping system', and the bookkeeping system contains a 'data store' There are 'neighbour' connections between the actors There are 'private channel' connections between the bookkeeping systems The data store of a bookkeeping system will contain an append-only log of 'messages' that were sent/received over each of the private channels the system has with the systems of neighbours It can contain an asymmetric key pair for signing messages It can also contain an address book where it can look up public keys of other actors and check signatures

The bookkeeping systems then exchange messages corresponding to the promises the actors make to each other.

On top of this promise-sending layer you could define constructs like:

• standard business document flow (purchase order, delivery note, etc) / e-invoicing / logistics
• Collaborative Invoice Composition
• federated timesheets
• federated catalogues maybe?
• correspondent banking
• ledgerloops
• virtual organisations

[michielbdejong]

Apart from promises we also want to record decisions and real-world events.

We can define a few equivalent representations, and document how they are used in practice.

Good starting points, maybe:

• bank statements, their various CSV formats and transaction type codes, various MT940 flavours
• standard basic bookkeeping terms like 'Profit & Loss Statement' (see Kahn Academy and/or generic textbooks)

[michielbdejong]

We can study:

• the documents that are exchanged, and what they mean.
• the data that is stored in databases, and what they mean.
• the way existing software products transform data, for instance when generating an outgoing invoice from data in its internal database.

In our heads, all these documents and data rows have meaning that links them with each other and with the physical world, and a transformation can therefore be correct or incorrect.

We should probably also model these discrepancies because it's quite often that not all items are invoiced, so then we have two knowingly conflicting statements about the same thing.

Should we distinguish statements from representations? We can probably define a statement as a speech act referring to a specific representation. So an invoice is a representation, and me sending you an invoice is a statement claiming that that invoice should be considered correct.

So then instead of studying how the world works, we consider ourselves to be studying how representations of the world interrelate.