A system of events
Most software records what is. Phlo records what happened.
Most software keeps one row per thing and one value per field, and writes over it when something changes. Phlo adds an event instead, never overwrites, and works out the current state from what happened. That record is the centre of what you own when you own a Phlo system, and it is what gets handed over.
The usual way
One row, written over.
Open almost any business system and look at one record: an order, a bale, a truck. It has a status, a quantity, a date. Each is a single value. When something changes, the old value is replaced by the new one.
That answers one question: what is true now. It cannot answer the questions an operation asks when something goes wrong. What did it say yesterday. Who changed it. What happened in between. Some systems add a change log to cover this. The log sits beside the data, and usually covers only the fields someone chose to track.
So the missing history gets kept elsewhere: a register, a spreadsheet beside the system, a message in a group chat.
The Phlo way
Three rules, and everything follows from them.
- Append only. Every action is written as an event: what happened, who did it, when and where. An event is never edited and never deleted.
- The current state is worked out. Stock on hand, the status of an order, the balance owed: each is worked out from the events that led to it. The system keeps that result up to date as each event lands.
- A correction is a new event. A mistake is put right by adding an event on top of the old one. Both remain. The record shows the error, the fix, and who made each.
Nobody using the system has to think about any of this. The gate operator sees a form. The manager sees a list. The difference is in what is kept underneath.
A worked example
One bale of fabric, stored two ways.
A textile processing house's packing floor turns dyed fabric into bales. Each lump of fabric is measured and classified. On the packing floor its metres join the lot's pool, and the lot is cut into lengths called thaans and packed. Here is one bale, with invented values. On 12 September it was scanned out by mistake.
What a normal system would have stored
MRL-27-00412 · Bale
- Status
- Dispatched
- Dispatched on
- 16 Sep
One status and one date. The bale was marked as dispatched on the 12th and put back on the 13th. Neither fact is stored anywhere. Stock was wrong for a day, and nothing says so.
What Phlo stores
- 04 SepFolding completedOne lump of the lot folded and measured. QR sticker printed104.5 m
- 05 SepClassification recordedQR sticker scanned with the camera, labelled TF1
- 09 SepLump utilisedScanned onto the packing floor. Its metres join the lot's pool
- 09 SepThaan loggedCut from the lot's metres on the packing floor. Grade set from the metres42.0 m
- 10 SepBale setting createdBale MRL-27-00412. Packing slips printed
- 12 SepBale dispatchedScanned out with the morning batch
- 13 SepBale dispatch undoneThe bale was still on the floor. Back to Packed
- 16 SepBale dispatchedCustomer and invoice number recorded at confirmation
The undo on 13 September did not erase the dispatch of the 12th. It was added on top of it. Anyone who later asks why the stock figure dipped for a day can read the answer. And the bale can be followed backwards, through its thaans, to the lot and the gate pass it arrived on.
What that gives you
Four things an edited record cannot do.
Trace any outcome back to what caused it
The chain that produced a result is the data itself. A bale leads back to its thaans, the thaans to their lot, the lot to the truck it arrived on. Nothing has to be reconstructed from memory or from three files.
Nothing can be quietly changed
Append only. The original never disappears. What the record said before, who changed it and when all remain. A record that can be edited has to be taken on faith.
An audit trail nobody has to assemble
Every event already carries who did it and when. The audit trail is not a module and not a month-end job. It exists because of how the system stores what happens.
A record AI can read
Events are what AI reads. Records are what AI guesses from. A static record shows the current state and leaves the path to inference. An event log hands over the sequence.
Extends without a migration
New processes sit on the history you already have.
In a system that stores only the current state, adding a process usually means reshaping the data: new columns, a conversion script, a weekend when the old figures are moved into the new structure and checked by hand. Whatever the old structure never captured is gone.
In a system of events, the events are the data and the current figures are worked out from them. Adding a process means adding new kinds of event and new figures to derive. The events already recorded are not converted, re-keyed or re-entered. They stay as they were written.
Take the bale above. Suppose that next year the factory wanted a report on how often dispatches are undone, and at what time of day. No such report exists today, and nobody planned for it. In a system that stores one status per bale, that history was never kept. Here every undo is already in the log with its time and its author, so the report can cover the period before anyone thought to ask.
The same holds for a second system. It reads the history the first one recorded. It is why the second system costs a fraction of the first.
What gets handed over
An owned system whose history cannot be quietly rewritten.
Owning software has to mean more than holding a contract for it. With Phlo, what you hold is concrete: the complete record of what happened in your operation, in order, and a written description of how the operation runs, with its entities, its events and its exceptions.
This is also what gets handed over. When your own engineers build on Phlo, they build on this: a record of your operation that cannot be quietly rewritten, and a description of how it runs that already exists. They do not inherit a database whose columns have to be reverse-engineered. They inherit a list of named events, each of which means what the floor says it means.
That is the difference from a system a vendor builds and holds. There, the knowledge of why a figure is what it is leaves when the engagement ends. Here it is in the record. Phlo Framework describes what a team builds on, and How we work describes the choice after the first build.
The natural objections
Four fair questions.
Is it slower?
No. Screens do not replay history each time a page opens. When an event is recorded, the current state is updated in the same step, and the two are saved together or not at all. Lists and reports read that current state, as they would in any system. The current state is defined by the events behind it, so any figure can be traced to them. It is not something a user waits for.
Can we still fix mistakes?
Yes, and people do, every day. A wrong weight is corrected. A dispatch is undone. A received quantity is amended. Each fix is an event of its own, so the person fixing it does what they would do anywhere else: open the record and put it right. What they cannot do is make the earlier figure vanish. The rules for who may correct what, and until when, are part of your design: at the textile house a dispatch can be undone for a limited time.
Can an administrator edit the history?
Not through the system. There is no action that edits or deletes an event, for any role, the administrator included. An administrator can correct a figure like anyone else with the permission to, and that correction is an event with their name on it. This is a property of how the application is built, not a cryptographic seal: access to the database itself is controlled the way access to any production database is.
What about reports?
Reports look the way reports always look: totals, lists, ageing, exports to a spreadsheet. They are worked out from the events, so a figure on a report can be followed back to what produced it. And because the events are kept, a report designed next year can draw on history recorded this year.
The one thing an event record asks of you is discipline at the start. The events have to be the right ones, named the way your floor names them. That is why we map the process on site before anything is built. How we work describes those steps.
Get started
Every process in your operation, on one system.
Tell us how your operation runs today, and we will come back with what it takes to build it: the processes, the scope, and the timeline. Every system is scoped and built with you, so the first conversation is about your operation, not a demo.
coffee@jetbro.inWhatsApp +91 90999 62227