Draft, pending approval

Data export and portability

Draft 28 October 2026, not yet in force

This description applies to the production service and takes effect together with the terms of service. Draft 28 October 2026.

The service provider is Enarra Oy (Business ID 3664892-5), “Enarra”. Enarra provides a software service called Tarumo. The Customer’s data belongs to the Customer. This page says which data can be exported, in which formats and structures, how an export is made and requested, what technical limitations apply and when the data is deleted. It is the description of switching and porting procedures under Article 26 of the EU Data Act (2023/2854) and the online register of data structures and formats. It is based on section 9 of the terms of service and section 17 of the data processing agreement. Where the texts differ, the contract applies.

This page is archived with each version of the terms of service under the same version identifier. The contract is governed by the version archived with the terms the Customer accepted. Every file carries the version number of its structure (schemaVersion).

In short

What an administrator can export in the service

Data Format Where
Published knowledge cards and their archived versions with sources (the expert or "Former expert", and dates), and the cards’ warnings about outdated or incorrect information without the reporter’s details JSON and Markdown Organization page, Data export
All data in one file: the published knowledge cards as above; key persons and their areas of expertise (departure date and its confirmation, criticality, sole expert, successor and link to a knowledge pack); the Customer’s own knowledge packs and the Customer’s changes to Enarra’s packs, with their versions, and the pack suggestions sent by experts in Mapping; coverage by area of expertise and by sub-area; users and their roles, the accountant, teams, team challenges, reward settings and the organisation’s other settings; the organisation’s whole log, except card views and card reports; read and "useful" counts per card as monthly totals (at least three reader-days), with no information about the readers ZIP file of JSON files Organization page, Data export, Download all data
The organisation’s log as CSV (at most the 10,000 newest events), except card views and card reports CSV Log page
The Mapping final report, if the Customer has had a Mapping Markdown Mapping page, Final report
Invoices PDF Invoices on the Organization page (customers who pay by invoice) or the Stripe payment portal (customers who pay by card, once online ordering is open). The accountant can download them too.

In addition, an interviewee can download the texts of their own interviews from the Interview page as Markdown or JSON for as long as they are kept (structure below). No one else can download them.

Technical limitations

What Enarra delivers on request

If an administrator cannot download the data themselves, for example because the organisation no longer has an administrator who can access the service, Enarra delivers the content of the Download all data file on request as JSON within 14 days at the latest. If a request is made during the export or retrieval period, Enarra delivers the data even if delivery falls after the period ends, and does not delete it before delivery.

What is not exported, and why

The following categories of data are not part of the Customer’s export. This does not prevent switching: the content meant for the organisation’s use moves as the published knowledge cards and the data listed above.

Category How it is handled Why it is not exported to the Customer
Interview texts and audio recordings, undecided card drafts and draft mapping proposals Short-lived working material of the interview, visible in the service only to the interviewee. The interviewee can download their own interview texts. An interview text is deleted when the card made from it is approved or rejected, and at the latest 30 days after the interview ended. An audio recording is deleted by default 30 days after transcription. The Customer, as controller, has defined the material as the interviewee's working tool, not as the organisation's material (sections 5 and 6 of the data processing agreement). The knowledge meant for the organisation moves as approved knowledge cards. Free-form answers may contain information that it is not necessary to disclose to the employer under section 3 of the Finnish Act on the Protection of Privacy in Working Life. This does not limit the interviewee's own rights.
Personal points, levels, achievements and reward choices Visible only to the person themselves. Incentives are off by default. The settings of team challenges and rewards are exported. The data is collected for the person's own use. Disclosing it to the employer would make it material suited to evaluating employees, which section 3 a of the terms prohibits, and would breach purpose limitation (Article 5(1)(b) of the GDPR) and section 3 of the Act on the Protection of Privacy in Working Life.
Individual card view rows (who opened which card and when) Exported only as monthly totals per card (at least three reader-days in the month) with no information about the readers (above). The rows are kept for 12 months to investigate security (section 5 of the data processing agreement). A person receives their own rows under section 13 of the data processing agreement. Reading data per person would tell the employer who read what and would be suited to monitoring employees (section 3 a of the terms, section 3 of the Act on the Protection of Privacy in Working Life). The organisation's need to know how the cards are used is met by the totals.
Who reported a card Reports are exported without the reporter. The reporter's identity is not needed to correct the card, and keeping it confidential protects the reporter.
Filtered content Not stored. There is nothing to export.
Search index vectors Computed from the published cards and deleted with them. The vectors depend on the model and settings Enarra has chosen and are of no use in another service. They can be recomputed from the exported cards. Exporting them would reveal Enarra's technical implementation.
The AI's prompts and the intermediate results of the risk calculation The service's internal workings. The result is shown in the coverage data. Enarra's trade secrets and intellectual property, which are not exportable data (Article 2(38) of the Data Act).
The service's technical log and Enarra's administration log Enarra's own processing for the service's security (privacy notice). What the Customer's users do is in the organisation's log, which is exported. The log concerns the service's infrastructure and may contain other customers' data. Disclosing it would weaken the service's security.
Enarra's general knowledge packs The Customer's changes to them are exported. Enarra's intellectual property.

