{
  "deep_analysis": {
    "cncf_projects": [
      {
        "name": "Kubernetes",
        "category": "Orchestration & Management",
        "usage_context": "Primary container orchestration platform",
        "version": "v1.26",
        "configuration_details": "Three production clusters with Calico CNI"
      }
    ],
    "architecture_components": {
      "infrastructure_layer": [
        {
          "component": "Kubernetes Clusters",
          "description": "Three production clusters (us-east-1, us-west-2, eu-west-1)"
        }
      ],
      "platform_layer": [
        {
          "component": "Istio Service Mesh",
          "description": "Traffic management and observability"
        }
      ],
      "application_layer": [
        {
          "component": "Microservices",
          "description": "200+ microservices deployed across clusters"
        }
      ]
    },
    "integration_patterns": [
      {
        "pattern": "Service Mesh Integration",
        "description": "Istio provides traffic management between Kubernetes services",
        "projects_involved": ["Kubernetes", "Istio"]
      }
    ],
    "technical_metrics": [
      {
        "metric_name": "API Latency (p95)",
        "before_value": "500ms",
        "after_value": "50ms",
        "improvement_factor": "10x",
        "business_impact": "Enabled 200% user growth",
        "transcript_quote": "We reduced our p95 API latency from 500 milliseconds down to just 50 milliseconds"
      }
    ],
    "sections": {
      "background": "200-400 words: Company context from transcript...",
      "technical_challenge": "400-600 words: Specific problems faced...",
      "architecture_overview": "500-700 words: High-level design...",
      "implementation_details": "700-900 words: Step-by-step process...",
      "results_and_impact": "400-600 words: Outcomes and metrics...",
      "lessons_learned": "400-600 words: Reflections and advice..."
    },
    "screenshot_opportunities": [
      {
        "timestamp_seconds": 120,
        "description": "Kubernetes dashboard showing cluster overview",
        "section": "architecture_overview"
      }
    ],
    "key_quotes": [
      {
        "quote": "Moving to Kubernetes allowed us to scale from 50 to 500 microservices",
        "speaker": "CTO",
        "relevance": "Business impact of architecture decision"
      }
    ]
  },
  "diagram_specifications": {
    "diagrams": [
      {
        "title": "High-Level Architecture",
        "diagram_type": "system_context",
        "description": "Shows external users, load balancers, Kubernetes clusters, and databases",
        "components": ["Users", "AWS ALB", "EKS Clusters", "RDS", "S3"],
        "relationships": [
          {"from": "Users", "to": "AWS ALB", "type": "HTTPS requests"},
          {"from": "AWS ALB", "to": "EKS Clusters", "type": "Routes traffic"}
        ]
      }
    ]
  },
  "company_info": {
    "name": "Example Corp",
    "url": "https://example.com",
    "industry": "E-commerce",
    "verified_membership": true,
    "company_size": "500-1000 employees"
  },
  "video_metadata": {
    "title": "Example Corp's Journey to Cloud Native with Kubernetes and Istio - John Doe & Jane Smith, Example Corp",
    "url": "https://youtube.com/watch?v=VIDEO_ID",
    "duration_seconds": 1234,
    "duration_string": "20:34",
    "publication_date": "2026-01-15",
    "speakers": "John Doe & Jane Smith"
  }
}

