Three journals: what we touched, what you did, and what we warned about

A contractor working with a customer's data should be able to show exactly what they touched. Not "who opened a screen", but what was done to the data and what left it. That is what gets written here, in three journals kept deliberately apart.

The access journal: what was done, not who glanced

The decision was to record changes and exports, not views. The reason is plain: a customer does not care that someone opened a task list, they care what was changed and what was taken out. A sweep of the code found 44 points where the provider side touches customer data; forty-four lines of "opened a list" answer no question they will ever ask.

Background jobs are not recorded, and not by a list of names: background work has no person behind it, and the rule reads "no person, no row". Any new job written tomorrow falls under it by itself, without anyone remembering it exists.

What a row says

Every row carries what happened (created, changed, deleted, exported), over which kind of data, and how many objects were affected. For a task both numbers are shown through a separator, ours and the vendor's.

The change itself is written with values, but not for every field, and the line runs by meaning rather than by type. Status, priority, due date and hours estimate are written with their values, because a value like that is understandable on its own. Foreign keys are written by field name only, because "department: 3 to 5" is a riddle, not an answer. Content texts such as a title or an internal note are also written by name only: their values are the customer's data itself, and a journal proves a fact rather than keeping a second copy.

Money in a journal is closed by the same rule that closes it on screen

Whoever is not entitled to see amounts will not see them here either. The row stays where it is, the event stays visible, and the values come off the caption. An important detail: values come off the whole row, not only the money part, because a neighbouring field, hours or quantity, would let the amount be reconstructed by subtraction.

We did not hide the row entirely. A journal silent about the event itself is worse than a journal without numbers: the customer would not learn that the cap had been touched at all, and the silence would read as "nothing happened".

What the customer does on their side is a separate journal

The customer's actions in the portal have a journal of their own: sign-in, screens, reports, exports, changing a task's department. The two journals do not merge, and not for convenience: they answer different questions, have different readers and different retention. On one screen they stand side by side; in the data they remain two tables.

How long it is kept

The access journal is kept for seven years by default, and that is a setting rather than a constant: for another contractor the law names another period. The portal activity journal is kept for a year; it answers a different question and accumulates far faster.

The warnings journal: a private record of "I did warn you"

The third is built differently and is private: the customer does not see it. It exists for the moment when we warned, the decision went the other way, and two months later the problem surfaced.

A record has two shapes: they asked for something against our recommendation, or we warned on our own initiative. Each one states what we advised and what was decided, and later you can add what actually happened. A record moves through four stages over time: warned, chose otherwise, problem appeared, resolved. It can be tied to a task and to the people who were part of the story.

This is not a weapon. It is memory: in six months nobody will recall who said what, and the conversation will run on facts.

Where it lives

All three journals sit in one place inside the project. The customer sees their own access journal in the portal, on a separate page with two filters.

Frequently asked questions