Classy privacy notice

Published 11 October 2026.

Scope and contact

This notice covers personal information processed for Classy and communications sent to Razumly about Classy. It does not cover the separate Razumly sports app or replace Atlassian's own privacy terms. Contact Razumly at support@razumly.com, or 2130 N Q St, Washougal, WA 98671, United States.

Customer content and responsibilities

Your organization decides which Jira or supplied text and classifier definitions to use with Classy. Razumly processes that customer-controlled information to provide the requested classification, configuration, publication, history and deletion functions. Your organization is responsible for its instructions, permissions, lawful basis and notices to people whose information it submits; it may itself act for another controller.

Classy uses external AI processing, as described below. Only submit information you are authorized to process with Atlassian, OpenRouter and TypeSafe. Do not submit secrets or sensitive information prohibited by the applicable agreement. Jira access permission or enabling an Automation action does not itself establish every person's consent or another legal basis. Classy does not automatically discover or redact personal information in free text.

Information and purposes

The sections below describe the source text, classifier definitions, account and lifecycle records, decision previews, publication records and linkable technical metadata used by Classy. This information supports the requested app functions, permission and replay controls, operational diagnostics, retention and account-privacy reporting. Publishing a classifier makes its selected definition available across the Jira site; it does not make private manual history site-wide.

If you contact support, your sender/contact information, message and any diagnostic details you choose to provide are used to handle the inquiry and related service, security or legal requirements. Do not email source content, passwords or API keys. Support correspondence is separate from seven-day manual History and is retained as needed to handle the inquiry and applicable recordkeeping or legal requirements; contact the notice address to request access, correction or deletion.

Roles and legal bases

For customer-controlled app information, Razumly acts on the customer's instructions and the customer determines the applicable lawful basis. For direct support correspondence and Razumly's own service-administration records, Razumly determines the handling needed for those purposes. Where a legal basis is required for that handling, the applicable basis is performance of a contract or requested pre-contract steps, legitimate interests in providing and securing the service and handling inquiries, or compliance with legal obligations, depending on the context. If particular processing relies on consent, it may be withdrawn for future processing without changing the lawfulness of earlier processing.

Recipients and international processing

Atlassian provides the Forge platform and Jira integration. OpenRouter routes inference requests to TypeSafe Jev and receives the invocation/session reference. The external-processing and supplier-information sections below identify the information sent and link to the suppliers' own documents. Customer-configured Jira Automation can also copy decisions to destinations chosen by the customer; those downstream uses are controlled by the customer's rule.

Information may be processed outside your country. Forge persistent storage follows the host Atlassian app's storage location; external inference uses OpenRouter's global endpoint. Supplier-published U.S. hosting descriptions do not establish a fixed country for every request or an app-wide regional-residency guarantee. This notice does not itself create a transfer mechanism or represent unresolved contractual safeguards as approved.

Retention, security and requests

The technical sections below distinguish seven-day manual-result visibility, daily cleanup, continuing draft/publication storage and separate Jira, supplier, diagnostic and platform-recovery copies. Uninstalling, clearing History and whole-owner erasure have different effects. None is a guarantee of immediate deletion of every external or backup copy.

Classy uses installation/owner-scoped storage, current-user Jira access, administrator authorization for manual owner erasure and server-side provider credentials. Explicit execution diagnostics omit raw source content and credentials but can contain linkable references. These measures do not promise absolute security, supplier compliance or a certification.

Depending on applicable law and the processing context, you may request access or a copy, correction, deletion, restriction or portability, object to processing, withdraw applicable consent or complain to a competent data-protection authority. Requests about customer-controlled content should ordinarily go to the organization controlling that content; Razumly can assist with Classy records within the applicable instructions and law. Contact support@razumly.com and identify the affected Jira site/account without sending sensitive content or credentials. Identity and authority may need verification. Classy does not provide a complete self-service export through its limited History view.

Changes

Changes to this notice will be published with the notice. Any additional notice required by an applicable agreement or law remains separate; this statement does not replace the selected DPA's notice obligations.

External AI processing

Classification sends source text, classifier question/instructions and category IDs, labels and matching descriptions to OpenRouter and TypeSafe (Jev), outside Atlassian. Classy uses the typesafe/jev-1.13 model through OpenRouter's Decisions API.

Issue classification: source text is the issue's summary and description, read with the invoking user's Jira permissions. Classy does not fetch comments or attachments for this action.
Text classification: source text is whatever you supply in the workbench or Automation action, including resolved smart values. Such input can include information about any person you mention.
Operational reference: OpenRouter also receives the Forge invocation reference as a session ID. Its Decisions contract describes this as observability metadata not forwarded to the model provider.

The provider request does not separately send the Jira issue key, classifier name or confidence threshold. Any of those details may nevertheless appear in free text; Classy does not automatically redact personal information from your content.

Every request requires no-data-collection and zero-data-retention routing. If the route cannot meet these filters, Classy does not weaken them, switch models or create a fallback decision. These are routing requirements, not a guarantee of supplier behavior or destruction of all copies.

OpenRouter account input/output logging and data-use settings are separate from request routing. Supplier operational metadata, permitted transient processing, security/abuse handling and legal-retention exceptions can remain. Disabling a setting does not erase previously retained data. Classy makes no app-wide regional-residency or Atlassian-only processing claim.

Only submit content you are authorized to process with these external services. Do not submit secrets or sensitive information, or use classification for decisions requiring guaranteed accuracy. Classy does not automatically redact your content.

What Classy stores and why

Classy app records use installation-scoped Forge-hosted storage. Data supports saved configuration, published Automation decisions, authorized manual history, replay protection, retention and erasure. No Classy-operated external app database is used in this implementation.

Private classifier drafts: Names, question/instructions, category IDs/labels/criteria/colors, confidence threshold and revision information, owned by your Atlassian account in this installation.
Published revisions: Immutable definition snapshots and lookup records. Publishing deliberately makes a revision selectable across the Jira site; it does not make your manual history site-wide.
Manual results: Source title, preview up to 240 characters, relevant Jira issue key/update metadata, classifier/revision references, category/probability snapshots, model, usage, timestamps and result references. There is no separate complete source-text field, but a title or short preview may itself contain personal information or the entirety of a short input.
Execution receipts: Manual replay identities, private request fingerprints, history/revision linkage and outcome references, not a second source-text or result copy. Native actions do not append private workbench history.
Owner and lifecycle records: The Atlassian account ID, oldest collection/reporting metadata, owner linkage and record counts needed to identify and erase that owner's records. Ordinary classifier deletion may leave a minimal linkable lifecycle record; whole-owner erasure removes it.
Retention and inference state: Cleanup progress/checkpoints and installation-wide concurrency/rate/shutoff state. Logical expiry of a reservation or timestamp is not immediate destruction of every old field.
Execution diagnostics: Invocation, installation and result references; stage/outcome/error class; timing; model; provider generation, usage and reported cost. Explicit execution records omit raw source, definitions, credentials and raw provider/error bodies, but their identifiers may remain linkable to an owner.

Account scopes and several fingerprints use SHA-256. Hashing supports linkage and equality checks; it is not an anonymity guarantee. Jira access is rechecked before successful issue results/outputs and when reading Jira-backed history.

Retention is not the same as visibility

Manual History: up to 50 recent results younger than seven rolling 24-hour UTC periods, measured from server creation time. Expired results are excluded immediately.
Physical app-storage cleanup: a daily worker removes expired results and then expired execution receipts in bounded background batches. Result deletion can lag expiry by roughly one day; failures can extend that lag.
Receipts: eligibility for cleanup is 168 hours after the later of admission and the execution identity's preparation time. Receipt retention does not extend a result's History lifetime.
Drafts and publications: no seven-day automatic expiry. Delete or unpublish deliberately; whole-owner erasure also covers them.
Logs, supplier records and platform recovery copies: controlled separately. A log query window, routing flag or empty History view is not a destruction deadline.

Jira administrators can inspect Result retention in Jira settings → Apps → Classy administration and resume interrupted cleanup. A cleanup error or overdue data requires attention; contact support if it persists. Classy does not offer a configurable custom retention period.

