utkarshp845 · utkarshp845 · Jul 21, 2026 · Jul 21, 2026
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -1,6 +1,6 @@
 # Contributing
 
-Thanks for helping improve AIOps Lab.
+Thanks for helping improve Reliability Lab.
 
 The main rule is simple: keep the project beginner-friendly without making it shallow. A new feature should teach a real AI infrastructure concept at the right time.
 
@@ -49,4 +49,3 @@ In your PR, include:
 - Why it belongs in the learning path.
 - How you tested it.
 - Any tradeoffs or follow-up work.
-
diff --git a/LICENSE b/LICENSE
@@ -1,6 +1,6 @@
 MIT License
 
-Copyright (c) 2026 AIOps Lab contributors
+Copyright (c) 2026 Reliability Lab contributors
 
 Permission is hereby granted, free of charge, to any person obtaining a copy
 of this software and associated documentation files (the "Software"), to deal
@@ -19,4 +19,3 @@ AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
 LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
 OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
 SOFTWARE.
-
diff --git a/README.md b/README.md
@@ -1,8 +1,8 @@
-# AIOps-Lab
+# Reliability Lab
 
 Simple first. Production-minded always.
 
-AIOps Lab is a practical learning lab for AI infrastructure. It starts with a normal web service, adds logs and metrics, then uses an AI SRE Assistant to explain what is happening operationally.
+Reliability Lab is a practical learning lab for AI infrastructure. It starts with a normal web service, adds logs and metrics, then uses an AI SRE Assistant to explain what is happening operationally.
 
 The first version runs on a normal laptop. No GPU, Kubernetes, vLLM, Triton, Ray, KServe, or full MLOps platform is required on Day 1.
 
@@ -41,8 +41,8 @@ The AI assistant does not need an LLM key to work. If no provider is configured,
 ## Quickstart
 
 ```bash
-git clone https://github.com/utkarshp845/AIOps-Lab.git
-cd AIOps-Lab
+git clone https://github.com/utkarshp845/Reliability-Lab.git
+cd Reliability-Lab
 cp .env.example .env
 make up
 make test
@@ -126,7 +126,7 @@ curl -s -X POST http://localhost:8001/summarize-incident \
 ## Repository Structure
 
 ```text
-AIOps-Lab/
+Reliability-Lab/
   apps/
     demo-service/        # FastAPI app that emits health, failure, latency, logs, and metrics
     ai-sre-assistant/    # FastAPI app and CLI that analyze demo-service logs

diff --git a/SECURITY.md b/SECURITY.md
@@ -1,6 +1,6 @@
 # Security Policy
 
-AIOps Lab is a learning project, but security issues still matter.
+Reliability Lab is a learning project, but security issues still matter.
 
 This repo intentionally starts local and simple. Please do not treat the default Docker Compose or kind setup as production-ready.
 

diff --git a/docs/00-overview.md b/docs/00-overview.md
@@ -1,6 +1,6 @@
 # Overview
 
-AIOps Lab teaches AI infrastructure by starting with the parts every production engineer already understands: services, logs, health checks, metrics, containers, and operational debugging.
+Reliability Lab teaches AI infrastructure by starting with the parts every production engineer already understands: services, logs, health checks, metrics, containers, and operational debugging.
 
 The AI part is introduced as an assistant that observes a service, not as a giant platform on Day 1.
 
@@ -24,4 +24,3 @@ The AI part is introduced as an assistant that observes a service, not as a gian
 - Optional OpenAI-compatible LLM integration.
 - Docker Compose.
 - Tests and CI.
-
diff --git a/docs/14-kubernetes-production-next-steps.md b/docs/14-kubernetes-production-next-steps.md
@@ -1,6 +1,6 @@
 # Kubernetes Production Next Steps
 
-Week 3 Day 7 closes the first Kubernetes chapter of AIOps Lab.
+Week 3 Day 7 closes the first Kubernetes chapter of Reliability Lab.
 
 The local kind setup now teaches the core mapping:
 

diff --git a/docs/18-production-observability.md b/docs/18-production-observability.md
@@ -1,6 +1,6 @@
 # Production Observability Upgrade Path
 
-Week 4, Day 5 maps the local AIOps Lab signals to a production-minded observability system.
+Week 4, Day 5 maps the local Reliability Lab signals to a production-minded observability system.
 
 The current setup is intentionally small: `demo-service` writes structured logs to a shared file, exposes Prometheus-style metrics, and the AI SRE Assistant reads that evidence directly. Production changes the transport, storage, access, and operating model. It should not change the core reasoning pattern:
 
@@ -154,7 +154,7 @@ Send collector output to a managed observability platform. This reduces backend
 
 Keep OpenTelemetry at the collection boundary and choose different backends by environment or signal type. This preserves portability while allowing managed services where they reduce meaningful toil.
 
-The default AIOps Lab setup should remain dependency-light. A production stack belongs in an optional deployment path after the signals and ownership model are understood.
+The default Reliability Lab setup should remain dependency-light. A production stack belongs in an optional deployment path after the signals and ownership model are understood.
 
 ## Staged Migration
 

diff --git a/docs/19-advanced-model-serving-roadmap.md b/docs/19-advanced-model-serving-roadmap.md
@@ -1,6 +1,6 @@
 # Advanced Model Serving Roadmap
 
-Week 4, Day 6 defines when AIOps Lab should move beyond external model providers and which serving layer should solve each production problem.
+Week 4, Day 6 defines when Reliability Lab should move beyond external model providers and which serving layer should solve each production problem.
 
 The project does not need GPUs or a self-hosted model to remain useful. The deterministic analyzer and optional OpenAI-compatible provider path should stay the default until customer requirements or measured workload economics justify more infrastructure.
 
