Add day 2 use cases (#7)

* Added content for "The bad deploy" use case

* Added remaining four use cases as-is from Notion

* Adjusted headers and added righsizing content

* Putting emphasis on impact detection

* Changed CTA for use cases to match existing one

* Replaced scenario with neutral use case description

* Replaced scenario with neutral use case description for impact analysis

* Replaced scenario with neutral use case description for Infrastructure drift detection

* Replaced scenario with neutral use case description for rightsizing

* Replaced scenario with neutral use case description for rollback

* Editorial changes for clearer scoping

Author: TobiasBabin

day-2-operations/impact-analysis/README.md

@@ -0,0 +1,27 @@
+# Impact analysis
+
+The Platform Orchestrator can detect infrastructure drift on a resource level and pinpoint the impacted environments for a complete situation assessment.
+
+> ℹ️ **Note**
+> 
+> While we are preparing the full use case implementation, you can already see the Platform Orchestrator in action with your own technology stack. [Book a session with us here](https://humanitec.com/schedule-demo).
+
+Rollout management in the context of the Humanitec Platform Orchestrator enables platform teams to safely and efficiently propagate infrastructure changes, such as security patches or configuration updates, across multiple environments. When a misconfiguration is detected in a shared module (for example, a module provisioning S3 buckets with incorrect access controls), the Orchestrator provides the ability to immediately assess the scope and impact of the issue.
+
+The Orchestrator’s impact analysis tools allow teams to visualize which workloads and environments are currently using the affected module version. This includes detailed insights into which environments are at risk, which are unaffected, and which teams are responsible for each workload. With this visibility, platform teams can:
+
+- Identify all affected environments and workloads using the problematic module version
+- Understand the exact scope (blast radius) of required updates, reducing uncertainty and manual investigation
+- Plan and execute targeted rollouts or forced updates, minimizing disruption and ensuring compliance
+- Maintain a clear audit trail of changes and updates across the platform
+
+By leveraging these capabilities, the Platform Orchestrator ensures that updates can be rolled out in a controlled and transparent manner, reducing the risk of widespread outages and enabling rapid incident response. This approach eliminates the need for manual repository checks or guesswork, providing a single source of truth for infrastructure state and change management.
+
+## References
+
+- [Platform Orchestrator Documentation](https://developer.humanitec.com)
+- [Platform Orchestrator Terraform Modules](https://github.com/humanitec-tf-modules)
+
+<!-- BEGIN_TF_DOCS -->
+
+<!-- END_TF_DOCS -->

day-2-operations/impact-analysis/main.tf

@@ -0,0 +1 @@
+# Use case implementation being prepared

day-2-operations/infrastructure-drift/README.md

@@ -0,0 +1,22 @@
+# Infrastructure drift detection
+
+The Platform Orchestrator can remediate infrastructure drift by detecting resources having drift and re-aligning them with the desired state through a re-deployment.
+
+> ℹ️ **Note**
+> 
+> While we are preparing the full use case implementation, you can already see the Platform Orchestrator in action with your own technology stack. [Book a session with us here](https://humanitec.com/schedule-demo).
+
+Infrastructure drift occurs when the actual state of infrastructure resources diverges from the intended, declared configuration. This can result from manual changes, failed deployments, or external modifications. The Humanitec Platform Orchestrator is being developed to provide drift detection capabilities that continuously monitor infrastructure and help alert platform teams when such divergence is detected.
+
+Drift identified by the Orchestrator can be surfaced in the tool of your choice so you can notify teams, enabling them to quickly assess and remediate the issue. Remediation can be performed by re-deploying the environment, which realigns the actual state with the approved configuration. This approach helps maintain consistency and reliability across environments, and serves as a critical security feature by detecting unauthorized changes that could introduce vulnerabilities or compliance violations.
+
+The Orchestrator’s drift detection ensures that infrastructure remains aligned with organizational standards and policies, supporting operational efficiency and security objectives. Teams can remediate drift rapidly, ensuring their infrastructure stays consistent with the declared configuration through a simple re-deployment process.
+
+## References
+
+- [Platform Orchestrator Documentation](https://developer.humanitec.com)
+- [Platform Orchestrator Terraform Modules](https://github.com/humanitec-tf-modules)
+
+<!-- BEGIN_TF_DOCS -->
+
+<!-- END_TF_DOCS -->

day-2-operations/infrastructure-drift/main.tf

@@ -0,0 +1 @@
+# Use case implementation being prepared

day-2-operations/progressive-rollouts/README.md

@@ -0,0 +1,28 @@
+# Progressive rollouts
+
+The Platform Orchestrator can rollout infrastructure updates gradually across your estate in controlled waves, providing full rollout control and progress visibilty.
+
+> ℹ️ **Note**
+> 
+> While we are preparing the full use case implementation, you can already see the Platform Orchestrator in action with your own technology stack. [Book a session with us here](https://humanitec.com/schedule-demo).
+
+Platform teams need to evolve shared infrastructure components (such as database operators) without risking widespread outages. The Platform Orchestrator provides a controlled way to roll out new module versions across environments while limiting blast radius and preserving the ability to roll back quickly.
+
+A typical rollout starts by creating a new version of a module that encapsulates the updated infrastructure behavior (for example, a new Terraform/OpenTofu module version wired via the Orchestrator’s module catalog). The platform team then uses the Orchestrator to apply this version selectively across environments, following a staged progression rather than updating everything at once. Environments can be ordered from lowest-risk to highest-risk (for example, ephemeral and development environments first, then staging, then production), leveraging the Orchestrator’s project/environment structure and promotion capabilities.
+
+Each rollout “wave” is executed as a normal deployment, driven via CLI or CI/CD, which updates the resource graph and regenerates the Terraform/OpenTofu for that environment. Teams can use their existing observability stack (for example, metrics dashboards and alerts) to validate behavior after each wave before proceeding. If issues are detected, the Orchestrator’s rollback capabilities allow reverting a specific environment to a previous working deployment state, using the historic manifest and resource graph and the same module versions that were active at that time without affecting other environments still on older versions.
+
+This pattern enables:
+
+- **Fine-grained control of blast radius** by scoping changes to selected environments or subsets of workloads
+- **Progressive rollout** of new infrastructure versions across the estate, aligned with environment progression practices
+- **Safe experimentation and fast remediation**, through a combination of deployment history, rollback, and repeatable module-based configuration
+
+## References
+
+- [Platform Orchestrator Documentation](https://developer.humanitec.com)
+- [Platform Orchestrator Terraform Modules](https://github.com/humanitec-tf-modules)
+
+<!-- BEGIN_TF_DOCS -->
+
+<!-- END_TF_DOCS -->

day-2-operations/progressive-rollouts/main.tf

@@ -0,0 +1 @@
+# Use case implementation being prepared

day-2-operations/rightsizing/README.md

@@ -0,0 +1,22 @@
+# Rightsizing for cost control
+
+The Platform Orchestrator can assist in rightsizing infrastructure resources by applying more cost efficient configurations.
+
+> ℹ️ **Note**
+> 
+> While we are preparing the full use case implementation, you can already see the Platform Orchestrator in action with your own technology stack. [Book a session with us here](https://humanitec.com/schedule-demo).
+
+Organizations often encounter situations where infrastructure resources, such as databases, are over-provisioned relative to their actual workload requirements. This leads to unnecessary operational costs and inefficient resource utilization. The Humanitec Platform Orchestrator addresses this challenge by providing a centralized, rule-based orchestration layer that enables proactive rightsizing of resources for optimal cost control.
+
+Once underutilized or oversized resources are identified, teams can adjust resource parameters such as changing the size class of a database directly within the deployment manifest. The Orchestrator then enforces these changes across all relevant environments through the regular deployment cadence, ensuring that the updated configuration is applied consistently and securely.
+
+This dynamic configuration management approach not only streamlines the process of rightsizing resources but also enforces organizational standards and policies. By automating the rollout of configuration changes, the Orchestrator helps organizations maintain lean resource allocation, reduce costs, and prevent resource sprawl, all while maintaining compliance and operational efficiency. The ability to audit changes and track deployment history further supports governance and transparency in resource management.
+
+## References
+
+- [Platform Orchestrator Documentation](https://developer.humanitec.com)
+- [Platform Orchestrator Terraform Modules](https://github.com/humanitec-tf-modules)
+
+<!-- BEGIN_TF_DOCS -->
+
+<!-- END_TF_DOCS -->

day-2-operations/rightsizing/main.tf

@@ -0,0 +1 @@
+# Use case implementation being prepared

day-2-operations/rollback/README.md

@@ -0,0 +1,22 @@
+#  Rollback
+
+The Platform Orchestrator can remediate application or infrastructure issues introduced by faulty deployments by executing a rollback to a previous, stable configuration.
+
+> ℹ️ **Note**
+> 
+> While we are preparing the full use case implementation, you can already see the Platform Orchestrator in action with your own technology stack. [Book a session with us here](https://humanitec.com/schedule-demo).
+
+When a deployment causes instability in an application or its dependencies, the Platform Orchestrator allows teams to rapidly restore a previously known good state without manual reconstruction of configs or infrastructure.
+
+Using the Orchestrator’s deployment history, teams can identify the last successful deployment for a given environment and trigger a rollback against that specific deployment ID. A rollback deployment reuses both the manifest and the resource graph from that earlier deployment and regenerates the Terraform/OpenTofu code with the same module versions that were used at the time, ensuring that application and infrastructure configuration are reverted together in a consistent way.
+
+The rollback is executed like any other deployment and supports dry run and plan-only mode for safe validation. It appears in the normal deployment history with its own logs and outputs. This lets teams quickly mitigate production issues, restore service health, and maintain a full audit trail of what was changed and when.
+
+## References
+
+- [Platform Orchestrator Documentation](https://developer.humanitec.com)
+- [Platform Orchestrator Terraform Modules](https://github.com/humanitec-tf-modules)
+
+<!-- BEGIN_TF_DOCS -->
+
+<!-- END_TF_DOCS -->

day-2-operations/rollback/main.tf

@@ -0,0 +1 @@
+# Use case implementation being prepared