Do you archive/delete old Confluence pages or keep everything for Rovo to have it "in context"?

[Mirek]

As more teams start using Rovo, I've been wondering whether our approach to Confluence content should change.

In the past, many of us tried to keep Confluence clean by archiving or deleting outdated pages. It made search results more relevant and reduced clutter.

Now I'm not so sure.

On one hand, outdated content can confuse users and AI if it isn't clearly marked. On the other hand, keeping historical documentation might give Rovo more context and help it provide better answers by understanding the evolution of projects, decisions, and processes.

I'm curious how other teams are approaching this.

Do you regularly archive or delete old Confluence pages?
Do you keep everything unless there is a compliance reason to remove it?
Have you changed your content strategy since adopting Rovo?
Have you noticed any difference in the quality of Rovo's answers depending on how much historical content is available?

I'd love to hear about your experience, best practices, or lessons learned.

[Roger Barnes]

I don't have a solution yet, but I can say with some confidence that not archiving and deleting is problematic, and doing something about it is high on my list. Rovo finds more stuff, spends more time (and tokens) trying to make sense of it and often pays attention to the wrong things. I believe too much of the wrong content is frequently more of an issue than the occasional regret of archived/deleted context being missed.

My hunch is the solution is multi-pronged, including:

• Rovo getting smarter about what to pay attention to. This could be in the form of improvements to baked in skills/prompts, better signals in the teamwork graph, or more ways for organisations and teams to provide hints. I'm confident this will happen with product improvements; meanwhile I'm encouraging folks to prompt more explicitly about where to look and what rudimentary signals to consider for the task at hand (eg updated recently, is it referenced, is it in a shared space)
• Pragmatic knowledge management
  • Doing pretty much what you're doing, archiving and deleting old content. The pragmatic part is the tasteful judgement applied to deciding what's useful historical context vs outdated, potentially misleading, or just expensive to chew on
  • Distillation and curation. Agents should be able to help compress knowledge over time, updating new knowledge, making what's still relevant more accessible, archiving old source material, keeping links to archived content for when it's needed, and keeping humans in the loop. The broader space of knowledge and context management with AI is fast moving but still messy.

I look forward to hearing more about what people are doing and what's working for them!

[MeghnaP_LogicLemur Labs]

I completely agree. I don't think the challenge is the amount of content, it's knowing which content can be trusted.

Historical pages are still valuable, but they shouldn't compete with the current source of truth. Simple signals like when a page was last reviewed, whether it has an owner, or if it's been superseded could help both people and Rovo make much better decisions.

I think content trust is going to become just as important as content search in the AI era.

[Andrea Robbins]

I think it depends on the content on the page. For example, if the content is no longer true, accurate or relevant, then archiving makes sense. However, if it is content that is more like lessons learned for projects or like PIRs for post-incident management, as long as they're still relevant, I think keeping those even if on the older side, will help provide Rovo context and content to have that full-picture. 

I feel like the more historical content available, it does take longer. For example, today I was asking a question about asset rest apis to get a single object, and I had a guide on how to use the import rest apis in my internal knowledge base. It had to read internal pages first even though they were related although it realized after a few seconds that it was not relevant at all. I guess it was not historical just related in the sense that the more pages you have the longer it will take.

[MeghnaP_LogicLemur Labs]

I don't think the question is whether we should keep or delete old pages anymore. It's whether people (and AI) can tell which content they should trust.

We've found that older pages still have a lot of value because they explain why decisions were made, even if they're no longer the current way of doing things. That context can be really helpful for Rovo.

The real problem starts when an old page looks just as relevant as one that was reviewed last week. Without any indication of freshness, it's hard for both people and AI to know which one should be treated as the source of truth.

For me, it's becoming less about cleaning up Confluence and more about making the status of content obvious. Knowing when a page was last reviewed, who owns it, and whether it's still considered or still trusted feels much more important in an AI-driven world.

[Andrei Eleodor Sirbu]

My philosophy is the past is the past, focus on the present and the future. 
This means up to date documentation reflecting current state of the projects. 
Historical information is contained in the issues in Jira if Rovo needs to access it. Comments inside issues explaining decisions taken etc. remain. 

Obsolete documentation is archived the deleted. I consider obsolete any piece of information which doesn't hold any valuable information about the project (whether its past state or current state) and only creates noise. 

I actually ask Rovo to audit Confluence spaces and give me a full plan for cleaning up spaces. It does a wonderful job in this respect. It retrieves the entire hierarchy of the space, finds duplicates, empty pages, pages with no readers and documentation which may be obsolete (I still need to check it visually myself to make sure it doesn't do mistakes here but it saves a lot of time). 

[Keyna Hendrickson]

Our company routinely faces document retention requirements, so it's baked in for us to create "archive" spaces where we file old documents. Any company working in a space that is heavily regulated should be keeping its documentation, even when the documentation is no longer relevant. You never know when you'll have to answer for why a situation was handled the way it was.  OP brings an even greater reason to light - context! However much it costs to store data, commit to it and create a document retention plan. It's better to have it and not need it, than need it and not have it.