How to delete Classy data

Clear a classifier's manual history

Open the saved classifier's History and confirm Clear history. This removes retained results and receipts, including Jira results hidden by your current issue permissions, but keeps the classifier and published revisions. A run accepted before the clear cannot restore its old history afterward.

If the UI reports History cleanup pending, use Resume cleanup. That resumes the interrupted boundary without clearing a newer run. A local reset or empty table alone does not mean storage cleanup succeeded.

Unpublish or delete a classifier

Unpublishing removes the selected published snapshot from Classy. Deleting a classifier removes its private definition, results, receipts and publications with their lookup records. Rules pinned to a removed publication fail; update or disable them first.

Interrupted deletion stays fenced against new writes. Retry Delete classifier in its dialog, or reload and use Resume deletion under Pending deletions. Other classifiers remain usable. Ordinary classifier deletion is not whole-owner erasure.

Erase an account's records in this installation

Ask a current Jira administrator to open Classy administration → Owner data erasure for the correct Jira site/installation.
Enter the account's Owner account ID, select Inspect owner data and confirm the installation shown. Inspection does not run erasure; the target owner need not have an active session.
Confirm irreversible erasure, then select Erase owner data. It covers owned drafts, retained results, receipts, publications/indexes, lifecycle/owner records and matching retention checkpoint references, including records whose parent draft is missing.
If the result is erasing or the response is uncertain, inspect again and use Resume owner erasure. Completion requires the erase/resume receipt to report absent and zero remaining classifiers.

Whole-owner erasure is scoped to the selected account and installation. Other owners' records and other installations are not erased. It is not account suspension: a later deliberate session can create new data. Requests prepared before erasure may require a reload.

History clearing, deletion and administrator erasure are not blocked by the inference license check. If you cannot reach these controls, contact support@razumly.com and identify the affected Jira site without sending source text or credentials.

What Classy erasure cannot erase

Original Jira issues, rule configuration/audits and downstream writes or copies of decision outputs. Use Jira's own controls for those records.
Source/results already held in another open browser, screenshots or exports.
Forge diagnostic logs or any separate log export. Explicit content-free records can still contain linkable identifiers.
Provider-controlled content or metadata and lawful-retention exceptions. App-storage erasure is not evidence that OpenRouter or TypeSafe erased their copies.
Atlassian's soft-deleted/recovery and backup copies. Deletion is final from Classy's app-readable storage point of view, not an immediate platform-backup destruction guarantee.

Uninstalling is not the same as the in-app erasure procedure. Atlassian documents a 28-day hosted-storage retention period after uninstall and a 21-day recovery-request window. Its separate lifecycle guidance describes billing/trial-related access and platform-managed soft-deleted/backup disposal. Those periods describe different things; Classy does not combine them into a promised end-to-end deletion deadline.

See Atlassian's Forge-hosted data lifecycle and storage recovery guidance. If deletion is needed before uninstall, complete the applicable erasure procedure while Classy remains accessible.

Privacy and account requests

For account-record erasure, access or correction questions, contact your Jira administrator or support@razumly.com. State that the request concerns Classy and the affected Jira site/account; do not email sensitive source content, passwords or API keys.

Classy's daily maintenance and the administrator's Run cleanup now control queue due account reports without requiring the owner to be online. Reporting sends the registered Atlassian account ID and oldest collection time to Atlassian's Personal Data Reporting API. A successful no-change response sets the next reporting cycle; administrators can inspect Next personal data report under Owner data erasure.

The separate administrator reporting control uses the same policy. Accepted closed or updated responses trigger whole-owner erasure, including publications; rules bound to erased publications become unavailable. Reporting does not discover every person mentioned in free text or selectively redact their mentions from another owner's records.

Classy's technical deletion controls do not determine legal entitlement, establish a broader compliance certification or erase data held by Jira and external providers. Requests involving people mentioned in content need to identify the relevant records and processing context.

Supplier information

These are suppliers' own documents, not a Classy DPA, legal approval, certification or a per-request location guarantee: