How your data is handled.

Local Python can sort, calculate, reconcile, filter, aggregate, and create outputs. A workflow may use it before a model step when that improves the work.

The plugins do not automatically anonymise or pseudonymise data. Names, documents, original language, and case facts remain when they are useful for the professional purpose.

Each workflow can use data differently. Its own page explains the operational sequence: what the model sees, what code processes, and when the process stops. This page does not duplicate those workflow-specific statements.

Never put passwords, API keys, authentication cookies, access tokens, or session material in prompts or files the selected AI workspace can read.

Only 13 selected Vera pipelines produce this comparison report; their function pages identify them. Studio Archive records the start and finish of each run and generates the report at finalization from recorded execution evidence for each model-visible phase. The report compares the countable source population, local processing and model-visible data, and saves JSON and Markdown files in that run. Missing measurements make the report unavailable. If all data reaches the model or no measurable local remainder exists, there is no comparison report. A chat or another pipeline does not trigger one.

A possible narrower code path appears only when evidence from the run supports it and identifies a safeguard for analytical quality. A complete relevant document or population can be the correct minimum. The report is not network monitoring, a provider attestation, a DPIA, a legal opinion, or GDPR certification; a recorded hash binds a receipt to bytes but does not prove provider-side delivery.

The receipt-enabled Vera report command automatically sends Mparanza four fields: schema version, random receipt ID, Vera version and SHA-256 digest of the local report. Mparanza adds its server time and Ed25519 signature and retains those proof fields without the report, client data, filenames, source content, or source-document hashes. The resulting HTML can be sent to a customer, printed as PDF, and checked on the public verification page. This proves existence, server time, and report integrity only; it does not independently prove who submitted the digest. If the receipt service is unavailable, the work and local report remain complete and the request stays pending for retry.

Reading an existing report, the generic local Studio Archive report helper and the explicitly local onboarding path do not request a server receipt. The receipt service operates in Finland, EU, and retains signed proof without automatic expiry. IP addresses are not stored in the receipt database: the endpoint uses them for rate limiting, and access logs record them separately. Nginx keeps 14 daily archives plus the current file; no fixed maximum retention has been identified for the Uvicorn application log, which the operational script overwrites on restart. To be implemented: a 14-day retention limit with automatic deletion of technical logs. Signed receipts are excluded from this deletion.

The SHA-256 hash is a 64-character fingerprint calculated locally from the report, not an encrypted copy: there is no decryption operation that returns its contents. Someone who holds the report can recalculate its hash locally and compare it with the signed proof, without sending the report to Mparanza. Mparanza receives neither client names nor a mapping from hashes to people. Document confidentiality is protected by excluding the contents from the request; automatic submission creates the technical receipt.

A connected app, public search, portal, or send action is used only when that route is part of the selected work. The destination's terms and controls apply separately.

Using an external destination does not make Mparanza the recipient. The workflow or point-of-use notice identifies a Mparanza-hosted route when one is involved.

Vera automatically records which processes are used and their observed outcome: started, completed, failed or cancelled. A run with no observed outcome remains unknown. A random installation identifier, without a named account, also allows repeat usage to be measured. Records include the process, host application, Vera version and event timestamps.

Users can rate the result from 1 to 5 stars and add an optional comment to help improve Vera. Without a response, the result remains unrated. Periodic AI monitoring reviews usage, outcomes and feedback to identify problems and improve the functions.

Usage events contain no client documents, task text, filenames, prompts or professional outputs. They can link to an existing technical receipt through its identifier and report hash without sending the report. Studio Archive and supporting operations are not counted as separate processes; synthetic and agent tests are excluded from ordinary usage statistics.

The service operates in Finland. Events, ratings, optional comments and receipt links are retained until administrative deletion, without automatic expiry. Events awaiting delivery remain in the local queue until receipt is acknowledged.

When a function uses a Mparanza-hosted service, the content needed for that service reaches Mparanza-controlled systems. Hosted interviews, voice capture, and retail data are examples.

The notice shown where that service is used states what reaches it and the applicable access, retention, and deletion arrangement.