RCARS — Overview¶
What is RCARS?¶
RCARS (RHDP Content Advisory & Recommendation System) is an AI-powered platform for managing Red Hat Demo Platform catalog content. It reads every lab and demo in the RHDP catalog, understands what each one teaches, and uses that understanding to help teams find the right content, detect duplicate material, and identify items that should be retired.
Ask it a question in plain English — "what should we show at a developer-focused Kubernetes conference?" — and it returns a ranked list of catalog items that fit, each with a rationale. But RCARS has grown beyond recommendations into a broader content intelligence system: it tracks infrastructure metadata, detects content overlap, imports usage and sales data from the RHDP reporting system, and scores items for retirement.
The Problem It Solves¶
The Red Hat Demo Platform catalog contains hundreds of demos and workshop labs across every Red Hat product line. Several problems compound at this scale:
Finding the right content requires knowing the catalog well. New team members don't know what exists. Even experienced people miss content outside their product area. Events get staffed with familiar demos rather than the best-fit ones.
Duplicate content accumulates as different teams build labs that cover the same material under different names and structures. Without a way to detect semantic overlap, the catalog grows without bounds.
Stale content lingers after products evolve. Items that were once popular may no longer reflect current products or drive meaningful sales. Without data-driven performance analysis, these items consume infrastructure resources and confuse content selectors.
RCARS addresses all three by reading the actual lab content — not just titles and descriptions — and combining that understanding with usage, sales, and infrastructure data from the broader RHDP ecosystem.
How It Works¶
Content Ingestion¶
RCARS reads the live RHDP catalog directly from the Babylon platform's Kubernetes CRDs. For every catalog item with a Showroom (lab content repository), it clones the repo, reads the AsciiDoc modules, and sends the content to Claude Sonnet for structured analysis: what the lab covers, learning objectives, audience, duration estimate, and format suitability. The analysis is stored alongside 768-dimensional vector embeddings (via a dedicated vLLM embedding server) that capture the semantic meaning of each piece of content.
For AgnosticD v2 items, RCARS also extracts infrastructure metadata — cloud provider, OCP version, installed workloads — from the catalog CRDs. Separately, RCARS scans the AgnosticD v2 source repositories directly, reading the Ansible code for each workload role and base config, and uses an LLM to determine what each one installs, provisions, or configures. The results are stored in a searchable infrastructure catalog with vector embeddings, so you can ask "what workload deploys OpenShift AI?" and get an answer.
Recommendations¶
When someone asks a question, RCARS runs a three-phase pipeline:
- Vector search — the query is embedded and compared against stored content embeddings using pgvector cosine similarity
- Haiku triage — a fast AI model scores each candidate for relevance and filters poor matches
- Sonnet rationale — the top candidates get structured rationales: why it fits, how to use it, suggested format, caveats
The pipeline supports event URL parsing (paste a conference URL, get matched content), duration-aware reranking, and acronym expansion for Red Hat product abbreviations.
Content Overlap Detection¶
RCARS compares lab embeddings against each other to find catalog items that teach substantially the same material. This is a curator tool for identifying duplicates — items with 85%+ cosine similarity are flagged as near-duplicates, and 75-84% as related content worth reviewing. Comparisons are scoped by stage (prod vs prod only).
Performance Analysis¶
RCARS imports provision counts, sales pipeline data, closed revenue, and infrastructure cost from the RHDP reporting database (the same source as the SuperSet management dashboard). It uses this data to score each production item for performance on a percentile basis — items in the top tier for usage, pipeline, and revenue relative to their peers score highest.
The performance dashboard has two views: Prod Performance (scored table for items with production deployments) and Without Prod (age-based list of dev/event-only items that haven't been promoted). These metrics help people identify candidates; scores do not approve retirement automatically.
Retirement¶
The Retirement System records curator recommendations and supporting metrics, then lets admins manage owner notification, Jira linkage, and AgnosticV notice/removal PRs. A nightly sweep opens due removal PRs and reconciles merged removal or cancellation-revert PRs. Humans still review and merge every catalog change. The Retirement report brings recommended, in-progress, and retired items together, while the shared workflow drawer is also available from Performance and Non-Prod Items.
Catalog Preservation (Soft-Delete)¶
When catalog items disappear from the Babylon platform — whether they've been retired by content owners, removed during cleanup, or reorganized — RCARS preserves them instead of deleting them. Removed items are marked with a retired_at timestamp rather than purged. Showroom analysis, vector embeddings, workload mappings, and curator notes survive. Derived reporting metrics may be refreshed or cleaned up; the retirement approval snapshot preserves the metrics used for the decision.
This makes RCARS the institutional memory for the RHDP catalog. Curators can find retired items, see when they were removed, review their historical performance data, and recover the AgnosticV config path if they need to bring an item back. If an item reappears in Babylon (re-published after a fix, or restored from a different namespace), RCARS automatically un-retires it and all its data is immediately active again.
Nightly Maintenance¶
A nightly pipeline runs at 04:00 UTC. It runs Babylon catalog/content/reporting maintenance, portfolio-architecture sync, and then the retirement sweep when GitHub App integration is configured. The sub-pipelines are isolated so a failure in one does not prevent the next from being attempted. See Operations for scheduling and monitoring.
Who Uses It¶
Field teams and event staff use the Advisor to find content for events, booths, and customer conversations. The interface is a two-pane layout: conversation on the left, recommendation cards on the right. Follow-up queries refine results. No training required.
Content curators use Browse to review catalog items, tag content, set duration estimates, and mark best-fit recommendations. Content Analysis provides overlap detection (which labs duplicate each other?) and performance scoring (which items are driving impact, and which should we sunset?).
Platform admins use the Admin pages and CLI to monitor catalog health, trigger scans, track LLM token usage, and review query history.
Publishing House (the RHDP content management system) calls RCARS APIs to check content overlap during intake and search by infrastructure characteristics.
What It Runs On¶
RCARS runs on OpenShift as four deployments: a React frontend (PatternFly 6), a FastAPI API, and two arq background workers (scan and recommend, split to prevent bulk operations from blocking user queries). It is backed by PostgreSQL with pgvector for semantic search and Redis for job queuing and SSE streaming.
LLM calls use LiteMaaS (Red Hat's internal AI service) as the primary provider with Vertex AI as an automatic fallback. Two models: Sonnet for content analysis, rationale, and chat answers; Haiku for triage, workload scanning, and chat routing.
Reporting data is imported from the RHDP reporting MCP server, which provides access to the same provisions_summary materialized view that powers the SuperSet management dashboard.
Access is controlled through OpenShift's OAuth proxy with Red Hat SSO, with three role tiers: viewer, curator, and admin.
A Note on the Name¶
RCARS is a nod to LCARS — the Library Computer Access and Retrieval System, the fictional computer interface from Star Trek. The name borrows the acronym structure from a system that is, at its core, a library computer: you ask it what you need, it tells you where to find it. The frontend was redesigned with PatternFly 6 for modern accessibility and Red Hat design standards, but the name stuck.