File formats and structure

All files are in commonly used, machine-readable formats: JSON (UTF-8), Markdown (UTF-8), CSV (UTF-8, comma-separated) and PDF. The structure of the knowledge card JSON file is a contract and is described here. The Markdown file carries the same content for people to read, and its layout is not a contract.

The knowledge card JSON file (version 1)

Field Type Meaning
schemaVersion integer The version of the structure (now 1).
generatedAt string The moment of the export, ISO 8601 (UTC).
organization object { name, slug }: the organisation’s name and id.
cardCount number The number of current cards (archived versions are not counted).
cards array The current cards, sorted by area, category and title.

A card (an element of the cards array):

Field Type Meaning
id string (uuid) The card’s id. Stable: a later export has the same id for the same version.
title string The title the expert approved.
items string array The points of the card, in the expert’s words, in order.
source object { name, publishedAt }: the expert’s name as it was when the card was approved, and the moment of approval (ISO 8601).
topic object { area, category }: the area of expertise and the knowledge pack category, or null when the area has no pack.
locale string The language the card was written in (fi, en).
status string published for a current card.
provenance object The machine-readable marking under Article 50(2) of the AI Act: { aiAssisted, assistedBy, approvedBy, approvedAt }. The card’s text was made from an AI draft that the expert approved (aiAssisted is always true).
warning object or null The warning every member sees on the card: kind (marked or reported), reason (outdated or incorrect), on (the day, YYYY-MM-DD) and note (in the reporter’s words, or null).
history array Earlier versions the card replaced, newest first. The fields id, title, items, source, topic, locale, provenance and archivedAt.

The file never contains drafts or rejected cards, reporters’ details, user ids or email addresses, read counts or "helpful" marks. It holds no personal data other than the name of the card’s source.

The all-data ZIP file (version 1)