@@ -37,7 +37,7 @@ Do not self-host because GPU infrastructure looks impressive. Low utilization, u
 
 ```mermaid
 flowchart LR
-    product["AIOps Lab API and policy layer"] --> gateway["authenticated model gateway"]
+    product["Reliability Lab API and policy layer"] --> gateway["authenticated model gateway"]
     gateway --> engine["inference engine such as vLLM or Triton"]
     gateway --> appserve["distributed application serving when needed"]
     appserve --> engine
@@ -51,7 +51,7 @@ flowchart LR
     platform --> telemetry
 ```
 
-The AIOps Lab API remains the product boundary. It owns evidence access, redaction, evaluation, policy, quotas, auditability, and user workflows. Serving frameworks provide model execution and orchestration underneath that boundary.
+The Reliability Lab API remains the product boundary. It owns evidence access, redaction, evaluation, policy, quotas, auditability, and user workflows. Serving frameworks provide model execution and orchestration underneath that boundary.
 
 ## What Each Tool Solves
 
@@ -167,7 +167,7 @@ A private deployment is not automatically secure. It only changes who owns the c
 
 ## Monetization Possibilities
 
-The serving engine should not be the product moat. Open-source inference projects will continue to improve. AIOps Lab can monetize the operational and governance layer that customers repeatedly need.
+The serving engine should not be the product moat. Open-source inference projects will continue to improve. Reliability Lab can monetize the operational and governance layer that customers repeatedly need.
 
 | Possible tier | User outcome | Potential paid capabilities |
 | --- | --- | --- |
@@ -205,7 +205,7 @@ Before committing to a serving platform, require:
 
 ## Day 6 Definition Of Done
 
-- The default AIOps Lab path still requires no GPU.
+- The default Reliability Lab path still requires no GPU.
 - Each advanced tool maps to a specific problem and adoption gate.
 - Provider and self-hosted options use the same evaluation standard.
 - GPU cost is compared per successful analysis, including operations.

diff --git a/docs/20-production-readiness-review.md b/docs/20-production-readiness-review.md
@@ -1,6 +1,6 @@
 # Production Readiness Review
 
-Week 4, Day 7 closes the first AIOps Lab learning cycle with an explicit release decision.
+Week 4, Day 7 closes the first Reliability Lab learning cycle with an explicit release decision.
 
 The project now demonstrates a complete local path from application signals to evidence-grounded incident analysis. That makes it ready to publish as a learning lab. It does not make the current Docker Compose or kind configuration ready for internet-facing production use.
 

diff --git a/docs/21-commercialization-roadmap.md b/docs/21-commercialization-roadmap.md
@@ -6,7 +6,7 @@ The strategy is deliberate: audience first, wedge product second, paid tiers thi
 
 ## Strategy Summary
 
-The AI incident-copilot market is crowded with well-funded products. AIOps Lab does not win by out-building them from a standing start. It wins by:
+The AI incident-copilot market is crowded with well-funded products. Reliability Lab does not win by out-building them from a standing start. It wins by:
 
 1. Teaching an underserved audience (production engineers new to AI infra) and earning distribution through the open learning lab.
 2. Converting that audience into customer discovery for a narrow wedge: an evidence-grounded incident analyst whose quality is enforced by a CI evaluation gate.

diff --git a/docs/build-log.md b/docs/build-log.md
@@ -2,7 +2,7 @@
 
 ## Day 1 - Simple First, Production-Minded Always
 
-I am building AIOps Lab because AI infrastructure is becoming part of normal software infrastructure, but the learning path often starts too late in the stack.
+I am building Reliability Lab because AI infrastructure is becoming part of normal software infrastructure, but the learning path often starts too late in the stack.
 
 AI infra is intimidating because beginners are quickly surrounded by model serving frameworks, GPU scheduling, Kubernetes operators, distributed systems, observability, evals, and cost tradeoffs. Those topics matter, but they do not need to arrive all at once.
 
@@ -542,7 +542,7 @@ What comes next:
 
 ## Week 4, Day 5 - Production Observability Upgrade Path
 
-Today I mapped the local AIOps Lab signals to a production observability architecture.
+Today I mapped the local Reliability Lab signals to a production observability architecture.
 
 Day 4 made assistant quality testable. Day 5 asks how teams can operate, govern, and measure the service once logs and metrics no longer live on one laptop.
 
@@ -582,7 +582,7 @@ What comes next:
 
 ## Week 4, Day 6 - Advanced Model Serving Roadmap
 
-Today I defined when AIOps Lab should move from managed model providers to self-hosted inference and how that decision can support a real product.
+Today I defined when Reliability Lab should move from managed model providers to self-hosted inference and how that decision can support a real product.
 
 Day 5 mapped the production observability path. Day 6 uses those quality, latency, usage, and cost signals to decide whether advanced serving infrastructure is justified.
 
@@ -649,7 +649,7 @@ Why this matters:
 
 Production readiness is not a feeling and it is not a list of tools. It is a decision backed by tests, measurable gates, clear ownership, and an honest account of unresolved risk.
 
-AIOps Lab is ready to ship as an open learning project when the validation gate passes. It is not yet an internet-facing multi-tenant production service, and the review says so explicitly. That boundary makes the project more credible, not less ambitious.
+Reliability Lab is ready to ship as an open learning project when the validation gate passes. It is not yet an internet-facing multi-tenant production service, and the review says so explicitly. That boundary makes the project more credible, not less ambitious.
 
 Lessons learned: