JQL Contract Tests
by ProfitSignal Labs

JQL Contract Tests — customer terms and processing agreement

Version 1.0 — 1 October 2026.

Agreement

For orders made through Atlassian Marketplace, the agreement consists of the Bonterms Standard End User Agreement (Version 1.0), unmodified, together with the Provider-Specific Terms and attachments below. It takes effect between the customer and the provider upon the customer's first order as provided in that standard agreement. This page does not itself accept an order or establish that the app is available for sale.

Standard agreement: https://www.atlassian.com/it/licensing/marketplace/end-user-agreement-v1

Provider-Specific Terms

Provider and product. Provider is Jon Ander Irazusta Iribar, trading as ProfitSignal Labs. Product is JQL Contract Tests for Jira. Legal notices may be sent to support@profitsignallabs.dev and the address in the Legal Notice.

Governing law. Spanish law applies, without excluding protections or jurisdiction rules that cannot lawfully be excluded. For disputes between businesses, the agreed courts are those of Donostia–San Sebastián, Spain.

Permitted use and documented limits. The Product checks expected membership of Jira filters or literal candidate queries without editing filters or issues. It supports ten contracts per project, fifty reference IDs per contract, 8,000-character queries, up to 1,000 visible matches per scan and 128 immutable configuration revisions. Source operations share a 150-call, 20-second budget; comparisons and history may reach the budget earlier. Reports expire after one minute. These are safety bounds, not throughput or availability guarantees. The interface is in English. No automated monitor, alerts, general test platform or Jira writes are included.

Review signals. PASS and FAIL describe tested expectations under the current user and observed read times. Query errors, incomplete coverage, denied access and detected source changes do not establish a successful check. Comparing queries covers common tested references only. Relative dates, currentUser(), permissions, indexing and data changes can alter membership without a filter edit. No atomic snapshot, causal attribution or compliance verdict is promised. Customers remain responsible for native filters and operational decisions.

Attachments. The published product setup guide is the Documentation. The Support Policy and Security Measures below apply. The Data Processing Agreement below applies to Customer Personal Data processed on the customer's behalf. The Privacy Notice explains processing for the provider's own purposes and the service architecture. For personal-data processing, the DPA prevails over inconsistent terms to the extent required to protect that data.

Support and availability. No additional contractual uptime percentage is offered. Support response commitments must meet the Marketplace Partner Agreement: a response within 24 hours for requests identified by Atlassian as critical and within five business days for other requests. Response is not a promise of resolution within that time. This does not remove the obligations and remedies in the Standard Agreement or mandatory law.

Customer data use. The provider does not sell customer data, use it for advertising or use it to train AI models. The current app has no integration with an AI service.

Data Processing Agreement

Parties and scope. This DPA forms part of the Product agreement between the customer (controller, or processor acting for its controller) and the provider (processor, or subprocessor respectively). It applies only to personal data processed on the customer's behalf through the Product and associated instructed support conducted through an agreed channel covered by this DPA. The general enquiries mailbox must not be used to transmit customer project records or personal data from Jira.

Instructions and purpose. The agreement, documented configuration and authorized use instruct the provider to read visible Jira query results, validate expectations, display/compare/export observations, store project-owned contracts and optional personal check metadata, operate the service and provide instructed support. Processing occurs only on documented instructions, including transfers, unless law requires otherwise. Where legally permitted, the provider informs the customer of such a requirement and instructions that appear to infringe data-protection law.

Details of processing. Operations include retrieval, validation, comparison, display, user-directed export and Forge storage. Transient data includes issue/project IDs, update times, filter JQL, parse results, search membership and permissions. Stored project-owned configuration contains names, filter IDs or literal JQL, reference issue IDs and expectations, optional count bounds, versions and save times. Query text and names may contain sensitive user-provided data. Optional personal history contains slot/suite version, PASS/FAIL, exact visible count, query/filter hashes and check/save/expiry times, with account-hashed keys. Real account ID and oldest retained time are stored for Atlassian personal-data reporting. Personal records expire logically after 30 days using platform TTL; registry and erasure markers last at most 31 days. Configurations do not expire automatically; minimal erased-version markers remain. Source issue values, descriptions, comments, names/emails and membership snapshots are not retained. Data subjects may include staff, contractors and people referenced in query text. Special-category and criminal-conviction data is not required.

Confidentiality and security. The provider will ensure that persons authorized to process the data are subject to confidentiality obligations and will implement appropriate technical and organizational measures, considering the processing risks. The Security Measures below describe this release. Customer instructions do not authorize weakening those measures. The provider remains responsible for its applicable obligations even where the infrastructure is supplied by a third party.

