Service Conditions

These conditions govern the use of the EVIDE platform operated by Informatica in Azienda, directed by Dott. Emanuel Celano. These conditions, together with the Privacy Policy, apply to the use of the platform. The way in which they are accepted is described in Section 16.

The platform may be used both by professional users, acting for purposes relating to their trade, business, craft or profession, and by consumers, meaning natural persons acting for purposes outside those activities. Where these conditions contain specific rules for consumers, those rules apply to consumer users. Nothing in these conditions limits the rights that consumers have under mandatory consumer-protection law, including the Italian Consumer Code (Legislative Decree 206/2005) and, for consumers resident in another country, the mandatory provisions of the law of that country. Services specifically intended for household or personal use, if offered in the future, may be subject to supplementary conditions. Users must be at least 18 years old.

EVIDE is provided as-is. We strive for maximum availability but do not guarantee uninterrupted service. Temporary interruptions may occur due to maintenance, technical issues, or circumstances beyond our control. Service interruptions do not invalidate evidentiary records already created: intake hashes remain verifiable with standard SHA-256 tools, applied to the original material or, for structured intakes, to its canonical form as documented by EVIDE, and the UTC timestamp remains the reference recorded by EVIDE at deposit time. For consumers, this section does not affect the legal guarantee of conformity of digital content and digital services provided by the Consumer Code.

EVIDE depends on third-party infrastructure including hosting providers, SSL authorities, email delivery services, and, for the FEDIS service only, qualified trust service providers for signatures and time stamps. The base EVIDE deposit does not use qualified time stamps: its UTC timestamp is generated by the EVIDE server. We cannot be held liable for service degradations caused by maintenance, updates, or failures of these providers. In such cases, service will be restored as quickly as technically possible, except where mandatory law requires otherwise.

EVIDE is a shared-infrastructure platform designed for professional use at the volumes indicated in each plan. Users requiring more than 500 intakes/month must contact us before activating such volumes to arrange a dedicated infrastructure solution. Standard service plans are not designed to guarantee enterprise-level SLAs at high-volume or continuous-throughput workloads. Performance degradations caused by volumes exceeding the plan threshold do not constitute breach of contract. We reserve the right to suspend accounts generating disproportionate load without prior agreement, with 24 hours notice and proportional refund of the unused period, except where mandatory law requires otherwise.

We reserve the right to modify service prices at any time. Price changes will be communicated with at least 30 days notice via email to the registered address. Users with active paid plans retain their current price until the end of the paid period. Renewal after the effective date of the new pricing will be at the updated rates. Continued use of the service after the effective date constitutes acceptance of the new pricing. Consumers are notified of price changes in the same way and may terminate the contract, without penalty, before the new prices take effect.

We reserve the right to modify, improve, or discontinue features of the platform with 30 days notice. In case of discontinuation of the platform, intake hashes already computed remain independently verifiable with standard SHA-256 verification tools, provided that the holder keeps the original material (or, for structured intakes, its canonical form) and the reference hash. The UTC timestamp remains the reference recorded by EVIDE at deposit time: it is not verified with hash tools. Where a modification negatively affects a consumer's access to or use of a paid digital service more than marginally, the consumer is informed in advance and may terminate the contract free of charge, as provided by the Consumer Code.

7.1 Responsibility. The user is solely responsible for the content deposited. It is prohibited to use the platform to deposit illegal, fraudulent, or rights-infringing content. EVIDE does not moderate deposited content but reserves the right to deactivate accounts in case of documented violations, as described in Section 13.5. The user is responsible for having a lawful basis for any personal data of third parties included in deposited content.

7.2 Ownership. Depositing content does not transfer its ownership to Informatica in Azienda. Materials submitted by the user (uploaded content, payloads, declarations and other inputs) remain the property of the user or of the relevant rights holders. The user grants Informatica in Azienda only the rights needed to provide the service, namely to store, hash, process and reproduce those materials in the platform's records, in FEDIS documents and, where the user has requested publication, in the public registry. The EVIDE platform, its software, schemas, APIs and documentation, and the formats of the records it generates (such as EAR versions, evidentiary profiles and FEDIS documents) belong to Informatica in Azienda; this gives Informatica in Azienda no right over the user's content contained in those records, and the user may use the records and FEDIS documents relating to their own deposits for their own purposes.

