Build1 distinct publisher3 min readUpdated
From 17 August, Jira and Confluence content trains Rovo by default. The content switch works on every plan; the metadata switch is greyed out below Enterprise, which makes governance a purchase.
The Engineer · Build desk

Compiled by The EngineerSomething wrong?How this is made
The part that stays on is the derived layer, and it repays reading item by item. According to Atlassian's data-contribution documentation, as summarised by dev.to, metadata contribution covers readability scores, task classifications (that a ticket is "sales work", for instance), story points, sprint end dates, SLA values, and semantic-similarity measures pulled from the Teamwork Graph [7]. None of that is anyone's prose. It is a working model of how an organisation estimates and where its estimates fail, and it is the layer an admin below Enterprise cannot switch off [5].
What the content setting covers is easy to picture: Confluence page titles and body text, Jira work-item titles, descriptions and comments, and custom status and workflow names [6]. That is material an admin can imagine reviewing. The metadata list is harder to picture and harder to audit, and it is the one that is locked [3].
So the escalation path for an admin who wants the derived signals to stop does not exist inside the admin console. Free, Standard and Premium are three of the four named plans, and none can reach a complete off state by configuration [13]. A Premium admin who flips every switch on offer is still contributing, and the remedy sits on the price list rather than in the settings page [15]. That moves a governance requirement into procurement, where the approver is different and the clock is a renewal cycle.
Credit where it is owed. The opt-out is real and documented, and the path is Atlassian Administration, then Security, then Data contribution [8]. Atlassian has said the collection feeds product improvement, and Rovo competes in a market where an assistant that knows your workspace beats a generic one [12]. Retention is bounded on paper too, with in-app data leaving the improvement datasets about 30 days after an opt-out and content attributes at about 90, retraining to follow [9].
The bound has a tail. Aggregated, de-identified data may persist for up to seven years [9], roughly 28 times the 90-day window that governs content attributes [14]. The short clocks apply to material Atlassian can still tie to a customer. The long clock applies to what it says it cannot.
The distribution of all this is the part worth arguing about. Non-admin users get no switch, and their data's fate is settled a level up by someone who first has to notice the change happened [10]. Set that against the tier matrix and the customer contributing the most by default is the one paying Atlassian the least [11]. That is not an artefact of engineering, per dev.to's reading; it is a decision about where privacy sits on the price list [11].
Follow any of these and your For You feed starts watching them — no settings page required.
Ranked by verification strength, evidence, and original report placement.
On the Free, Standard and Premium plans the metadata switch is greyed out; Atlassian's support page reads "You can't change this setting." The full off switch that also stops metadata contribution is available only on Enterprise.
Metadata contribution is on across all tiers and can only be switched off by Enterprise customers.
Retention is bounded on paper: after opting out, in-app data leaves the improvement datasets within about 30 days and content attributes within about 90, with retraining to follow, while aggregated, de-identified data may persist up to seven years.
From 17 August, by Atlassian's own account, content written into its Cloud products, including Confluence pages and Jira tickets, descriptions and comments, is used by default to train Rovo, Atlassian's AI assistant. The change was opt-out, not opt-in.
There are two separate data-contribution settings: one governing in-app data (the text itself) and one governing metadata (derived signals about that text).
In-app data contribution defaults to on for Free and Standard customers and off for Premium and Enterprise, and every tier can toggle that setting.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Specific and document-anchored, but single-publisher
The core factual spine is unusually concrete for a single-source cluster: a dated effective change, a named admin path, a per-tier control matrix, enumerated in-app and metadata categories, and numeric retention windows, all attributed to Atlassian's own documentation and support pages with one direct quote. What is missing is corroboration — Atlassian's documentation is not present in the cluster as its own item, no second outlet confirms the matrix, and no Atlassian statement was obtained directly.
Live by default; uptake and opt-out behaviour unmeasured
Adoption of the mechanism is structural rather than voluntary: the change is described as in force from 17 August and default-on for Free and Standard in-app data and for metadata on every tier, so exposure follows automatically from being an Atlassian Cloud tenant. But the cluster supplies no tenant counts, no seat numbers, no measurement of how many admins have opted out, and no evidence of Rovo usage or customer response, so breadth cannot be quantified beyond 'the default is running'.
Slightly overstated framing over well-specified facts
The substantive claims are close to what the documentation is said to say, and the article explicitly concedes the good-faith case: Atlassian shipped a documented opt-out, gave Premium and Enterprise a gentler default, and bounded retention. The mild overstatement is rhetorical and interpretive — 'privacy is now a plan tier' and the attribution of deliberate intent go beyond anything evidenced in the cluster, and the whole account rests on one publisher relaying vendor docs without a vendor response or any measured harm.
Vendor upsell and publisher-advocacy incentives both visible
Two incentive structures are legible in the material. Atlassian's is stated in the cluster: collection feeds product improvement and Rovo competes on understanding your workspace, while the one control that fully stops contribution sits on the most expensive tier, aligning governance demand with an upgrade path. The publisher's is visible in the item itself — a consumer-advocacy column that leads with the anti-consumer reading and cross-promotes companion pieces on unlearning and data leakage. Neither incentive is quantified in the cluster.
Actionable specifics, uncorroborated sourcing
Confidence is capped by structure, not by vagueness: one publisher, no primary Atlassian document or vendor response in the cluster, and no independent verification of the matrix or retention windows. It is lifted by the precision and checkability of what is asserted — a named admin path and quoted setting text an operator can confirm in minutes — and by the article's inclusion of counterarguments, which reduces the chance of one-sided error.
build
White-on-white PDF makes Atlassian's Rovo leak Jira and Confluence data; the org switch does not help1 distinct publisher
build
A NetworkPolicy in another repo broke invoicing while every dashboard reported success1 distinct publisher
build
A cleanup commit deleted the sanitizer. Five days later a scanner cashed it in.1 distinct publisher
build
The stability step is a branch, not a pipeline: inside one team's release-candidate discipline1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 23, 2026