{
  "metadata": {
    "title": "Reference Architecture: E-commerce Platform on Kubernetes with Istio Service Mesh",
    "subtitle": "Multi-region, multi-cluster architecture for high-traffic e-commerce workloads",
    "company_name": "Example Corp",
    "company_url": "https://example.com",
    "industry": "E-commerce",
    "video_url": "https://youtube.com/watch?v=VIDEO_ID",
    "video_title": "Example Corp's Journey to Cloud Native with Kubernetes and Istio - John Doe & Jane Smith, Example Corp",
    "duration_string": "20:34",
    "speakers": "John Doe & Jane Smith",
    "publication_date": "2026-02-09",
    "word_count": 3500,
    "estimated_read_time": "18 minutes",
    "tab_metadata": {
      "project_maturity": "graduated",
      "architectural_significance": "Demonstrates multi-cluster Kubernetes with service mesh at scale for e-commerce",
      "primary_patterns": ["microservices", "service-mesh", "multi-cluster"]
    }
  },
  "sections": {
    "executive_summary": "200-300 words: Concise overview of the architecture, problem solved, and key outcomes...",
    "background": "300-400 words: Company context, industry, business requirements...",
    "technical_challenge": "400-600 words: Specific technical problems faced (scalability, reliability, etc.)...",
    "architecture_overview": "500-700 words: High-level architecture description with layers...",
    "architecture_diagrams": "300-400 words: Descriptions of each diagram with references...",
    "cncf_projects": "500-700 words: Detailed usage of each CNCF project...",
    "integration_patterns": "400-600 words: How projects integrate (e.g., Kubernetes + Istio)...",
    "implementation_details": "700-900 words: Step-by-step implementation process with commands/configs...",
    "deployment_architecture": "400-600 words: Multi-cluster, multi-region deployment setup...",
    "observability_operations": "400-600 words: Monitoring, logging, alerting, operations...",
    "results_and_impact": "400-600 words: Quantitative results and business impact...",
    "lessons_learned": "400-600 words: What worked, what didn't, recommendations...",
    "conclusion": "200-300 words: Summary and future directions..."
  },
  "cncf_project_list": [
    {
      "name": "Kubernetes",
      "category": "Orchestration & Management",
      "usage_summary": "Primary container orchestration platform across three production clusters"
    },
    {
      "name": "Istio",
      "category": "Service Mesh",
      "usage_summary": "Traffic management, security, and observability for microservices"
    }
  ],
  "key_metrics_summary": [
    {
      "metric": "API Latency (p95)",
      "improvement": "500ms → 50ms (10x improvement)",
      "business_impact": "Enabled 200% user growth"
    }
  ]
}

1. Paragraph Structure:
   - NEVER generate text as one continuous blob
   - ALWAYS break content into multiple paragraphs (2-5 sentences each)
   - Add blank line between paragraphs in markdown
   - Each paragraph should have ONE clear focus
   
2. Markdown Table Formatting:
   - Tables MUST have proper markdown syntax:
     | Column 1 | Column 2 | Column 3 |
     |----------|----------|----------|
     | Row 1    | Data     | Data     |
     | Row 2    | Data     | Data     |
   
   - ALWAYS include header separator row with dashes: |----------|
   - Ensure each row has same number of columns as header
   - No missing pipes (|) at start/end of rows
   - Test table structure: count pipes in header vs data rows
   
3. Professional Tone:
   - Minimize bold formatting (use only for project names on first mention)
   - NO emojis anywhere in the content
   - NO marketing language or buzzwords
   - Use formal technical writing style
   - Avoid excessive formatting (bold, italics, caps)
   