File Content Fields
organization.json The organisation’s settings (industry, audio retention, incentives, status), the package and key person limit, the Microsoft Teams settings, the Entra ID provisioning settings, HR connectors and API keys without any secrets. settings { industry, audioRetentionDays, incentivesEnabled, status, eraseAfter, createdAt }, plan { package, keyPersonLimit, keyPersonsUsed, startsOn, endsOn, invoiceReference } or null, microsoftTeams { enabled, allowedTenantIds }, entraProvisioning { entraTenantId, tenantConfirmed, defaultRole, groupRoles }, hrConnectors[] { id, kind, name, enabled, settings, hasCredentials, lastSyncAt, lastStatus }, integrationTokens[] { id, kind, name, scopes, createdBy, createdAt, expiresAt, lastUsedAt, revokedAt }
users.json Members with their roles and the days they joined and were removed (a removed member’s name and address are no longer shown), open invitations and the accountant. members[] { userId, name, email, role, status, joinedAt, removedAt }, invitations[] { id, email, role, expiresAt, expired }, accountants[] { userId, name, email, status, since, removedAt, removedReason }
key-persons.json Key persons (archived ones too), their departure details (type, day, confirmation and successor) and their areas of expertise (criticality, sole expert and the linked knowledge pack). keyPersons[] { id, displayName, jobTitle, startYear, userId, teamId, createdAt, archivedAt, departure { type, date, confirmed, successor { userId, name } }, areas[] { id, name, criticality, soleExpert, pack { packId, packKey, version, locale, name, own }, createdAt, archivedAt } }
coverage.json Coverage by area of expertise: the linked pack, the covered and all sub-areas, the share, and each sub-area with when it was covered. areas[] { areaId, areaName, keyPersonId, keyPersonName, pack, covered, total, share, categories[] { key, name, covered, coveredAt } }
packs.json The Customer’s own knowledge packs and the Enarra packs the Customer has changed, with all their versions and sub-areas, unfinished pack drafts and the pack suggestions sent by experts in Mapping. Enarra’s general packs only as named references. packs[] { id, packKey, basedOn { packId, packKey }, createdAt, versions[] { id, version, locale, name, description, vocabulary, reviewStatus, reviewedBy, contentHash, basedOnVersion { packKey, version }, createdAt, categories[] { key, position, name, description, questions } } }, drafts[] { id, packKey, packId, origin, locale, content, aiUnreviewedCategoryKeys, moderationStatus, revision, createdAt, updatedAt }, mappingSuggestions[] { id, author { userId, name }, locale, fit, targetPackKey, content, receivedOn, status, draftId, createdAt }
incentives.json Teams, team challenges as they were set up, reward settings and the reward granters. No challenge results, personal points or achievements. enabled, teams[] { id, name, createdAt, archivedAt }, challenges[] { id, title, teamId, teamName, target, startsOn, endsOn, rewardText, createdAt, archivedAt }, rewards[] { id, achievementKey, rewardText, createdAt, archivedAt }, rewardGranters[] { userId, name, assignedOn }
cards.json The published knowledge cards, in the knowledge card JSON structure. schemaVersion, generatedAt, organization, cardCount, cards[]
card-usage.json Each published card's read counts and "useful" marks per calendar month, with no information about the readers or the card's author. Only completed months in Finnish time are included. A month is released only if the card had at least three reader-days in it; other months are not released at all, and their figures are not carried over to other months. Reads are counted per day: the Service aims to count the same reader once per card and day, but a restart of the Service can count them again the same day. The author's own reads are not counted. One person reading on three different days also meets the condition, and the administrator cannot tell it from three readers. The reads of a released month do not change in later exports, but the number of "useful" marks can go down if a mark is withdrawn or a user's data is erased, and a card leaves the file when it is corrected or withdrawn. The card's id and title and its months: month (YYYY-MM), read counts and "useful" marks. A card with no month to release is listed with no months.
audit-log.json The organisation’s whole log, newest first, with no row limit: time, event, who, target and the event’s details. No card views and no card reports. entries[] { id, at, action, actorUserId, actor, targetType, targetId, target, metadata }
manifest.json Last: the structure’s version, the time of the export, the organisation, each file’s name, number of records, size in bytes and SHA-256 hash, and the lists of what the file leaves out and what Enarra delivers on request. format, schemaVersion, generatedAt, organization, documentation, files[] { name, records, bytes, sha256 }, excluded, onRequest

The file is made at the moment of the download, and no copy stays with Enarra. The files are read one after another: if data changes during the download, the change may show in one file and not in another. Fields without a value are null. A reader must ignore fields it does not know.

Other files

The interviewee’s own interview texts (version 1)

How to request an export, a transfer or deletion

  1. Send a written request to sales@tarumo.fi from the address of an administrator of the organisation. Give the organisation’s name and say what you want: an export of the data, a transfer to another service or to your own systems, or deletion only.
  2. Enarra confirms the request and delivers the requested JSON files within 14 days at the latest.
  3. When a switch to another service is requested, the notice period is two months or a shorter period the Customer gives. A 30-day transition period follows, during which the service works normally, and then a retrieval period of at least 30 days. The Customer can extend the transition period once. Enarra gives reasonable help with the switch (section 12 a of the terms of service).
  4. If the contract ends without a switching request, administrators can export the data for at least 30 days after the end. The service shows administrators the date by which the export must be made.

During the contract and until the end of the retrieval period an administrator can export the knowledge cards, all data as a ZIP file, the log and the reports themselves, without any request.

Deletion after the retrieval period

Questions

Questions about export can be sent to sales@tarumo.fi. Data location is described on the page Data location and access by authorities.