JiCoRedact. Approve. Document.
Reference instead of reproduction
A pseudonym mapping that stores everything is just a second plain-text store with a politer name.
Redact · 2026-09-19 · 6 min read
The promise most vendors do not keep
"We pseudonymise your data" is one of the most popular sentences in data protection marketing — and one of the least examined. Because by definition pseudonymisation needs an assignment that can be resolved again: somewhere it has to be recorded what «Person 1» actually stands for, otherwise the placeholder would be nothing but data waste at the end of the session. The interesting question is not whether this assignment exists. It has to exist. The interesting question is what it looks like — and what happens if it falls into the wrong hands.
The obvious, convenient solution is a table: placeholder on the left, plain text on the right. Name, address, telephone number, all neatly filed in a database. That is precisely the table JiCo does not build — for a simple reason: such a table is itself a full-blown store of personal data. One would have recreated the very problem one set out to solve, merely somewhere else in the system.
Two cases, two answers
JiCo distinguishes between two kinds of personal data, because they differ fundamentally in technical terms — and treats them accordingly differently.
For Jira entities — the assignee of a ticket, the reporter, someone mentioned in a comment — JiCo already knows a stable, unambiguous attribute: the Jira ID. Storing this reference instead of the name carries no address, no date of birth, no contact details. It is a pointer, not content. Anyone wanting to resolve that pointer to find out who is behind it needs access to Jira itself anyway — so the mapping reproduces nothing that an attacker could not also fetch directly from the system if they were already inside it.
For everything else — a telephone number that appears loose in the ticket text, a name in a colleague's comment who is not a Jira user themselves — this stable reference does not exist. Here the only option left is to store the actual value, but encrypted with AES-256 and bound to exactly the one assignment for which it is needed. No global keyring, no store that grows across assignments.
Why anything has to be stored at all
One could ask: why not simply remember nothing? Every session starts empty, every placeholder expires immediately. That would be the most radical protection — and for an interactive conversation with an assistant it would even work, because there question and answer lie within the same session.
But it would make any assignment-based operation impossible. An overnight run that goes through 400 tickets and presents a condensed approval folder in the morning still needs the assignment between placeholder and origin hours later, when a human actually decides the next morning — long after the model last saw the placeholder. Without a mapping that survives that span of time there would be no overnight run, no queue, no automated pre-check. Only individual requests, one after another, with a human sitting alongside the whole time.
96 hours, and not an hour longer than necessary
Both kinds of mapping — the Jira reference as well as the encrypted free-text mapping — expire automatically after 96 hours. Frequently much earlier: as soon as the last open proposal of an assignment has been decided, the associated mapping is deleted, no matter how much of the 96 hours would still have been left. An assignment whose mapping has already expired is not quietly carried on with stale data — it counts as void and has to be started afresh.
This deadline is not an arbitrary number. It is the answer to the question of how long a human realistically needs to review an overnight approval folder and decide — plus a buffer, but not a blank cheque.
What appears in the audit trail — and what expressly does not
A detail that is easily overlooked when one looks only at the existence of an audit trail, not at its content: this mapping never appears in the audit trail. The audit trail evidences that redaction took place and how much, broken down by type — the number of names detected, the number of telephone numbers masked, that sort of thing. It does not evidence what was concretely redacted. Anyone reading the audit trail to understand what a model saw over the course of a week gets a balance, not a plain-text list. For the actual content they would still need either access to Jira directly or to the one time-limited mapping of an assignment that is still running.
A fixed number instead of a vague intention
The length of this deadline — 96 hours, not "as short as possible" or "as long as necessary" — is itself notable, because it is a concrete, verifiable number at all and not a vague declaration of intent. Storing for longer would have been technically more convenient: an assignment left lying because an approval only comes later would then simply carry on indefinitely. But that very convenience is the point at which data minimisation starts to cost something real, instead of remaining just a heading in a compliance document: the longer a mapping exists, the longer there is a file somewhere that could — with the right key — be assembled into a re-identification. A fixed, short deadline is therefore already a statement in itself: not "we promise to be frugal", but a number that can be read in the code and observed in the behaviour of the system, instead of merely standing in a brochure.
The boundary that applies to the model itself as well
One final detail that is often overlooked because it sounds counter-intuitive: in neither of the two cases does the model get to see the Jira ID — only the placeholder. One might think the ID is surely harmless enough to be passed through as a consolation prize, if no plain-text name is allowed. That is exactly what JiCo does not do. The reference exists solely so that JiCo itself can resolve at the end of the session who was meant — not so that the model gets a stable attribute of a person that can be recognised again across several tickets. Were the ID visible in the model context, one would have handed the model exactly the instrument with which it could recognise and link people across different requests — and preventing that, not merely hiding the name itself, is what the gate is there for.