7.3 No sale of data. Informatica in Azienda does not sell, trade, rent or license deposit contents (uploaded content, intake payloads, declarations and the contents of EAR and ESB records) to third parties for those third parties' own purposes. Deposit contents are used only to provide and document the service requested by the user, to comply with legal obligations and to protect the security of the platform; they are not reused for advertising, other commercial purposes, unrelated research or third-party purposes without an appropriate legal basis and the user's authorization. Informatica in Azienda may use aggregated statistics that contain neither deposit contents nor personal data, such as the number of intakes processed. This commitment does not prevent processing by the technical providers that Informatica in Azienda uses to provide the service, such as hosting and qualified trust service providers, as described in the Privacy Policy, nor disclosures required by law or by an order of a competent authority.

7.4 Artificial intelligence. Informatica in Azienda does not use deposit contents to train, fine-tune or evaluate its own AI models or those of third parties. The platform does not transmit deposit contents to external AI services. Informatica in Azienda does not provide deposit contents to external AI services that it uses manually, for example to support the development or maintenance of the platform, unless the contents have been anonymised or the user has authorized it in writing for a specific purpose, under arrangements that prevent the provider from using them for its own purposes. Integrations operated by the user, such as AI agents or MCP clients that send data to EVIDE, are under the user's control.

7.5 Confidentiality. Informatica in Azienda treats deposit contents as confidential and limits access to them to the persons who need it to provide the service, such as the certifier when a FEDIS is requested. Deposit contents are never published: the public registry shows only the information described in Section 13.9.

7.6 Organizations and former members. A user who belongs to an organization on the platform may deposit intakes for that organization. Intakes deposited for an organization are records of that organization: they are accessible to its current members and are billed to the organization. Any new operation on an organization's intake, such as requesting a FEDIS, accepting or declining a quote, sending messages, adding linked intakes to an evidentiary chain, updating or closing an ESB, or using an API key issued for the organization, requires current membership of the organization at the time of the operation, in addition to the other conditions that apply to that operation. When a user stops being a member, the user's authority to act for the organization ends immediately; API keys issued for the organization in that user's name stop operating for the organization, without being revoked, until the user is readmitted or the key is reassigned. A former member keeps read-only access to the intakes that he or she personally deposited for the organization, limited to the intake itself, its EAR versions, the evidence still stored on the platform and the current status of the request. The former member does not see the messages, the status history, quotes, prices or other economic details of the request, or the other intakes of the organization's evidentiary chain, and cannot perform any operation on those intakes. Former members who did not make a deposit have no access to it. By depositing intakes through its members, an organization acknowledges that the member who made a deposit keeps this limited access after leaving. An organization that needs a different arrangement for specific intakes should contact Informatica in Azienda before depositing them, or may request their deletion in accordance with Section 13.7.

7.7 Linked Responses. Where the Linked Responses function is available on the platform, the user who deposited an intake may invite a named person, identified by DAPI number, first name and last name, to declare his or her own position on a representation of that intake. For an organization's intake, the depositor must be a current member of the organization (Section 7.6). On creating the invitation, the depositor declares that he or she is authorized to share the content with the recipient and that the sharing is permitted by the applicable rules and, for an organization's intake, by the organization's authorizations; these remain declarations of the depositor and are not verified by EVIDE. The invitation is personal: it can be used only through the EVIDE account whose DAPI number, first name and last name match those indicated, and it expires 30 days after its creation.