4. Section Organization:
   - Use clear subsection headers (###) when needed
   - Group related content logically
   - Use numbered lists for sequential steps
   - Use bullet lists for non-sequential items
   
5. Bad Example (DO NOT DO THIS):
   "CERN's architecture leverages six CNCF projects each serving a specific purpose in the overall system Kubernetes CNCF Graduated serves as the primary container orchestration platform hosting Keycloak pods across multiple clusters in different availability zones The migration from VM-based infrastructure to Kubernetes occurred in September 2023 moving from puppet-managed VMs to operator-managed containers The multi-cluster approach treats each Kubernetes cluster as cattle rather than pets clusters are replaceable and zone failures are handled gracefully..."
   
   Why bad: One massive paragraph, no breaks, unreadable
   
6. Good Example (DO THIS):
   "[CERN](https://home.cern)'s architecture leverages six CNCF projects, each serving a specific purpose in the overall system.
   
   **[Kubernetes](https://kubernetes.io)** (CNCF Graduated) serves as the primary container orchestration platform, hosting Keycloak pods across multiple clusters in different availability zones. The migration from VM-based infrastructure to Kubernetes occurred in September 2023, moving from puppet-managed VMs to operator-managed containers.
   
   The multi-cluster approach treats each Kubernetes cluster as cattle rather than pets. Clusters are replaceable and zone failures are handled gracefully without manual intervention. This design choice enables automatic failover and reduces operational burden."
   
   Why good: Multiple paragraphs, clear breaks, readable structure, proper linking

7. Screenshot Management (CRITICAL):
   - EACH screenshot MUST be used EXACTLY ONCE in the document
   - Track used screenshots to prevent duplicates
   - Screenshots are numbered 1-6 (screenshot-1.jpg through screenshot-6.jpg)
   - Once a screenshot is embedded, mark it as USED
   - NEVER reference the same screenshot number twice
   - If you need to refer to a diagram again, use text reference: "As shown in the architecture diagram above..."
   - Screenshot format: [![Description](images/slug/screenshot-N.jpg)](VIDEO_URL&t=XXXs)
   - Each screenshot should appear in the most relevant section based on deep_analysis.screenshot_opportunities
   - Distribute screenshots across 3-4 major sections (not all in one place)
   - Example: screenshot-1 in Background, screenshot-2 in Architecture Overview, screenshot-3 in Implementation, etc.

1. Load deep_analysis from input
2. Load diagram_specifications from input
3. Load company_info from input
4. Load video_metadata from input
5. Verify all required fields are present
6. Verify deep_analysis has 5+ CNCF projects
7. Verify all 3 architecture layers are present

1. Generate title:
   - Format: "Reference Architecture: [Problem Domain] on [Primary CNCF Project] with [Secondary Projects]"
   - Example: "Reference Architecture: E-commerce Platform on Kubernetes with Istio Service Mesh"
   - Keep title under 100 characters
   - Make it descriptive and specific

2. Generate subtitle:
   - One-line description of the architecture's purpose
   - Format: "[Architecture pattern] for [use case]"
   - Example: "Multi-region, multi-cluster architecture for high-traffic e-commerce workloads"
   - Keep subtitle under 150 characters

3. Extract company_name and company_url from company_info:
   - company_name: from company_info.name
   - company_url: from company_info.url

4. Extract video metadata:
   - video_url: from video_metadata.url
   - video_title: from video_metadata.title (full title with speakers)
   - duration_string: from video_metadata.duration_string (format: "MM:SS" or "HH:MM:SS")
   - speakers: from video_metadata.speakers (extracted from title, format: "Name1 & Name2")

5. Calculate word_count:
   - Sum word counts from all sections
   - Target: 2500-4000 words (acceptable: 2000-5000)

6. Calculate estimated_read_time:
   - Formula: word_count / 200 (words per minute)
   - Round to nearest minute

7. Generate TAB metadata:
   a. project_maturity:
      - Check CNCF project maturity levels
      - Use highest maturity level among primary projects
      - Values: "graduated", "incubating", "sandbox"
   
   b. architectural_significance:
      - One sentence explaining why this architecture is significant
      - Focus on: scale, complexity, novel patterns, lessons learned
      - Example: "Demonstrates multi-cluster Kubernetes with service mesh at scale for e-commerce"
   
   c. primary_patterns:
      - List 2-4 architectural patterns used
      - Examples: "microservices", "service-mesh", "multi-cluster", "gitops", "event-driven"
      - Extract from deep_analysis.integration_patterns and architecture description

6. Set publication_date to current date (ISO format: YYYY-MM-DD)

7. Copy company_name, industry, video_url from inputs

Linking Rules (apply throughout ALL sections):

1. Company Name Linking:
   - ALWAYS link company name: [Company Name](https://company-url.com)
   - Link company name in EVERY section where it appears
   - Example: "[CERN](https://home.cern)" NOT "CERN"
   - Use company_url from company_info.url

2. CNCF Project Linking:
   - ALWAYS link CNCF projects with bold formatting: **[Project Name](https://project-url)**
   - Link on FIRST mention in each major section
   - Examples:
     - **[Kubernetes](https://kubernetes.io)**
     - **[Keycloak](https://www.keycloak.org)**
     - **[Argo CD](https://argoproj.github.io/cd/)**
     - **[Prometheus](https://prometheus.io)**
     - **[Istio](https://istio.io)**
   - Use official project URLs (kubernetes.io, istio.io, etc.)
   - Subsequent mentions in same section can be unlinked

3. CNCF Glossary Term Linking:
   - Link cloud-native terminology to CNCF glossary: [term](https://glossary.cncf.io/term/)
   - Common terms to link:
     - [cloud-native](https://glossary.cncf.io/cloud-native-tech/)
     - [microservices](https://glossary.cncf.io/microservices-architecture/)
     - [container orchestration](https://glossary.cncf.io/container-orchestration/)
     - [service mesh](https://glossary.cncf.io/service-mesh/)
     - [observability](https://glossary.cncf.io/observability/)
     - [GitOps](https://glossary.cncf.io/gitops/)
     - [progressive delivery](https://glossary.cncf.io/progressive-delivery/)
     - [canary deployment](https://glossary.cncf.io/canary-deployment/)
   - Link on first mention in each major section
   - Use kebab-case URLs (service-mesh, not servicemesh)

4. Project URL Reference List:
   Kubernetes: https://kubernetes.io
   Keycloak: https://www.keycloak.org
   Argo CD: https://argoproj.github.io/cd/
   Argo Rollouts: https://argoproj.github.io/rollouts/
   Prometheus: https://prometheus.io
   Grafana: https://grafana.com
   Istio: https://istio.io
   Envoy: https://www.envoyproxy.io
   Helm: https://helm.sh
   Fluent Bit: https://fluentbit.io
   Fluentd: https://www.fluentd.org
   Jaeger: https://www.jaegertracing.io
   Podman: https://podman.io
   Containerd: https://containerd.io
   
   (If project not listed, use format: https://projectname.io or https://github.com/cncf/projectname)

Example paragraph with proper linking:

"[CERN](https://home.cern) operates a multi-cluster **[Kubernetes](https://kubernetes.io)** architecture 
across multiple availability zones. The team uses **[Keycloak](https://www.keycloak.org)** for identity 
management with **[Argo CD](https://argoproj.github.io/cd/)** for [GitOps](https://glossary.cncf.io/gitops/)-based 
deployments. This [cloud-native](https://glossary.cncf.io/cloud-native-tech/) approach enables 
[CERN](https://home.cern) to manage 200,000 users with high availability. Monitoring is handled by 
**[Prometheus](https://prometheus.io)** and **[Grafana](https://grafana.com)**."

Quality Checks:
- [ ] Company name linked in every section
- [ ] All CNCF projects linked with bold on first mention per section
- [ ] Cloud-native terms linked to glossary on first mention per section
- [ ] URLs are correct and follow official project domains
- [ ] No broken links or placeholder URLs

Paragraph 1: Problem and Context (50-75 words)
- Company name and industry
- Business challenge or requirement
- Why cloud native was needed
- Example: "Example Corp, a leading e-commerce platform, needed to scale from 50 to 500 microservices while maintaining sub-100ms API latency for millions of daily users."

Paragraph 2: Solution Overview (75-100 words)
- High-level architecture description
- Primary CNCF projects used
- Key architectural patterns
- Example: "The team implemented a multi-region Kubernetes architecture spanning three AWS regions, with Istio service mesh for traffic management and Prometheus/Grafana for observability."

Paragraph 3: Key Results (50-75 words)
- Top 3-4 quantitative improvements
- Business impact
- Example: "The new architecture reduced API latency by 10x (500ms → 50ms), improved deployment frequency from weekly to 50+ times per day, and enabled the platform to handle 200% user growth."

Paragraph 4: Significance (25-50 words)
- Why this architecture is relevant to other organizations
- What makes it noteworthy
- Example: "This reference architecture demonstrates how to operate Kubernetes at scale across multiple regions while maintaining high availability and performance."

Quality checks:
- Total word count: 200-300 words
- No marketing language or buzzwords
- Includes specific metrics with numbers
- Mentions 3-5 CNCF projects by name

Paragraph 1: Company Overview (75-100 words)
- Company name, industry, size
- Core business and products
- Target market and scale
- Extract from deep_analysis.sections.background and company_info
- Example: "Example Corp is a global e-commerce platform serving 10 million monthly active users across 30 countries. Founded in 2015, the company processes over $500M in annual transactions through its web and mobile applications."

Paragraph 2: Previous Architecture (100-125 words)
- What they were using before (monolith, legacy systems, etc.)
- Technical limitations of old approach
- Specific pain points
- Extract from deep_analysis.sections.background and technical_challenge
- Example: "Prior to 2024, Example Corp ran on a monolithic Rails application deployed on EC2 instances behind an ELB. As the platform grew, they encountered several critical limitations: deploys took 45 minutes and required downtime, scaling required manual intervention, and debugging production issues was difficult due to lack of observability."

Paragraph 3: Business Drivers (75-100 words)
- Why change was necessary
- Business goals and requirements
- Growth projections or competitive pressure
- Extract from deep_analysis.sections.background and key_quotes
- Example: "The company's ambitious growth plans required a more scalable architecture. The CTO stated: 'We needed to move from deploying once a week to multiple times per day to keep pace with customer demands.' Additionally, expanding to new regions required geographic distribution of services."

Paragraph 4: Decision to Adopt Cloud Native (50-75 words)
- Why they chose Kubernetes and CNCF projects
- Evaluation process or alternatives considered
- Key decision factors
- Example: "After evaluating managed services, serverless, and Kubernetes, the team chose Kubernetes for its flexibility and community support. The decision to adopt Istio came later when the team realized they needed more sophisticated traffic management and observability."

Quality checks:
- Total word count: 300-400 words
- Provides sufficient context for technical decisions
- Includes company-specific details (not generic)
- No fabricated information (only from transcript)

Paragraph 1: Core Technical Problem (100-150 words)
- Specific technical issues (not business issues)
- Why existing architecture couldn't solve it
- Technical constraints and requirements
- Extract from deep_analysis.sections.technical_challenge
- Use technical vocabulary (latency, throughput, consistency, etc.)
- Example: "The monolithic architecture presented three critical technical challenges: First, the application's synchronous request-response pattern created cascading failures when downstream services experienced latency. A slow database query could block an entire worker process, degrading performance across the entire application. Second, the team lacked visibility into service dependencies, making it difficult to debug production issues..."

Paragraph 2: Scalability Challenges (100-150 words)
- Specific scalability issues
- Performance bottlenecks
- Resource utilization problems
- Include metrics from deep_analysis.technical_metrics
- Example: "The platform's traffic patterns showed 10x spikes during flash sales and promotional events. The monolith could not horizontally scale individual components—scaling the checkout service meant scaling the entire application, wasting resources. During peak traffic, API latency (p95) reached 500ms, causing cart abandonment. The team estimated they needed to handle 50,000 requests per second during peak periods..."

Paragraph 3: Reliability and Availability Challenges (100-150 words)
- Downtime issues
- Failure scenarios
- Disaster recovery limitations
- Example: "Deployments required a maintenance window and caused 15-30 minutes of downtime. In 2023, the platform experienced three major outages totaling 8 hours of downtime, costing an estimated $2M in lost revenue. The monolithic architecture lacked regional redundancy—if the us-east-1 region went down, the entire platform went down. Additionally, database failures caused complete service outages..."

Paragraph 4: Operational Challenges (100-150 words)
- Deployment and CI/CD limitations
- Monitoring and debugging difficulties
- Team velocity and developer experience
- Example: "The ops team spent 40% of their time on manual deployment tasks and troubleshooting production issues. The lack of structured logging and distributed tracing made debugging difficult—engineers would spend hours correlating logs across multiple servers. Deployment frequency averaged once per week, limiting the team's ability to iterate quickly. Rollbacks required reverting database migrations, a risky and time-consuming process..."

Quality checks:
- Total word count: 400-600 words
- Focuses on technical problems (not business problems)
- Includes specific metrics and numbers
- Each paragraph has a clear focus
- Problems are concrete and specific (not vague)
- Connects to why cloud native was chosen

Paragraph 1: Architecture Vision (75-100 words)
- High-level architecture approach
- Key design principles
- Overall architecture style (microservices, event-driven, etc.)
- Example: "Example Corp adopted a microservices architecture running on Kubernetes across three AWS regions. The design prioritizes fault isolation, independent scaling, and regional autonomy. Services communicate via HTTP/gRPC through an Istio service mesh, with asynchronous events handled by Kafka for eventually-consistent operations."

Paragraph 2: Infrastructure Layer (150-200 words)
- Physical/cloud infrastructure
- Kubernetes clusters (how many, where, why)
- Networking setup
- Extract from deep_analysis.architecture_components.infrastructure_layer
- Include specific configuration details
- Example: "The infrastructure layer consists of six Kubernetes clusters: three production clusters (us-east-1, us-west-2, eu-west-1), two staging clusters (us-east-1, eu-west-1), and one shared services cluster for monitoring and CI/CD. Each production cluster runs on Amazon EKS with 20-50 m5.2xlarge nodes using Kubernetes v1.26 and Calico CNI for network policies. Multi-region setup enables 99.99% availability SLA and sub-50ms latency for users worldwide. AWS Network Load Balancers distribute traffic to Istio ingress gateways in each region, with Route53 providing geo-aware DNS routing..."

Paragraph 3: Platform Layer (150-200 words)
- Service mesh, API gateway, message broker
- Platform services (observability, logging, etc.)
- Security and policy enforcement
- Extract from deep_analysis.architecture_components.platform_layer
- Example: "The platform layer provides cross-cutting concerns for all applications. Istio v1.18 service mesh handles traffic management, with Envoy sidecars automatically injected into all pods. Istio provides mutual TLS between services, circuit breaking, retries, and traffic shifting for canary deployments. Prometheus scrapes metrics from Envoy proxies and application endpoints, while Grafana provides dashboards and alerting. The ELK stack (Elasticsearch, Logstash, Kibana) centralizes logs from all services with structured JSON logging. ArgoCD implements GitOps for declarative deployments, with applications automatically synced from Git repositories..."

Paragraph 4: Application Layer (150-200 words)
- Microservices organization
- Service boundaries and responsibilities
- Data storage and state management
- Extract from deep_analysis.architecture_components.application_layer
- Example: "The application layer consists of 200+ microservices organized into 12 bounded contexts aligned with business domains (Catalog, Cart, Checkout, Orders, Payments, Inventory, Recommendations, etc.). Each domain team owns 10-20 services deployed independently. Services expose REST APIs and gRPC endpoints through Istio virtual services. State is stored in domain-specific databases (PostgreSQL for transactional data, DynamoDB for session data, Redis for caching, Elasticsearch for search). Services follow the Outbox pattern for reliable event publishing to Kafka, ensuring eventual consistency across domains..."

Quality checks:
- Total word count: 500-700 words
- Describes all 3 architecture layers clearly
- Includes specific technologies and versions
- Explains WHY design decisions were made (not just what)
- Provides enough detail for engineers to understand the architecture
- References diagram(s) if available

Introduction (50 words):
- How many diagrams are included
- Purpose of each diagram type
- Example: "This reference architecture includes three diagrams that illustrate different aspects of the system: a high-level system context diagram, a detailed deployment architecture diagram, and a service interaction diagram showing request flow."

For each diagram from diagram_specifications.diagrams:

Diagram N: [Title] (75-125 words)
- Diagram type and purpose
- Main components shown
- Key relationships and data flows
- What this diagram reveals about the architecture
- Extract from diagram_specifications.diagrams[N]
- Example: 
  "Diagram 1: High-Level Architecture
  
  This system context diagram shows how external users interact with the platform across multiple regions. Users make HTTPS requests to Route53, which performs geographic routing to the nearest regional load balancer (AWS Network Load Balancer). Each region hosts an independent Kubernetes cluster with full application stack, ensuring regional autonomy. The diagram illustrates the data flow from user request through load balancer, Istio ingress gateway, microservices, and databases. Cross-region components include the shared monitoring cluster, CI/CD cluster, and centralized Elasticsearch for log aggregation."

Reference to diagrams in other sections:
- "See Diagram 1 for the complete system overview"
- "Refer to Diagram 2 for details on service-to-service communication"
- Encourage readers to use diagrams to understand the text

Quality checks:
- Total word count: 300-400 words
- Describes each diagram clearly without the diagram present
- Helps reader understand what they'll see in the visual
- Connects diagrams to architectural decisions
- If no diagram_specifications provided, explain that diagrams would enhance understanding and list what diagrams would be useful

CRITICAL: This section often becomes an unreadable blob. MUST use subsections and paragraph breaks.

Introduction (50-75 words):
- Brief paragraph listing all CNCF projects
- One sentence per project explaining its role
- Example: "This architecture leverages five graduated CNCF projects. **[Kubernetes](https://kubernetes.io)** provides container orchestration, **[Istio](https://istio.io)** handles service mesh capabilities, **[Prometheus](https://prometheus.io)** collects metrics, **[Argo CD](https://argoproj.github.io/cd/)** enables GitOps deployments, and **[Helm](https://helm.sh)** manages package definitions."

For each project in deep_analysis.cncf_projects:

### [Project Name] ([Category])

Write 3-4 SHORT paragraphs (NOT one long blob):

Paragraph 1 - Purpose (2-3 sentences):
[Why this project was chosen and its primary role]

Paragraph 2 - Implementation (3-4 sentences):
[Version, configuration, deployment details]

Paragraph 3 - Features (2-3 sentences + bullet list):
[Introduction sentence, then bulleted list of 3-5 features]

Paragraph 4 - Operations (2-3 sentences):
[How it's operated, monitored, maintained]

Example (CORRECT FORMATTING):

### Kubernetes (Orchestration & Management)

[Kubernetes](https://kubernetes.io) serves as the foundational container orchestration platform, managing all microservices across six clusters in three regions. The team selected Kubernetes for its maturity, extensive ecosystem, and proven scalability at enterprise scale.

The team deployed Kubernetes v1.26 using Amazon EKS in three AWS regions. Each production cluster runs 20-50 m5.2xlarge nodes with Cluster Autoscaler for dynamic scaling. All clusters use Calico CNI for network policies and identical configurations managed through Git.

Key features utilized include:
- Deployments with rolling updates (maxSurge: 25%, maxUnavailable: 0)
- StatefulSets for Kafka and Elasticsearch clusters
- DaemonSets for monitoring agents (Prometheus Node Exporter, Fluentd)
- Horizontal Pod Autoscaler targeting 70% CPU utilization
- Network Policies for service-to-service security
- RBAC for team-based access control

Node pools are segmented by workload type (general compute, memory-intensive, GPU). Cluster upgrades follow a rolling approach: dev clusters first, then staging, then production regions sequentially.

Quality checks:
- Total word count: 500-700 words (80-140 words per project)
- Covers 5+ CNCF projects with proper paragraph structure
- Each project has 3-4 SHORT paragraphs (NOT one blob)
- Includes version numbers and specific configurations
- Explains WHY each project was chosen
- Uses subsection headers (###) for each project

Introduction (50-75 words):
- What integration patterns exist in this architecture
- Why integration between projects is important
- Example: "The architecture's success depends on seamless integration between CNCF projects. Three primary integration patterns enable this: service mesh observability integration, GitOps continuous deployment, and unified monitoring and alerting."

For each pattern in deep_analysis.integration_patterns (100-150 words each):

Pattern N: [Pattern Name]

**Projects Involved:** [List projects]
- Extract from integration_patterns[N].projects_involved

**Description:**
- How the pattern works
- Technical implementation details
- Extract from integration_patterns[N].description
- Include specific configuration or code examples

**Benefits:**
- What this integration enables
- Performance or operational improvements

**Implementation Challenges:**
- Difficulties encountered
- Solutions applied
- Extract from deep_analysis.sections.lessons_learned if relevant

Example:

Pattern 1: Service Mesh Observability Integration

**Projects Involved:** Kubernetes, Istio, Prometheus, Grafana

**Description:** Istio's Envoy sidecars automatically generate detailed metrics for all service-to-service communication without requiring application code changes. Prometheus scrapes these metrics every 15 seconds from each Envoy proxy using Kubernetes Service Discovery. The team configured Istio to export additional custom metrics for business-level monitoring (requests by product category, checkout completion rate). Grafana dashboards visualize service latency, error rates, and traffic patterns in real-time. The integration provides automatic RED metrics (Rate, Errors, Duration) for every service.

**Benefits:** This integration provides zero-instrumentation observability—new services automatically get monitoring without developer effort. The team reduced mean time to detection (MTTD) from 15 minutes to 2 minutes by alerting on Envoy proxy metrics. Service owners can identify downstream dependencies and latency sources through distributed tracing integration with Jaeger.

**Implementation Challenges:** The team initially encountered high cardinality issues when exporting metrics with too many labels (service, version, pod, cluster), causing Prometheus memory issues. Solution: reduced label cardinality by removing pod-level labels and using recording rules to pre-aggregate common queries.

Quality checks:
- Total word count: 400-600 words
- Describes 2-4 integration patterns in detail
- Shows how projects work together (not in isolation)
- Includes technical implementation details
- Mentions configuration specifics
- Explains benefits AND challenges

Introduction (75-100 words):
- Overview of implementation approach
- Timeline (how long it took)
- Team size and organization
- Extract from deep_analysis.sections.implementation_details
- Example: "The implementation occurred in four phases over six months, led by a platform team of 8 engineers. The team followed a phased rollout approach: infrastructure first, platform services second, application migration third, and optimization fourth. Each phase included validation in staging before production rollout."

Phase 1: [Phase Name] (150-200 words)
**Duration:** [Timeframe]

**Objectives:**
- What was accomplished in this phase
- Why this phase was first

**Steps:**
1. [Detailed step with commands or configurations]
2. [Detailed step with commands or configurations]
3. [Continue...]

**Challenges and Solutions:**
- Problem encountered
- How it was resolved
- Lesson learned

**Validation:**
- How success was measured
- Tests performed

Example:

Phase 1: Infrastructure Foundation (6 weeks)

**Duration:** January 1 - February 15, 2024

**Objectives:** Establish the base Kubernetes infrastructure across three regions with core platform services. This phase focused on cluster provisioning, networking setup, and security configuration.

**Steps:**
1. Provisioned three EKS clusters using eksctl with the following configuration:
   ```yaml
   apiVersion: eksctl.io/v1alpha5
   kind: ClusterConfig
   metadata:
     name: prod-us-east-1
     region: us-east-1
   nodeGroups:
     - name: general
       instanceType: m5.2xlarge
       desiredCapacity: 20
       maxSize: 50

### Step 11: Generate Deployment Architecture (400-600 words)

Describe multi-cluster, multi-region deployment setup:

### Step 12: Generate Observability and Operations (400-600 words)

Describe monitoring, logging, alerting, and operational practices:

### Step 13: Generate Results and Impact (400-600 words)

Present quantitative results and business impact:

### Step 14: Generate Lessons Learned (400-600 words)

Share reflections, recommendations, and advice:

### Step 15: Generate Conclusion (200-300 words)

Summarize and look forward:

### Step 16: Generate CNCF Project List

Create summary table of all CNCF projects:

### Step 17: Generate Key Metrics Summary

Create summary table of top improvements:

### Step 18: Final Validation and Quality Check

Before outputting the final JSON, validate all requirements:

---

## Common Mistakes to Avoid

### 1. Fabricating Technical Details

**❌ Wrong:**

(If transcript doesn't mention v1.28 or custom CNI)

**✅ Correct:**

(Only state what's in the transcript)

### 2. Using Marketing Language

**❌ Wrong:**

**✅ Correct:**

### 3. Generic Implementation Details

**❌ Wrong:**

**✅ Correct:**

### 4. Missing Technical Specificity

**❌ Wrong:**

**✅ Correct:**

### 5. Copying from Other Reference Architectures

**❌ Wrong:**

**✅ Correct:**

### 6. Inconsistent Company Names

**❌ Wrong:**

**✅ Correct:**

(Consistent company name usage throughout)

### 7. Wrong Word Count Ranges

**❌ Wrong:**

**✅ Correct:**

### 8. Missing Transcript Quotes for Metrics

**❌ Wrong:**
```json
{
  "metric": "API Latency (p95)",
  "improvement": "500ms → 50ms (10x improvement)",
  "business_impact": "Improved user experience"
  // Missing transcript_quote!
}

{
  "metric": "API Latency (p95)",
  "improvement": "500ms → 50ms (10x improvement)",
  "business_impact": "Reduced cart abandonment by 15%",
  "transcript_quote": "We reduced our p95 API latency from 500 milliseconds down to just 50 milliseconds"
}

{
  "metadata": {
    "title": "Reference Architecture: E-commerce Platform on Kubernetes with Istio Service Mesh",
    "subtitle": "Multi-region, multi-cluster architecture for high-traffic e-commerce workloads",
    "company_name": "Example Corp",
    "industry": "E-commerce",
    "video_url": "https://youtube.com/watch?v=VIDEO_ID",
    "publication_date": "2026-02-09",
    "word_count": 3500,
    "estimated_read_time": "18 minutes",
    "tab_metadata": {
      "project_maturity": "graduated",
      "architectural_significance": "Demonstrates multi-cluster Kubernetes with service mesh at scale for e-commerce, processing 50K requests/second with sub-50ms latency",
      "primary_patterns": ["microservices", "service-mesh", "multi-cluster", "gitops"]
    }
  },
  "sections": {
    "executive_summary": "Example Corp, a leading e-commerce platform serving 10 million monthly users, needed to scale from 50 to 500 microservices while maintaining sub-100ms API latency. Their monolithic Rails application couldn't meet these requirements...",
    "background": "Example Corp is a global e-commerce platform founded in 2015, processing over $500M in annual transactions. The company serves customers in 30 countries through web and mobile applications...",
    ...
  },
  "cncf_project_list": [
    {
      "name": "Kubernetes",
      "category": "Orchestration & Management",
      "usage_summary": "Primary container orchestration platform across three production clusters"
    },
    ...
  ],
  "key_metrics_summary": [
    {
      "metric": "API Latency (p95)",
      "improvement": "500ms → 50ms (10x improvement)",
      "business_impact": "Reduced cart abandonment by 15%, added $5M annual revenue"
    },
    ...
  ]
}