Version dated 16 September 2026. This page explains how history, memory, files, feedback, training, public sharing, connections, and data deletion differ in Cicora. It is read together with the Privacy Policy, Cookie Policy, Account Deletion page, and the Model and Policy Registry.
This page sets the data-control rules for settings available in a particular application, Workspace, model, and country. An available control is shown in the interface before the feature is enabled. Where a setting is not offered, data is handled under the Privacy Policy and the rule of the feature actually enabled.
1. Core principle: different data, different controls
The same conversation can contain Request Materials, technical records, a model choice, Workspace data, and order information at the same time. Deleting one object does not necessarily delete all others: for example, deleting a conversation does not cancel an accounting record for a completed request, and disconnecting an external connector does not withdraw data already lawfully sent to an external service. Cicora shows a control alongside its subject and explains the consequences before the action is confirmed.
| Object | Main way to control it | What the action usually changes | What does not change automatically |
|---|---|---|---|
| Profile and sign-in methods | Account settings or support request | contact details, password/session, language, basic preferences | order records required by law and Workspace data owned by an Organisation |
| Conversation history and projects | deletion/archive feature where available; rights request | the object's availability in the user interface and ordinary use | technical, billing, security, and backup data with a continuing lawful basis |
| Memory or saved instructions | a setting of the particular feature where available | future use of a saved item in the feature context | previously generated outputs, another user's actions, or content saved by an Organisation/link recipient |
| File | file/project deletion or rights request | ability to use the file in a future Cicora request | copies already transmitted to a selected provider or recipient while governed by that party's terms and law |
| Connected service | disconnection in Cicora settings and, where needed, with the external service | future Cicora access to a permission that can be withdrawn | data and actions already received or performed by the third-party service before disconnection |
| Public link | unshare/link removal | further delivery of the link by the Cicora interface | copies, screenshots, or recipient use outside Cicora |
| Marketing and optional cookies | unsubscribe, cookie settings, or separate consent | future optional messages/technologies | service notices, lawful retention of choice evidence, or processing completed before withdrawal |
| Entire Account | account-deletion procedure | Account access and ordinary processing of related personal data | data that must be retained for billing, security, dispute, law, or a corporate Workspace |
2. History, projects, memory, and personalisation
History is a user object that makes an earlier request and output available in the interface where that feature is enabled. Memory is a separate feature that can use a saved instruction, fact, or preference in later context. A cache is a technical mechanism for performance, a repeat operation, stability, or security. These concepts are not interchangeable.
Cicora does not treat all user text as permanent memory automatically. Where a saved-memory or personalisation setting is available, the interface states before it is enabled:
1. which data categories can be saved; 2. where the user can view, edit, or delete them; 3. whether the setting applies to one project, an Account, or a Workspace; 4. whether the saved item is sent to a Model Provider with a later request; and 5. how deletion of the item relates to technical cache and backups.
Turning off saved memory stops its future use in new requests within the feature actually implemented. It does not automatically delete previously created conversations, files, billing data, or information the user published personally. Separate actions apply to deleting history, a file, or an Account.
Where the interface offers a temporary, incognito, or ephemeral mode, it states before use the actual storage scope, history availability, permitted technical logs, Model Provider rules, and deletion process. Such a mode is available only through a clearly labelled feature. A temporary chat is not used for future personalisation and is not made available to other Workspace participants, except for exceptions expressly disclosed by law, security, or the selected Organisation.
3. Model training, service improvement, and feedback
As a baseline, Cicora uses private prompts, attachments, and outputs to provide, protect, and support its own service. RIZZ TRADE does not include them in training of its own general models, transmit them for third-party behavioural advertising, or change that rule silently through an interface or terms update.
A selected Model Provider can have its own retention, safety-review, feedback, training, or improvement modes. Before a request is sent, the user sees the applicable card in the Model and Policy Registry. If a user selects a route with a different data mode, Cicora discloses the difference before performance. Where law or a setting requires separate consent, the request is not sent until that action is received. General acceptance of the Terms, history, or cookies is not consent to model training.
Feedback differs from an ordinary conversation. A user may voluntarily submit a rating or error report. Cicora may then use the comment and context the user deliberately attached to correct an error, review security, or improve that particular feature. If feedback contains Personal Data, the Privacy Policy and data-subject rights apply. Rating one output does not create a right to use all Account materials for another purpose.
A separate research, evaluation, or training programme, if offered, is accompanied before activation by separate disclosure of its purpose, data categories, recipients, period, withdrawal method, effect on access to the core service, and restrictions of the selected model. Consent to that programme is obtained separately from this page and the Terms.
4. Files, media, and sensitive data
Before uploading a file, a user chooses whether it is needed for the task. Cicora may use the file, its technical properties, and needed context for request performance, compatibility, security, and support. Where a feature offers persistent file storage, a project, or a library, it shows how to find and delete the object. Where that feature is absent, the upload relates to the particular request and does not create a separate saved object.
An image, voice, video, health document, identity document, financial document, or other sensitive material can include information about the user or another person. The user must have the right, and where needed consent, to use it. A feature requiring special, biometric, or high-risk processing starts only after separate disclosure of the actual recipient, purpose, legal basis, and legally required choice. An ordinary media upload does not grant Cicora general permission to identify a person, clone an identity, perform biometric analysis, or retain that data.
Technical file checks can be used to the extent necessary to address malicious code, rule violations, security, or legal compliance. Such a check is not a guarantee that there is no risk, review of all material, or a replacement for the user's responsibility for the lawfulness of uploaded content.
5. Model Providers and route selection
A user can manage data through Account settings and selection of a model or tool. The reference directory helps locate published provider terms, but does not list every actual Cicora route. The selected feature separately discloses necessary request materials, material conditions for storage and use of data, security review, available settings, and applicable restrictions.
A model name alone does not determine a data mode. A route depends on availability, country, technical compatibility, selected feature, and provider restrictions. For automatic routing, its criteria and data consequences appear in the card/setting. If a switch materially changes data conditions, the user receives additional disclosure and makes a choice where required. If an agreed condition cannot be provided, Cicora rejects the request or offers a permissible alternative; material is not sent to an unagreed route.
A user may request information about the selected route, but Cicora does not disclose another party's secrets, vulnerabilities, access keys, or information whose disclosure would violate third-party rights, security, or law. This limitation does not remove the obligation to provide the data transparency required for the user.
6. Workspaces, administrators, and business data
In a Workspace, data rights can be allocated among the participant, Organisation, and its administrator. Before joining, a user sees that the Account is a work Account, who holds administrative powers, and what access to materials/metadata may be available within the role. An administrator does not acquire unlimited rights to a participant's personal Account merely because the participant uses a corporate email; the boundaries follow the actual Workspace connection, role, agreement, and law.
An Organisation may manage invitations, roles, access, budget, export, retention, and participant removal where the relevant feature exists and is disclosed. A user in that environment directs some requests concerning Organisation content to the administrator; Cicora does not give that user other participants' data or bypass the Organisation's lawful powers. The distinction between RIZZ TRADE acting as an independent controller and as a processor on an Organisation's instructions is described in the Business Data section.
7. Connected services and public sharing
Connecting a connector, third-party application, API, webhook, or external Account requires a separate action by a user or administrator. Before the connection, Cicora shows the permissions and data granted, how to disconnect it, and the rules applied by the external recipient. A user withdraws access in Cicora settings where available and, when needed, with the external service itself. Withdrawal applies to future access but does not undo lawfully completed actions or data already received by that external service.
When creating a public link, the interface shows the fact of publication and the scope of material made available. A user shares the link only with persons to whom the user may lawfully disclose the content. Removing or withdrawing a link stops its future availability through Cicora but does not delete independent recipient copies. If a public-link feature is unavailable, Cicora does not provide a path for that sharing.
8. Export, correction, and deletion
The right to export depends on applicable law and the feature actually available. Where a user has that right, Cicora provides an available format or considers the request under the Privacy Policy process. An export does not include another person's data, system secrets, security information, or data to which the user has no right. A corporate Workspace export can require participation by an administrator or Organisation.
A user can correct some data in Account settings. For other data, including Personal Data in Request Materials or an inaccurate output, contact support@cicora.ai. Correction does not mean Cicora can rewrite a third-party model's knowledge or remove a fact from an output already held by a recipient; we consider the available source object and explain the technical capability accurately.
Deletion of a conversation, file, or Account is described in the Account Deletion process. Before deleting an Account, a user should stop future renewals where possible, consider any needed export, and check the Workspace connection. Deletion is not automatically a waiver of a lawful refund and does not create a general right to a refund for unused access; those matters are governed by the Refund Rules.
9. Marketing, cookies, and rights requests
Marketing communications, optional analytics, and advertising technologies are not combined with acceptance of the Terms or processing necessary to perform a request. If Cicora offers marketing communications, consent or another applicable mechanism is provided separately, and each communication includes a clear way to unsubscribe. Service notices about an Account, security, an order, or a material change in conditions are not marketing communications.
Cookie and similar-technology settings are described on the Cookie page. A cookie choice does not replace a choice about a connected service, training, Workspace, or public link. To exercise rights, opt out of applicable targeted advertising/sale/sharing, withdraw consent, or make a complaint, contact support@cicora.ai; we apply the identity-verification and process described in the Privacy Policy.
10. Changes to controls
Cicora does not conceal a new processing purpose within an existing setting. Where history, memory, route selection, training, public sharing, external access, cookies, or retention changes, the interface and this page are updated before the change is enabled to the necessary extent. A material change requiring new consent or a separate choice does not apply merely because the user continues to use the service. Questions about data controls can be sent to support@cicora.ai and +998 90 051 48 40.