Subprocessors. The customer authorizes Atlassian, acting under the Forge Terms and Forge Data Processing Addendum, to provide Forge runtime and platform operations. This is the current subprocessor register for the Product. The applicable Atlassian contracting entity and its onward subprocessors are identified in those documents and Atlassian’s published subprocessor list. No separate email provider is authorized by this DPA to receive customer project records; any additional support channel requires its providers and safeguards to be disclosed and covered before such records are accepted. The provider will impose applicable equivalent data-protection obligations on subprocessors and remains responsible as required by law. Additional direct subprocessors will be notified at least 30 days before processing begins, allowing the customer to raise a reasonable data-protection objection. The parties will seek a reasonable resolution before the new subprocessor processes that customer's data; unresolved objections require an agreed alternative or termination of the affected service under the agreement.

Assistance. Taking account of the nature of processing and information available, the provider will assist with data-subject requests and the customer's obligations concerning security, breach notification, impact assessments and consultation with authorities. It will forward requests concerning customer-controlled data and will not independently answer them except on instructions or where law requires.

Personal-data breaches. The provider will notify the customer without undue delay after becoming aware of a personal-data breach affecting the customer's data. Available information will include the nature and scope, affected categories, likely consequences, contact point, and mitigation taken or proposed. Information can be supplied in stages as investigation progresses. This does not transfer the customer's independent statutory notification responsibilities.

Return and deletion. At the customer’s choice, the provider will return or delete customer personal data at the end of service unless law requires retention. Source Jira records and exported reports remain customer-controlled. Users can erase their own personal checks; project administrators can erase configuration in bounded batches. Minimal version markers prevent stale writes. Inaccessible records require an authenticated support process and paused use during cleanup. Manual erasure hides prior personal checks using a deletion watermark; two empty queries at least one minute apart confirm cleanup, and new saves wait until that confirmation. Forge retains hosted storage for 28 days after uninstall; reinstalling does not automatically restore it. Platform TTL and backups may lag logical deletion; immediate physical backup erasure is not promised.

Verification. The provider will make available information needed to demonstrate compliance and allow and contribute to audits and inspections by the customer or its mandated independent auditor, subject to reasonable confidentiality and security arrangements that do not prevent statutory rights. The parties will use available documentation first where appropriate. Audit access must not disclose another customer's data.

International transfers. Transfers must use a mechanism permitted by applicable law. Atlassian's applicable Forge DPA and transfer provisions must be in effect for its processing. The Forge DPA includes the applicable Standard Contractual Clauses. This agreement does not itself authorize a new recipient or create a transfer mechanism by merely mentioning one.

Security Measures and Support Policy

An hourly bounded privacy-maintenance function reports only account IDs and oldest retained data times to Atlassian, follows its reporting interval, and handles requested erasure. It does not scan Jira. Personal history reads and saves fail closed when privacy maintenance is overdue or erasure is pending.

The Product runs on Atlassian Forge. Jira reads use the requesting user’s current authorization. Backend entitlement checks protect production. Project administrator checks protect contract configuration changes. Conditional immutable writes reject version conflicts. Fresh source and configuration rechecks precede results and exports. Forge-hosted storage is scoped to each installation. Saved configuration and personal history are described in the Privacy Notice.

The app declares no external network destinations, scheduled scans, AI integration or issue-write permissions. The provider does not deliberately log issue content, queries, names or account identifiers. Bounded queries limit work per request. These statements describe implemented controls, not independent audit certification or a claim that all attacks have been ruled out.

Support: support@profitsignallabs.dev. Support follows the Marketplace Partner Agreement's response commitments: 24 hours for requests Atlassian identifies as critical and five business days for other requests. These are response deadlines, not guaranteed resolution times; no additional uptime percentage is promised. Send sanitized reproduction steps and approximate time. Security reports should omit exploit details or sensitive records until a safe exchange method is agreed. No public bug-bounty payment commitment is offered.

Start support requests with the action, time and a sanitized error message. Do not send project exports, issue summaries, account identifiers, credentials or customer records to the general mailbox. If a request requires customer data, a covered channel and minimal scope will be agreed first. Requests for access, return or erasure begin with minimal identifying information; no password or API token is required.

Subprocessor and platform references

Forge hosted storage holds versioned configuration, reference issue identifiers and optional personal check metadata. History has a 30-day logical lifetime; platform TTL deletion may lag. Configuration revisions have no automatic expiry. Platform log and infrastructure retention policies apply. Clearing a result, deleting history or uninstalling does not delete Jira records or user-exported reports.