JiCoRedact. Approve. Document.
Glossary
JiCo's own vocabulary, explained in plain words - the panel and this website read from the same source.
From A to Z
Blocked (never read)
Projects JiCo never reads - not on a reference, not on an explicit request.
An area under this lock is not even read, let alone redacted (GR-2: what is never read does not have to be blacked out). In onboarding, in the Approval Cockpit, in jico status, in the audit and in messages to the AI model it is called the same everywhere: “blocked” (German: „gesperrt“).
Human in the loop
A human decides on every change before it reaches Jira - JiCo's ground rule GR-1.
The AI model proposes, JiCo holds, you approve or reject in the Approval Cockpit. Without that approval nothing is written, and it only holds for the state you saw (GR-5).
GR-1 — No write access without approval
Every changing and every unknown tool is held until a human decides.
Unknown counts as writing (fail-closed) - a new Jira tool that JiCo does not know yet never passes through unchecked.
GR-2 — Redaction happens before the AI model
Personal data is replaced before a single line reaches the AI model - never afterwards.
What has been in an AI model's context cannot be taken back. Filtering the AI model's output afterwards would therefore protect nothing any more.
GR-3 — The mapping stays minimal and expires
The placeholder ↔ plain text mapping is as small as possible and expires with the mapping deadline.
For Jira entities (user, assignee, reporter) only the stable Jira ID, no name; for everything else AES-256 encrypted and bound to the assignment. The AI model only ever sees the placeholder.
GR-4 — Nothing bypasses the gateway
Every path from the AI client to Jira runs through JiCo's gates - a direct access makes them useless.
That is why JiCo warns about a second, unprotected Jira access in the same AI client (jico check), and why the one-line terminal command for an approval points at JiCo, never at Jira directly.
GR-5 — An approval only holds for its state
If a ticket has changed since the analysis, an approval that was given is no longer executed.
The message „changed since the analysis“ is exactly that: JiCo reads the state again immediately before execution and stops on any deviation - even in a field the action does not touch. The action moves to the follow-up list with a reason.
Placeholder
What the AI model sees instead of a real name or value, for example «Person 1».
It is resolved the moment an approval is executed - locally, never inside the AI model context. A placeholder an assignment does not know (invented instead of read) aborts the execution.
Redaction balance
How many values of which type were redacted in a ticket - never the values themselves.
It appears in the audit trail and in the ticket replica list (Settings › Data care) as a total with a tooltip per type, for example „3 redacted“ with the detail „person: 2, IBAN: 1“ on hover.
Mapping deadline (TTL)
How long the placeholder ↔ plain text mapping is kept - 96 hours by default.
It expires earlier as soon as the last open proposal of an assignment has been decided. After that a placeholder can no longer be resolved - the assignment has to be repeated.
Proposal
A prepared but not yet executed change - waiting for approval.
It carries the command in plain professional language, the effect, the checked state of the ticket and the equivalent Jira call as evidence. Only after approval is it executed deterministically.
Outbound ledger
A record of what actually went to an AI model - hash, placeholders, final check.
Unlike the audit trail (proposal/decision/execution), the outbound ledger records what the AI model actually saw - the basis for „which personal data has the AI model seen?“.
Audit trail
A complete, append-only record of proposal, decision and execution.
It never contains plain-text personal data, only the redaction balance (count per type). Linked as a hash chain - a changed line stands out.
Ticket replica
A local, redacted and encrypted copy of tickets that were read - not a second plain-text store.
Limited by count, storage and deadline (Settings › Data care shows the fill level). Jira remains the source of truth; the replica speeds up repeated reading and the knowledge search.
Follow-up list
Prepared actions that could not be executed - with a reason, ready to repeat.
It fills up mainly through GR-5 stops (ticket changed since the analysis) and expired mapping deadlines.
Egress guard
Blocks network connections that do not belong to loopback or the configured services.
Violations are blocked and evidenced in the audit - protection against a dependency quietly sending data somewhere.
Masked
A particularly sensitive value (social security number, IBAN, credit card) was replaced by an identifier.
Unlike a pseudonymised personal name, a mask is not resolvable by default - only types explicitly configured as resolvable can be recovered with a password in the terminal.
Demo mode (honeypot)
A demonstration with invented data - no access to a real Jira, no ticket links.
For trying things out before setup. An installation started with --honigtopf cannot switch to real operation without being set up again.
Assignment
A repeatable run - scheduled or started by hand - across several projects or filters.
The findings of an assignment are grouped and condensed into an approval folder with open questions, prepared actions and a follow-up list.
Glossary (project glossary)
Jira vocabulary for the AI model context - something different from this glossary page.
Settings › Glossary collects synonyms, boundaries and query terms from Jira metadata (issue types, statuses, fields) so that the AI model phrases things consistently. It contains no ticket content and goes to every AI model as context. This page here explains JiCo itself - for people, not for the AI model.