Jarvis logging protocol

FIG.01: What does and does not go into the log[##--] sheet 1/2

On the left the metadata that carries the evidence, on the right the content that does not belong in it

Enough evidence with as little content as possible is not a slogan but a layout. The five rows on the left are the five points from the list below, pulled apart into the fields they are made of. The seven blocks on the right are blacked out because by default none of it reaches the log.

~/jarvis/trust/logging · fields.schema[ok] append-only

goes into the logmetadata

The request itselfrequest idtimestampactororganisationroute

Changes to accessauthenticationroleconnectorentitlement

Which version appliedsourcememoryagentapproval

What the run actually didtool actionresult statusdurationerror category

Interventions on your datasupport accessexportdeletionincident status

stays out by defaultcontent and secrets

Full prompts

Answers

Documents

API keys

Tokens

Payment card data

Special category personal data

exceptionif content logging is temporarily needed for an incident, it gets a purpose, an owner, a deadline, an access list and proof of deletion, and only then may it be switched on

# a schema of the layout, not a copy of a real log

What we do log

request id, timestamp, actor, organisation and route;
changes to authentication, role, connector and entitlement;
source, memory, agent and approval versions;
tool action, result status, duration and error category;
support access, export, deletion and incident status.

What we do not log by default

Full prompts, answers, documents, API keys, tokens, payment card data and special category personal data. If temporary content logging is necessary for an incident, it gets a purpose, an owner, a deadline, an access list and proof of deletion.

Integrity and access

Critical audit events are append-only, time synchronised and shielded. Only authorised roles can look at them. An export masks secrets and data belonging to other tenants.

Retention

Security logs, product logs and customer content logs each get their own period. Technical logs and security logs we keep for ninety days; email events and general logs likewise ninety days; a backup disappears at the latest thirty five days after the data has been removed from production. If a log belongs to a confirmed incident we keep that part longer, because we need it as evidence. These periods are set out in the privacy statement and the data processing agreement; those documents lead, and the periods are enforced and tested in the system itself.

Where this sits

This page describes how we build it. What we are legally allowed to do with your data is set out in the privacy statement and, for what we process on your behalf, in the data processing agreement. Where this explanation differs from those documents, the document applies. Both documents are on this site in English as well as Dutch, and Dutch law governs them either way.

FIG.02: How long a log line stays[####] sheet 2/2

Ninety days in production, then at most thirty five more in the backup

The two periods above stand here side by side on scale, ninety against thirty five. There is deliberately no total, because the backup period only starts at the moment the data leaves production. The bottom row is the only one without an end.

~/jarvis/trust/logging · retention[note] the document leads

technical logs and security logs90 d35 d

email events and general logs90 d35 d

log belonging to a confirmed incidentlonger, for as long as we need it as evidence →

90 d: in production35 d: at most, backup rotation after removal from productionno fixed end

# these periods are set out in the privacy statement and the data processing agreement; those documents lead, and the periods are enforced and tested in the system itself

Enough evidence. As little content as possible.