Working Day Guard — Provider-Specific Terms
Effective date: the date Working Day Guard is first published on the Atlassian Marketplace.
1. Parties, version and precedence
Provider is the individual in Japan identified in the final legal disclosure, trading as Rillnook Labs. These Terms take effect on the date stated above. The Product is Working Day Guard for Jira. These Provider-Specific Terms modify and attach to the Bonterms Standard End User Agreement (Version 1.0), made available by Atlassian. They are not an unmodified standard agreement.
The standard agreement is incorporated by reference rather than republished or altered. Its Sections 1.1–1.4 govern formation and ordering except for the explicit cross-Order aggregation below. Mandatory law and binding transfer clauses prevail; for data protection, the Customer DPA prevails over inconsistent Provider-Specific or standard terms. Otherwise a valid signed Amendment prevails, followed by these Provider-Specific Terms and their identified attachments, then the standard agreement. The Privacy notice does not enlarge processing instructions or diminish the DPA.
2. Product and support attachments
The Product asynchronously evaluates Jira's standard Due Date after save. OBSERVE records a proposed outcome without correction; ENFORCE may correct only after safety checks. It is not a pre-save validator, bulk repair service, real-time guarantee, or atomic compare-and-set. Uncertain freshness, permissions, settings causality or changed state can cause a safe skip.
The product guide, Support Policy, Security Measures and Customer DPA are the identified attachments. No uptime or fixed restoration SLA is offered under Section 5.2. Japanese human support follows the two-business-day acknowledgment rule in the Support Policy. Support scope does not remove remedies under Section 6.2.
3. Performance warranty, remedies and trial reconciliation
Section 6.2 remains applicable to paid Subscriptions, including its claim-notification condition, reasonable-efforts correction or workaround period, and termination/refund remedy where the defect is not remedied. A statement that support does not guarantee resolution time does not waive that warranty or excuse its remedies.
For Section 18, the existing internal-evaluation scope, evaluation duration, termination rights and absence of trial/beta performance warranty, indemnity and SLA remain. However, its exclusion of Support is replaced by the published Japanese Support Policy for Marketplace evaluations of the released Product. Its standalone US$1,000 liability limit is replaced entirely by Section 4 below, including its non-limitable exceptions. Security, confidentiality, DPA and mandatory-law duties are not waived for trials or free use.
4. Replacement liability allocation (standard Section 14)
This Section replaces Sections 14.1, 14.3 and 14.5 and overrides inconsistent liability language in Sections 15 and 18. Section 14.2's exclusion of indirect and consequential losses remains for ordinary claims only; it does not exclude the special or non-limitable claims below. Section 14.4 otherwise remains.
For each Customer and this Product, the General Cap (G) is the greater of US$100 and the total Product fees paid or payable by that Customer for the 12 months immediately before the first incident giving rise to any liability subject to these caps. Fees are measured gross of Marketplace commission, excluding taxes and unrelated products. For fees not denominated in USD, use the USD value in the corresponding Marketplace settlement/order records; if unavailable, use a mutually documented conversion at the measurement date, not a unilaterally selected rate.
The measurement date is fixed by that first incident, not by complaint, filing, renewal or judgment. It and the resulting G do not reset for a later Order, renewal, claimant theory or related claim. These limits aggregate separately for each liable party, across all Orders and Agreements for the same Customer and Product, including paid and free periods. This is an express qualification to Section 1.3; affiliates that are separate ordering Customers are not silently combined.
For ordinary claims, each party's cumulative liability is limited to G. For all capped claims combined, liability is limited to the Special Cap (S), the greater of 3 × G and US$1,000. Special claims are breaches of security obligations (including Section 3.2), the DPA (Section 3.3), confidentiality (Section 16, including Customer Data), either party's infringement or misappropriation of the other party's intellectual property, and indemnification obligations under Section 15.
General and Special Caps are not added together. Amounts paid for ordinary claims count toward both G and S; amounts paid for special claims count toward S. Splitting claims, Orders or legal theories does not create further caps. Once S is exhausted, no additional capped liability remains; ordinary claims can never exceed G.
Amounts within a covered indemnification obligation include defense costs, reasonable attorneys' fees, awarded amounts and approved settlements; they consume S and are not payable in addition to it. Section 15 procedures, control/consent rules, exclusions and mitigation rights otherwise remain. Exhaustion limits only the contractual obligation between Customer and Provider, not a third party's claim or a court's order.
Neither cap nor the consequential-loss exclusion applies to intentional misconduct, fraud, gross negligence, or liability which applicable law does not permit to be limited. These are the only Uncapped Claims replacing the definition in Section 14.5. A party's primary obligation to pay agreed fees and the express repayment of prepaid unused fees under Sections 6.2, 15.5 or 19.8 remain enforceable and are not reduced by these damages caps. Injunctive relief is not replaced by a monetary ceiling.
These terms allocate liability between the contracting parties only. They do not limit data-subject or other third-party rights, regulatory powers or penalties, Provider's own investigation/compliance costs, or obligations under separate Atlassian or other vendor agreements. They do not promise that every limitation is enforceable.
5. Data protection and permitted processing
The Customer DPA is incorporated under Section 3.3 for personal data processed on Customer's documented instructions. Section 3.4 does not authorize undisclosed analytics, advertising, AI training, external runtime transfer or new uses of Customer Data. Independent administration of the website and correspondence is described separately in the Privacy Policy.
Section 12.4(a)'s access/export provision during the Subscription Term is distinct from deletion. Under Section 12.4(b), after termination or expiration, deletion must be completed within 60 days after receipt of the request, not requested by Customer within 60 days of termination. Earlier mandatory or DPA deadlines prevail; routine 180/210-day correspondence retention cannot extend them. The DPA's return obligation has its own applicable deadline and is not converted into this deletion period.
The ordinary settings/audit view and project data controls are bounded by current authorization and visibility; a PARTIAL return is not complete customer fulfilment. The release candidate also implements a separate signed Jira-administrator workflow that traverses the managed storage catalog with explicit return-page acknowledgment and bounded deletion steps. Its actual scope and limits are stated in the DPA. Deployment, live-behavior, issuer authorization, legacy-data, log/backup and applicable-deadline gates must be satisfied before real instructed processing, including free trials. Existing-data duties survive even if new processing is stopped. A missing tool is not an exemption.
6. Governing law, forum and notices
Under Section 19.2, Japanese law applies without its conflict-of-laws rules. The Tokyo District Court or Tokyo Summary Court, according to subject-matter jurisdiction, is the exclusive agreed court of first instance. Mandatory protections and any controlling data-protection/transfer provisions, including their forum rights, are preserved.
Provider's ordinary contract contact is support@rillnook.com, privacy contact privacy@rillnook.com, and vulnerability contact security@rillnook.com. Section 19.3's notice requirements otherwise remain.
Operational changes follow Section 19.6 without retroactively extending existing response deadlines or materially reducing contractual obligations. Contract amendments require Section 19.5; merely editing this web page does not silently change an existing agreement.