What the recipient receives is not the record: it is a FAST REVIEW representation generated by the platform from the record indicated by the depositor, according to the applicable template, and frozen with its identifier and fingerprint. In this version the fixed phrases of the representation are in Italian; the highlighted parts in quotation marks reproduce texts present in the record as entered through the depositor's account, and the representation does not establish who their original author is. The recipient does not receive the full record or the external documents that the record cites. The recipient may declare one of four positions on that representation (agree, acknowledge without expressing agreement, dispute, not in a position to assess), adding a motivation, which is required in order to dispute, and a reservation; a later response may replace or supplement an earlier one, which remains preserved. Each response is a record of the recipient and is documented in an EAR-LINKED record; the depositor cannot modify or delete it. EVIDE records the requests to open the link that its server receives and the declarations made by the recipient; these do not prove that a page was displayed, read or understood, and a declaration of having taken note of a notice is not consent.

A response is visible to the recipient, to the depositor while he or she has access to the record under these conditions (for an organization's intake, while he or she is a current member) and, where the depositor has chosen this visibility, to the current members of the organization; former members do not see it. The depositor may revoke an invitation directly. For an organization's intake, revocation follows the rules recorded for the invitation when it was created: these may instead require a revocation request, submitted by the depositor and decided by a current owner or admin of the organization other than the requester and the depositor, or by a review authority designated by the organization whose designation has been verified with the outcome «confirmed»; urgent requests suspend the invitation until the decision. Informatica in Azienda may suspend an invitation for security reasons. If the depositor stops being a member of the organization, the invitations he or she created on its intakes are closed definitively, unless they were created under the rules that keep them usable until their original expiry; in that case the current owners and admins of the organization may suspend, resume or revoke them, stating a reason. Revocations and suspensions prevent new responses and do not modify or delete responses already deposited.

For the review authority, EVIDE records the title document received (its metadata and a reference, not the document itself), the designation and the verification documented by a verifier appointed by Informatica in Azienda, with the method, the source examined and the outcome declared by the verifier. Neither the declarations of the depositor or of the organization nor the recorded verification are an attestation by EVIDE of the legal validity of the power to share or to decide. A response does not modify, confirm or verify the record, does not certify that the record or any declaration is true, and is not assessed by EVIDE; Sections 8 and 9 apply. Responses may be documented in a FEDIS-LINKED under the conditions of Section 7.8. Linked Responses records are retained as evidentiary records (Section 13.3), and the processing of the related personal data is described in the Privacy Policy.

7.8 FEDIS-LINKED. When the FEDIS-LINKED function is available on the platform, the depositor of a structured intake deposited through the web interface or the EVIDE Mobile app (Human Structured Intake) may request a FEDIS that documents, in addition to the intake, the includable linked responses (FEDIS-LINKED). The request follows the same procedure and the same economic conditions as any FEDIS: a quote from the certifier, express acceptance by the requester, use of any FEDIS packages and invoicing. A FEDIS-LINKED may be requested only by the depositor of the intake and, for an organization's intake, only while the depositor is a current member of the organization (Section 7.6). Where an intake has includable responses, the other members of the organization cannot request a FEDIS on that intake.

Only responses that were deposited after the recipient was shown the notice describing FEDIS-LINKED, in a version recorded by the platform as eligible, and whose EAR-LINKED record passes the integrity check, are includable. Revocation or suspension of the invitation after the deposit does not exclude the response; the document states the date of any revocation. If a response or an EAR-LINKED fails the integrity check, the request is not accepted.

Each request gives rise to a separate technical record, placed in the same scope as the intake (personal or organization), and to a snapshot of the relevant records. The snapshot is formed by the platform from its own archive at the time of the request and is identified by its SHA-256 fingerprint. For each included response, the FEDIS-LINKED reports: the respondent's name and DAPI number, any declared role, the positions, motivations and reservations, the deposit date, the visibility indicated in the invitation, and the identifiers and fingerprints of the response and of its EAR-LINKED. It also reports descriptive counts of invitations and responses. For non-includable responses and for invitations without a deposit, it reports counts only, without names or content. When the document is generated, the platform recomputes the fingerprints of the reported records that are still available and compares them with the recorded ones; if there is a discrepancy, the document is not generated, and records no longer available are indicated as not re-verified. Successive requests form a series: each FEDIS-LINKED is an autonomous document, linked to the previous ones, which it neither modifies nor replaces. A new request is possible only after the previous FEDIS request on the same intake has been concluded, and only if there are includable responses not yet documented in an issued FEDIS-LINKED.

The FEDIS-LINKED is delivered to the requester, who may use it and hand it to third parties regardless of the visibility of the response on the platform. The recipient of a FEDIS-LINKED is responsible, within the limits provided by law, for the uses made of it and for any communication to third parties of the personal data it contains, which must comply with applicable law and serve legitimate purposes. The document is not made available through the platform to the other members of the organization, and the technical record is not published in the public registry. When a FEDIS-LINKED is issued, each depositor of an included response receives an essential notice at the address of their account, without data from other responses.

Where a respondent objects to the processing of their data in FEDIS-LINKED documents, Informatica in Azienda may suspend, during the assessment, new requests and issuances that would include that response. The suspension does not modify or delete any record and does not affect documents already issued.

A FEDIS-LINKED documents the existence, integrity and content of the records at the snapshot time. It does not certify that the intake or the responses are true, that any agreement or consensus exists among the participants, or any declared role or power; the counts are counts of individual declarations, not a vote. Sections 8, 9 and 13.8 apply.

EVIDE produces independently verifiable evidentiary records anchored to a SHA-256 cryptographic intake hash, a server-generated UTC timestamp, and an identity reference linked to the user's DAPI-verified account. Roles, authority and other statements contained in a deposit remain declarations of the depositor unless the service description states that they are independently verified. The timestamp of the base deposit is generated by the EVIDE server and is not a qualified time stamp. FEDIS is a separate document, generated by the platform and signed by the certifier, that, under the current certification workflow, states the SHA-256 fingerprints of the intake record and of a specific EAR version (see Section 13.8) and adds a qualified electronic signature, a qualified electronic time stamp (eIDAS Art. 41) issued by a third-party qualified trust service provider and documented chain of custody; the time stamp attests the moment at which it is applied to the FEDIS document and does not make the timestamp of the base deposit qualified. Combined with FEDIS forensic certification, these records are prepared with reference to ISO/IEC 27037:2012 international standards, eIDAS (EU Regulation 910/2014), and Federal Rules of Evidence 901-902 (USA), providing structured forensic documentation usable in judicial, regulatory, and investigative contexts across the EU, United States, United Kingdom, Canada, Australia, and equivalent jurisdictions.

The essential distinction: EVIDE and FEDIS operate as a probatory crystallization layer -- not as a guarantee of automatic admissibility. They do not replace the evaluation of the competent authority, the procedural rules of the jurisdiction, or the role of the court. Their function is to reduce uncertainty by documenting the technical conditions that support evidentiary reliability, making integrity verification objective and independent of trust in the certifying platform.

Admissibility, legal weight, or procedural acceptance of evidentiary records may still vary depending on jurisdiction, court, or regulator. The user is responsible for assessing the legal context of their specific proceeding, before subscribing to the service, and for obtaining independent legal advice where required. Learn more about FEDIS forensic certification →

EVIDE verifies structural integrity, identity attribution, and intake timing of deposited records. It does not independently verify the factual accuracy, authenticity, completeness, or truthfulness of user-submitted content, declarations, metadata, or any fields declared by the user unless explicitly stated in the service description. The evidentiary value of an EVIDE record derives from its anchoring and integrity properties, not from any guarantee of the accuracy of the declared content.

All timestamps generated by EVIDE are expressed in Coordinated Universal Time (UTC) and represent the platform's independently generated intake time at the moment of deposit processing. EVIDE timestamps are generated server-side and are independent of the user's local clock, device timezone, or client-side time references. They do not represent the time of content creation, signing, or transmission by the user. Discrepancies between user-side timestamps and EVIDE intake timestamps do not constitute a platform error.

Users are responsible for maintaining the confidentiality of API keys, credentials, access tokens, and DAPI codes associated with their account. Actions performed through authenticated credentials -- including API calls, MCP-mediated deposits, and agent-initiated intakes -- are considered attributable to the account holder unless proven otherwise under applicable law. In case of suspected compromise of credentials, the user must notify us immediately at info@informaticainazienda.it. Informatica in Azienda cannot be held liable for deposits, records, or actions performed through credentials that the user failed to protect. When an account is deactivated, the credentials associated with it are suspended as described in Section 13.5. Informatica in Azienda may also revoke individual credentials, for example in case of suspected compromise; revoked credentials do not become valid again.

The platform may not be used in violation of applicable export controls, sanctions regulations, or laws governing digital evidence and restricted technologies. Use of EVIDE is prohibited where such use would violate the laws of the user's jurisdiction or applicable international regulations. Informatica in Azienda reserves the right to restrict access to users or organizations subject to applicable sanctions or operating in jurisdictions where the service cannot be legally provided.

13.1 Categories of records. In providing the service, EVIDE processes different categories of records, which are subject to different rules: (a) account data, such as name, email address, DAPI number and organization; (b) canonical intake records, including the intake hash, the server-generated UTC timestamp, the evide_id, the submitted payload and the evidentiary profile computed by the platform; (c) Evidentiary Artifact Record (EAR) versions and their hashes; (d) Epistemic Stabilization Buffer (ESB) observations, declarations and closure records; (e) content uploaded by the user; (f) FEDIS documents and the records they reference; (g) entries in the EVIDE public registry; (h) operational, security and access logs and billing records; (i) Linked Responses records, such as invitations, declarations, FAST REVIEW representations, responses, EAR-LINKED records, revocation requests, suspensions, revocations and decisions and review-authority data, FEDIS-LINKED snapshots, technical records, notices and suspensions, and the register of changes to organization memberships and to the status of accounts, DAPI identities on EVIDE and organizations; (j) technical records of API requests sent with an idempotency key (Section 13.11). Some of these records may contain personal data of the user or of third parties. A record is not excluded from data protection law merely because it is a hash, an identifier or a technical record.

13.2 Uploaded content. For intakes submitted with uploaded content (files, ZIP archives, or a URL or text that the platform stores as a file), the uploaded content is stored on the platform's servers for a limited period and is then deleted, as published in the service description. While it is stored, the user can download it from the account. When a FEDIS is issued for such an intake, its uploaded content is deleted from the platform's storage at the time of issuance; the user should keep an independent copy, or download the content, before issuance. Structured intakes do not include uploaded content: the data submitted with them forms part of the canonical intake record and is handled under Section 13.3. Deletion of uploaded content does not delete the canonical intake record, including the intake hash, nor EAR versions, ESB records or the related metadata, such as the name, size and hash of the uploaded file. The user is solely responsible for keeping an independent copy of any content deposited.

13.3 Retention of evidentiary records. Canonical intake records, EAR versions, ESB records and related integrity metadata are not deleted automatically when uploaded content is deleted, when a plan expires, when an account is deactivated or when the contract is terminated. They are retained for as long as necessary to document the deposit and to allow its later verification, in accordance with the retention criteria set out in the Privacy Policy and with applicable law, unless they are deleted earlier through an authorized deletion under Section 13.7. EVIDE does not guarantee that any record will remain available indefinitely.

13.4 Versioning and integrity. In the ordinary operation of the platform, an EAR version, once generated, is not edited: when the canonical evidentiary state changes, a new version is added, and each version has a recorded SHA-256 hash. Recomputing the SHA-256 hash of a copy and comparing it with a reference hash shows whether that copy is consistent with the reference. The comparison does not, by itself, prove that both the stored record and the reference hash have remained unchanged; that depends on where and how the reference hash was preserved, for example in a FEDIS or in a copy kept by the user. Hash consistency does not establish that the content of a record, or any declaration in it, is true. This section describes how records are handled by the platform; it is not a promise that records can never be removed in the circumstances described in Sections 13.7 to 13.10.

13.5 Account deactivation. Deactivation is an administrative measure. Informatica in Azienda may deactivate an account, in particular in the cases described in Sections 4, 7, 11 and 12, at the user's request, or for security reasons. While an account is deactivated, all authenticated access is suspended: web sessions, mobile access tokens and API keys associated with the account are rejected, and no new deposits, ESB updates or closures can be made. Deactivation does not delete account data, intake records, EAR versions, ESB records, FEDIS documents or other records, and it is neither a termination of the contractual relationship nor an erasure of personal data. If the account is reactivated, credentials that have not expired and have not been explicitly revoked may be used again.

13.6 Termination, account closure and permanent deletion. The user may request termination of the contract, closure of the account or permanent deletion of the account by writing to app@certifywebcontent.com or, alternatively, to info@informaticainazienda.it. Informatica in Azienda may terminate the service in the cases provided for in these conditions or by law. Termination ends access to the platform and does not affect payment obligations that have already accrued; on its own, it does not delete account data or records, which are handled in accordance with Section 13.3. Where the user requests closure of the account, Informatica in Azienda, after verifying the identity and documented authority of the requester, deletes the user's personal intakes that can be deleted under Section 13.7, together with their dependent records, permanently revokes the user's sessions and API keys and removes the user's organization memberships. If no record linked to the account has to be retained, the account and the enrolment of the user's DAPI identity on EVIDE are deleted. If records linked to the account have to be retained, such as intakes deposited for an organization, intakes that cannot be deleted under Section 13.7 or records that must be kept by law, the account is kept in a closed state, linked only to those records: it cannot be used to sign in and is not used for any other purpose, and the user is informed of the records retained and of the reasons. Closing an EVIDE account does not revoke or alter the user's DAPI certification, which is governed by its own terms. A closed account is never reopened automatically: access may be restored only on request, after verification of the requester's identity, and a user whose account has been deleted may be enrolled again as a new account; in both cases, deleted records, revoked credentials and former organization memberships are not restored. Deletion removes the deleted data from the platform's active systems; it does not reach documents already delivered to the user or to third parties, copies outside the control of Informatica in Azienda, records that must be retained by law, or backup copies until they are overwritten, as described in the Privacy Policy. Deactivation (Section 13.5) is neither closure nor deletion.

13.7 Requests to delete intakes and accounts. The platform does not currently offer users a self-service function to delete intakes, EAR versions, ESB records or the account. Requests are made in writing to app@certifywebcontent.com or, alternatively, to info@informaticainazienda.it and may concern one intake, several intakes, all intakes associated with an account, or the account itself. A request received through another channel is not disregarded for that reason alone; in no case is the address from which a request is sent, in itself, sufficient proof of the requester's identity or authority. Informatica in Azienda verifies the identity and documented authority of the requester and assesses each request in accordance with applicable law, taking into account, in particular, whether a FEDIS has been issued, whether the intake is referenced by other intakes in an evidentiary chain, the rights and interests of third parties and any retention required by law. The existence of a FEDIS or of EAR versions does not in itself prevent deletion; equally, not every request will necessarily be granted. Where deletion is authorized, its scope may include the canonical intake record, EAR versions, ESB buffers and events, public-registry entries, FEDIS-related platform records and other associated technical records. Records are deleted in an order that preserves the integrity of evidentiary chains: an intake on which other intakes depend in a chain is not deleted while those intakes remain, and the chain of the remaining intakes is never altered. Where an authorized deletion cannot be carried out for technical reasons, for example because an issued FEDIS is linked to package or billing records that the platform keeps unaltered, the request is assessed separately; where erasure is due but cannot be carried out at that time, processing is restricted. A technical constraint is not in itself a legal ground for refusing erasure. Intakes deposited for an organization are assessed also in the light of the organization's rights (Section 7.6). Intakes to which Linked Responses invitations or responses are linked are not deleted through the ordinary procedure: the request is assessed separately, also taking into account the rights of the recipients over their own responses and the related revocation records (Section 7.7). A request to delete all intakes is not automatically treated as a request to close the account, and vice versa. The requester is informed of the deletion actually carried out and, where a request is not granted in full, of the reasons. Where a request is made under data protection law, Section 13.10 also applies.

13.8 Certified records (FEDIS). A FEDIS is a separate document, signed by the certifier and delivered to the user. A FEDIS issued under the current certification workflow states two SHA-256 fingerprints: the intake hash (for intakes with uploaded content, the fingerprint of the received content; for structured intakes, the fingerprint of the canonical intake record) and the hash of the specific EAR version that was current when the FEDIS was issued. That EAR version remains the reference for the FEDIS even if later EAR versions are generated. A FEDIS-LINKED also states the SHA-256 fingerprint of the snapshot of the linked responses and, for each included response, the fingerprints of the response and of its EAR-LINKED, with the outcome of the checks performed when it was generated (Section 7.8). A FEDIS issued before EAR references were introduced into the certification workflow may not reference an EAR version. An authorized deletion under Section 13.7 may include the platform records referenced by a FEDIS. Deletion of platform records does not alter or revoke a FEDIS document already delivered, and that document cannot be removed from the possession of the user or of third parties to whom it has been delivered; once the relevant platform records have been deleted, however, it may no longer be possible to verify that FEDIS against EVIDE's records. Accounting and tax records relating to a FEDIS, such as invoices, are separate from the evidentiary records and are retained as required by law.

13.9 Public registry. An entry is published in the EVIDE public registry only at the depositor's request, made when submitting the intake, where the form offers this option, or in writing, and only for intakes for which a FEDIS has been issued; publication is carried out by the certifier. A published entry shows the reference ID, the FEDIS code, the status, the intake hash, the intake timestamp and the publication date; the registry may also show other published entries with the same hash and, for intakes that belong to an evidentiary chain, the position of the entry in the chain. The technical records of FEDIS-LINKED documents are not published in the public registry. Published entries are publicly accessible and may be indexed by search engines. The user may request removal of an entry at any time by writing to app@certifywebcontent.com or, alternatively, to info@informaticainazienda.it. Removal from the public registry removes the public listing only: it does not delete the underlying intake records, EAR versions or FEDIS documents, and it does not revoke, invalidate or alter an issued FEDIS. Informatica in Azienda cannot control copies of public listings made by third parties, including search engines, before removal.

13.10 Data protection rights. Nothing in these conditions limits the rights that data subjects have under Regulation (EU) 2016/679 (GDPR) or other mandatory law, including the rights of access, rectification, erasure, restriction and objection. Requests to exercise these rights are handled as described in the Privacy Policy and within the time limits set by law. Where the erasure of personal data is requested, Informatica in Azienda will assess whether one of the exceptions provided for in Article 17(3) GDPR applies in the specific case, for example where retention is necessary for the establishment, exercise or defence of legal claims. Any such exception is applied only to the extent that it is necessary in the specific case; where it applies, processing may be restricted instead of the data being erased. Administrative deactivation (Section 13.5) and termination (Section 13.6) are distinct from erasure and do not replace the assessment of an erasure request. The user is responsible for having a lawful basis for any personal data of third parties included in deposited content and declarations.

13.11 Repeated API requests (idempotency keys). For the API requests for which the technical documentation provides it, the user's system may send an idempotency key that it chooses. Its use is optional: without it, each request is processed as a new request. For 7 days from the first request sent with a given key, a request repeated with the same key, through the same API key, to the same endpoint and with the same content is not executed a second time: the platform returns the outcome already recorded for that key or, if the first request is still in progress or was interrupted, processes it so that it takes effect only once. A request repeated with the same key but with different content, or to a different endpoint, is refused. After 7 days the key is no longer recognised, and a request sent with it is processed as a new request, which may create a new deposit. The user is responsible for generating the keys, for using a different key for each distinct request and for not including personal data or confidential information in them. Where an intake is deleted under Section 13.7, the outcome recorded for the keys that refer to it is replaced by a notice that the record no longer exists, which contains no data of the record; until the end of the 7-day period, a request repeated with such a key receives that notice and does not create a new deposit. This mechanism reduces the duplicates that may arise from repeating the same request within the limits described above; it does not guarantee that the platform will never hold more than one deposit relating to the same event, for example where the same event is sent with different keys, with different content, without a key or after the 7-day period, and it does not establish whether two deposits relate to the same event. A repeated request that returns the outcome already recorded does not create a deposit and is not counted as an additional intake; a deposit completed through a repeated request is counted once, when it is completed. Repeated requests remain subject to authentication, authorization and the request-rate limits of the plan. The technical records used for this purpose are not part of the evidentiary record and are described in the Privacy Policy.

Informatica in Azienda cannot be held liable for: indirect or consequential damages; loss of data caused by user actions; incorrect interpretations of evidentiary records by third parties; decisions made on the basis of EVIDE records by courts, regulators, or other parties; failure of evidentiary records to be admitted in any legal or administrative proceeding. Nothing in this section excludes or limits liability for wilful misconduct or gross negligence, or any liability that cannot be excluded or limited under applicable law. For consumers, the limitations of liability in this section and in Sections 2, 3, 4 and 9 apply only to the extent permitted by the Consumer Code and do not affect the consumer's statutory rights, including the legal guarantee of conformity.

These conditions are governed by Italian law. For any dispute with professional users, the Court of Bologna, Italy, has exclusive jurisdiction, except where mandatory law provides otherwise. For disputes with consumers, the competent court is that of the consumer's place of residence or domicile, where located in Italy. Consumers resident in another country retain the protection afforded to them by the mandatory provisions of the law of that country and by the applicable rules on jurisdiction.

16.1 Acceptance. These conditions apply from the moment the platform is first used. For API plans, they are expressly accepted when the API service is activated, and the accepted version is recorded. Other paid services are provided on the basis of a written request or order, for example by email, indicating the service and its price. For consumers, a contract for a paid service is concluded only with the consumer's express acceptance; before it is concluded, Informatica in Azienda provides the information required by the Consumer Code, and after it is concluded it sends confirmation of the contract on a durable medium.

16.2 Changes. Informatica in Azienda may update these conditions by giving at least 30 days' notice by email to the registered address; the notice indicates the new version and the date from which it applies. Where required by law or by the nature of the change, Informatica in Azienda will request renewed acceptance. A consumer who does not accept a change may terminate the contract free of charge before the change takes effect. Earlier versions of these conditions remain available on request. Each version of these conditions, together with the Privacy Policy in force from the same date, is also published as a PDF document bearing a qualified electronic signature, which can be downloaded from the page of these conditions with its SHA-256 fingerprint; once published, a signed copy is never replaced. The signed copy documents the content and the date of the version; acceptance is recorded as described in Section 16.1. A new version applies from its effective date and does not change acts already completed under an earlier version, such as deposits made, FEDIS documents issued or acceptances recorded; recorded acceptances of earlier versions remain unchanged. For users already registered on the publication date, a new version applies from the effective date stated in the notice. A contract concluded after the publication of a new version may expressly refer to it: in that case, that version applies to that contract from its conclusion. A function described in a new version can be used only from when it is available on the platform.

16.3 Right of withdrawal (consumers). A consumer who concludes a contract for a paid service at a distance may withdraw from it within 14 days of its conclusion, without giving any reason, by sending an unequivocal statement to info@informaticainazienda.it; the model withdrawal form provided by the Consumer Code may be used but is not mandatory. If the consumer has expressly requested that the service begin during the withdrawal period and then withdraws, the consumer pays an amount proportionate to the service provided until the withdrawal was communicated. The right of withdrawal is lost only if the service has been fully performed and performance began with the consumer's express prior consent and acknowledgement that the right would be lost once the contract had been fully performed. Amounts due to the consumer are refunded within 14 days of receipt of the withdrawal, using the same means of payment unless otherwise agreed.

16.4 Specific approval and unfair terms. Clauses that under applicable law require specific approval are effective only if approved in the form required by law. Clauses that are unfair under the Consumer Code do not bind consumers.