Exploring the E3SM AI Platform and where Atlassian Rovo fits in

[tomvothecoder]

Overview

This discussion explores a shared E3SM AI Platform that provides unified access to distributed organizational, scientific, and operational knowledge. The platform would federate existing services where practical, curate authoritative E3SM content where necessary, and help AI applications produce more accurate, relevant, and traceable results.

Note: This document is an extension of the E3SM AI Platform: Strategy and Architecture Concept Notes.

Goals for the Shared E3SM AI Platform

The E3SM AI Platform aims to:

• provide shared AI capabilities across E3SM applications to reduce duplicative development
• provide unified access to distributed organizational, scientific, and operational knowledge
• reuse existing services where practical and curate E3SM knowledge in-house only where necessary
• standardize security, citations, provenance, evaluation, and observability
• preserve application-specific agents, workflows, permissions, and outputs

Organize E3SM Knowledge by Domains

E3SM knowledge spans multiple domains that can ground AI applications and improve answer accuracy, relevance, and traceability.

Knowledge should be organized by authority, freshness, and access pattern, rather than by technology. The diagram below shows the main knowledge domains, representative E3SM sources, and the appropriate access or management approach for each.

Some sources span domains. For example, active GitHub content may be queried through MCP, while released code and approved documentation may be indexed in the authoritative RAG layer.

Knowledge Domains by Use Case

Use case	Organizational and project knowledge	Authoritative scientific knowledge	Live operational data	Primary fit
E3SM-ASSIST chat assistant	Project decisions, Jira, Confluence, Slack, and meeting history	E3SM documentation, source code, diagnostics, and scientific guidance	Optional access to current simulations, jobs, or repository state	Domains 1 and 2
SimBoard AI Assistant	Optional troubleshooting history and related project decisions	Diagnostics definitions, interpretation guidance, and documentation	Simulation metadata, provenance, status, diagnostics, and comparisons	Domains 2 and 3
E3SM workflow configuration assistant, such as RRM	Optional prior decisions and design discussions	Validated configuration guidance, rules, examples, and source documentation	Environment checks, input availability, validation, and execution readiness	Domain 2, with Domain 3 for validation

The domains are not mutually exclusive. Each application should use only the knowledge sources required by its workflows.

Candidate Technologies

Knowledge domain	Candidate technologies
Organizational and project	Rovo, Confluence and Slack integrations
Authoritative scientific	E3SM-managed RAG, LlamaIndex, PostgreSQL/pgvector, curated GitHub and Read the Docs content
Live operational	SimBoard API, GitHub MCP, scheduler, diagnostics, and filesystem services

These are implementation candidates, not architectural commitments. A source may use different approaches depending on authority and freshness. For example, active GitHub content may be queried through MCP, while released code may be indexed as authoritative knowledge.

Rovo is evaluated separately in this discussion thread.

Overall Recommendation

Use a federated knowledge architecture:

• use Rovo for organizational knowledge and Atlassian-connected workflows
• use APIs or MCP for live operational data
• use an E3SM-managed RAG layer only for authoritative scientific content requiring curation, provenance, stable citations, or evaluation

Do not make Rovo a dependency of the initial SimBoard prototype. Add it only when Jira, Confluence, Slack, or other connected knowledge is required by the selected workflow.

[tomvothecoder]

Evaluation of Atlassian Rovo for the E3SM AI Platform

Overview

Rovo is a candidate service for the organizational and project knowledge domain. It could reduce custom development for accessing Jira, Confluence, Slack, and other connected enterprise content.

It should be evaluated as one component of a federated E3SM knowledge architecture, not as the foundation of the entire platform.

What is Rovo?

Atlassian Rovo is a managed enterprise AI service for searching connected knowledge, answering questions, and supporting agent workflows.

It provides:

• Search across Atlassian and connected content
• Chat for questions, summaries, and actions
• Agents for specialized workflows
• Studio for building agents and automations
• Connectors for external knowledge sources

The Atlassian Rovo MCP Server can expose supported Atlassian knowledge and tools to external applications such as SimBoard or E3SM-ASSIST.

Can Rovo Act as a Knowledge Base and RAG?

Functionally, yes. Rovo can connect, index, and retrieve organizational content to ground Search, Chat, and Agents.

However, it is an Atlassian-managed enterprise retrieval layer, not a fully controlled scientific RAG platform. E3SM would have limited control over retrieval behavior, scientific metadata, provenance, citation structure, versioning, and evaluation.

Strengths and Limitations

Strengths	Limitations
Rapid deployment with minimal custom infrastructure	Limited control over retrieval, ranking, citations, and evaluation
Strong Jira, Confluence, and permission integration	Custom sources may require connector development and synchronization
Effective for project documentation, issues, decisions, and discussions	Less suited to scientific provenance, versioning, and specialized metadata
Managed search, chat, and agents	Introduces Atlassian licensing, governance, and platform dependency
Can expose Atlassian context to external chatbots through MCP	Not every connected source should be assumed available through Rovo MCP

Rovo and Slack

Rovo supports Slack through:

• a Slack connector for permission-aware knowledge discovery
• a Rovo Slack app for chat, summaries, and agents inside Slack

Use Rovo for Slack knowledge discovery and user interaction. Use a direct Slack API or MCP integration for precise message operations, event-driven workflows, or Atlassian-independent access.

Proposed Fit

Rovo and connectors
  Jira, Confluence, Slack, project history,
  and selected enterprise documents

GitHub MCP
  Active repositories, pull requests,
  and repository-hosted documentation

SimBoard API/MCP
  Current simulation metadata and operational state

E3SM-managed RAG
  Authoritative scientific content requiring
  curation, provenance, stable citations, or evaluation

Recommendation

Use Rovo to minimize custom work for organizational and project knowledge.

Keep live operational data behind APIs or MCP services. Build an E3SM-managed RAG layer only for authoritative scientific content whose retrieval, provenance, citation, or evaluation requirements are not met by existing services.

Do not make Rovo a dependency of the initial SimBoard prototype unless Jira, Confluence, or Slack knowledge is required by the selected workflow.

[tomvothecoder]

Hey @chengzhuzhang, I would like to understand the target audience and knowledge domain the E3SM AI Assistant (E3SM-ASSIST) should cover. This will help me narrow down candidate tools and technologies required for different E3SM applications, including SimBoard.

I’ve categorized E3SM knowledge by three domains. Is the vision that E3SM-ASSIST will be a chatbot that covers primarily domains 1 and 2? More context provided in the original post above.

1. Organizational and Project Knowledge – project docs, discussions, issues, decisions, and collaboration history.
2. Authoritative Scientific Knowledge – trusted version controlled scientific content with provenance and stable citations (e.g., versioned docs, versioned E3SM releases, diagnostic definitions, validated examples)
3. Live Operational Data – current system state and operational data that changes frequently (e.g., SimBoard metadata, active repos, job status, filesystem status)