What the log is, and what it is not

Kiln records what happened as a sequence of events that are never edited and never deleted. A case is not a row that gets overwritten as it progresses. It is the list of things that happened to it, and the case you see on screen is what you get when you play that list forward.

That single decision is behind most of what the rest of this documentation describes, including two things that look unrelated to it: why registers exist, and why you declare, column by column, what a flow is allowed to receive.

Why the events rather than the current state

A system that overwrites can tell you what is true now. It cannot tell you what was true in March, or who decided otherwise, or which version of a rule was in force when a decision was taken. Those questions all get answered afterwards by reconstruction, which means by argument.

Playing a list forward answers them by reading. Which stage a case was in on a given day, who moved it, what an AI step was given and what it returned, which published version of a flow was live at the time: each is an entry, not an inference. When somebody asks why a decision went the way it did, the answer is a record rather than a recollection.

The cost of that is the subject of the rest of this page.

A log that never forgets cannot forget on request

An append-only log has one property that matters more than every other: you cannot take something out of it. That is the whole point, and it is the source of the only real problem it creates.

Much of what flows through a working process is personal information about somebody, and a good deal of it carries an obligation to destroy on request, or after a period, or when a purpose has ended. Those obligations are not negotiable, and they arrive on a shorter clock than the record of the decision needs to survive. A driver’s identity has a destruction obligation. The fact that a decision was taken about a driver, on a stated basis, on a given date, is something an organisation usually needs to keep for years.

Putting both in the same permanent list means honouring the first obligation requires breaking the second, and there is no setting that resolves it. So Kiln does not put both in the same list.

Decisions and references, not personal detail

The log holds what was decided, by whom, and on what basis. It holds a reference to the person or the thing the decision was about, rather than their details.

The details live somewhere that can be destroyed. That might be a system you already run, reached through a Connection, in which case that system stays the authority on it and Kiln never held a copy. Or it might be a register, which is the place inside Kiln for a list your organisation maintains itself. A register’s rows are ordinary mutable records: they can be corrected, and they can be destroyed outright.

So destruction becomes possible. You destroy the referenced record, and the log survives it, still saying that a decision was made and why.

This is also why registers exist at all. Once the log holds references rather than detail, the author needs a governed place to put the thing being referenced. Without one, the rule is advice rather than a design.

What that looks like when you use it

An old case whose referenced record has since been destroyed renders a placeholder where a name used to be.

That is the correct behaviour and not a fault. It shows that a decision was taken about somebody whose details you are no longer permitted to hold. The alternative, a record that still names them, is the thing the destruction obligation prohibited. A record that shows nothing was ever there would be a different and worse failure, because it would hide that a decision happened.

A consequence worth knowing before you design a process: a case is not self contained. Reading an old one depends on its references still resolving. That is the trade, and it is deliberate.

Receiving a value and recording it are the same act

A flow run records what each step was given and what it returned. That is what makes a run inspectable afterwards, and it is not optional.

It also means that handing a value to a flow and writing it into a permanent record are the same act. There is no way to let a flow see something without the run keeping it.

This is why a register declares, for each column, whether its values may travel. A column can be readable on screen by everybody in your tenant and still be forbidden from reaching a flow, and for a home address that is the ordinary case rather than an unusual one. The declaration is off until somebody turns it on, so a register that has declared nothing hands a flow nothing, and a lookup that comes back without a column says which ones it did not receive and why.

Authors find this surprising for about a day, and then it becomes the thing they point at when somebody asks how they know a value has not leaked into a report.

What the log is not

It is not a copy of your systems. Your origination system, ledger, asset register and CRM keep holding what they hold, and keep being the authority on it. The log records what Kiln did and what was decided, including which of those systems it called and what came back.

It is not a place to keep personal information. It is specifically designed to be the place where personal information is not, which is what allows it to be permanent.

It is not a complete history of everything Kiln has ever touched. Register rows are mutable and destroyable, and destroying a row destroys the record of who changed it along with it. That is deliberate: keeping “this person’s address was corrected on the eighth” after destroying the person is the same disclosure in a different table.

It is not a substitute for deciding your own privacy position. Where a process handles personal information, the collection notices, the rules about who may view an individual, and the retention schedule are yours to settle. Kiln gives you the mechanisms. It does not choose for you.

What you get for it

Three things, and they are worth the constraint.

Which version of a process was live when a given case was decided is establishable rather than reconstructed.

A decision taken by an automated step can be examined afterwards, including what it was given and what it returned, rather than trusted at the time.

And a duty to destroy is dischargeable, which for a permanent log is not a small claim. It is available only because the log was designed from the start to hold references to people rather than people.