feat(ultraplan-local): v1.6.0 — /ultraresearch-local deep research command

Add /ultraresearch-local for structured research combining local codebase analysis with external knowledge via parallel agent swarms. Produces research briefs with triangulation, confidence ratings, and source quality assessment. New command: /ultraresearch-local with modes --quick, --local, --external, --fg. New agents: research-orchestrator (opus), docs-researcher, community-researcher, security-researcher, contrarian-researcher, gemini-bridge (all sonnet). New template: research-brief-template.md. Integration: --research flag in /ultraplan-local accepts pre-built research briefs (up to 3), enriches the interview and exploration phases. Planning orchestrator cross-references brief findings during synthesis. Design principle: Context Engineering — right information to right agent at right time. Research briefs are structured artifacts in the pipeline: ultraresearch → brief → ultraplan --research → plan → ultraexecute. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-04-08 08:58:35 +02:00 · 2026-04-08 08:58:35 +02:00 · baa2d0220b
commit baa2d0220b
488 changed files with 213221 additions and 0 deletions
--- a/skills/ms-ai-advisor/references/prompt-engineering/error-handling-and-fallback-prompting.md
+++ b/skills/ms-ai-advisor/references/prompt-engineering/error-handling-and-fallback-prompting.md
@ -0,0 +1,707 @@
+# Error Handling and Fallback Prompting Strategies
+
+**Last updated:** 2026-02
+**Status:** GA
+**Category:** Prompt Engineering & LLM Optimization
+
+---
+
+## Introduksjon
+
+Error handling og fallback-strategier er kritiske komponenter i produksjonsklare LLM-applikasjoner. Når AI-modeller møter feil, uventede tilstander eller usikkerhet i responsene sine, kan robuste error handling-mekanismer sikre at applikasjonen fortsetter å levere verdi selv under degraderte forhold.
+
+Denne kunnskapsreferansen dekker arkitekturmønstre for å håndtere feil fra Azure OpenAI, strategier for graceful degradation, retry-logikk og fallback prompting-teknikker som sikrer applikasjonen din forblir pålitelig i møte med usikkerhet og tekniske feil.
+
+**Nøkkelscenarier:**
+- Håndtering av 429 Rate Limit og 5xx-feil fra Azure OpenAI
+- Retry-logikk med exponential backoff
+- Fallback-prompts når modellen returnerer usikre eller ufullstendige svar
+- Graceful degradation når AI-komponenter feiler
+- Load balancing mellom flere Azure OpenAI-endepunkter
+
+**Confidence:** Høy – basert på offisiell Microsoft-dokumentasjon og etablerte mønstre fra Azure Well-Architected Framework.
+
+---
+
+## Kjernekomponenter / Nøkkelegenskaper
+
+### 1. HTTP Error Codes og Betydning
+
+Azure OpenAI returnerer standard HTTP-statuskoder som indikerer ulike feiltyper:
+
+| Status Code | Error Type | Betydning | Retry? |
+|-------------|------------|-----------|--------|
+| 400 | Bad Request Error | Ugyldig request (feil format, content filter treff) | Nei |
+| 401 | Authentication Error | Autentiseringsfeil | Nei |
+| 403 | Permission Denied Error | Manglende tilgang | Nei |
+| 404 | Not Found Error | Ressurs ikke funnet | Nei |
+| 408 | Request Timeout | Timeout i request | Ja |
+| 422 | Unprocessable Entity Error | Ugyldige data | Nei |
+| 429 | Rate Limit Error | Quotagrense nådd (TPM/RPM) | Ja |
+| 500 | Internal Server Error | Serverfeil | Ja |
+| 502 | Bad Gateway | Gateway-feil | Ja |
+| 503 | Service Unavailable | Tjeneste utilgjengelig | Ja |
+| 504 | Gateway Timeout | Gateway timeout | Ja |
+
+**Viktig:** 400-feil pga. content filtering genererer kostnader selv om requesten ikke fullføres. Implementer pre-filtering for å unngå unødvendige kostnader.
+
+### 2. Retry-Mekanismer i Offisielle SDKer
+
+Alle offisielle Azure OpenAI SDK-er har innebygd retry-logikk:
+
+**Python (openai-python):**
+```python
+from openai import OpenAI
+
+# Global retry-config
+client = OpenAI(
+    base_url="https://RESOURCE.openai.azure.com/openai/v1/",
+    api_key="YOUR_KEY",
+    max_retries=5  # Default: 2
+)
+
+# Per-request override
+client.with_options(max_retries=3).chat.completions.create(
+    messages=[{"role": "user", "content": "Query"}],
+    model="gpt-4o"
+)
+```
+
+**TypeScript/JavaScript (openai-node):**
+```typescript
+import { OpenAI } from "openai";
+
+const client = new OpenAI({
+    baseURL: "https://RESOURCE.openai.azure.com/openai/v1/",
+    apiKey: process.env.OPENAI_API_KEY,
+    maxRetries: 5  // Default: 2
+});
+
+// Per-request override
+await client.chat.completions.create(
+    { messages: [...], model: "gpt-4o" },
+    { maxRetries: 3 }
+);
+```
+
+**.NET (openai-dotnet):**
+```csharp
+// Automatisk retry (opp til 3 ganger) for:
+// - 408 Request Timeout
+// - 429 Too Many Requests
+// - 500, 502, 503, 504 Server Errors
+// Ingen manuell konfigurasjon nødvendig
+```
+
+**Automatisk retry gjelder for:**
+- 408 Request Timeout
+- 429 Rate Limit
+- ≥500 Internal Server Errors
+
+**Exponential backoff:** SDK-ene bruker exponential backoff med jitter for å unngå thundering herd-problemer.
+
+### 3. Retry-After Header
+
+Azure OpenAI inkluderer `Retry-After` HTTP-header ved 429-feil, som indikerer hvor lenge (i sekunder) klienten bør vente før neste forsøk.
+
+**Beste praksis:**
+- Respekter alltid `Retry-After` header
+- Bruk denne som minimum ventetid før retry
+- Kombiner med exponential backoff for robusthet
+
+### 4. Fallback Prompting-Strategier
+
+Når modellen returnerer usikre, ufullstendige eller uventede svar, kan fallback-prompting hjelpe:
+
+**Strategi 1: Forenklet prompt**
+```python
+primary_prompt = "Analyze this contract and extract all clauses related to liability, indemnification, and force majeure."
+
+fallback_prompt = "List the main topics in this contract."
+```
+
+**Strategi 2: Lavere temperature**
+```python
+# Primær forsøk
+response = client.chat.completions.create(
+    model="gpt-4o",
+    messages=[{"role": "user", "content": query}],
+    temperature=1.0
+)
+
+# Fallback: reduser temperature for mer deterministisk output
+if not is_valid_response(response):
+    response = client.chat.completions.create(
+        model="gpt-4o",
+        messages=[{"role": "user", "content": query}],
+        temperature=0.3
+    )
+```
+
+**Strategi 3: Fallback til enklere modell**
+```python
+models = ["gpt-4o", "gpt-4o-mini", "gpt-35-turbo"]
+
+for model in models:
+    try:
+        response = client.chat.completions.create(
+            model=model,
+            messages=[{"role": "user", "content": query}]
+        )
+        if is_valid_response(response):
+            break
+    except Exception:
+        continue
+```
+
+**Strategi 4: Chunking ved token limit-feil**
+```python
+try:
+    response = client.chat.completions.create(
+        model="gpt-4o",
+        messages=[{"role": "user", "content": large_document}]
+    )
+except openai.BadRequestError as e:
+    if "maximum context length" in str(e):
+        # Split dokument i chunks og prosesser hver del
+        chunks = split_document(large_document, chunk_size=2000)
+        results = [process_chunk(chunk) for chunk in chunks]
+        response = aggregate_results(results)
+```
+
+### 5. Content Safety og Output Handling
+
+Azure AI Content Safety kan filtrere både input-prompts og LLM-output. Insecure output handling er en av OWASP Top 10 for LLM-risikoer.
+
+**Anbefalinger:**
+- Valider og sanitize alle LLM-output før bruk i downstream-systemer
+- Bruk Azure AI Content Safety for filtrering
+- Encode output før presentasjon (unngå XSS, code injection)
+- Implementer zero-trust: behandle LLM som usikkert eksternt system
+
+---
+
+## Arkitekturmønstre
+
+### 1. Smart Load Balancing med Priority-Based Failover
+
+For production-workloads anbefales det å distribuere trafikk over flere Azure OpenAI-instanser basert på prioritet og tilgjengelighet.
+
+**Mønster:**
+```
+Priority 1: PTU (Provisioned Throughput) – forhåndsbetalt kapasitet
+Priority 2: S0 (Pay-as-you-go) i primærregion
+Priority 3: S0 i sekundærregioner
+```
+
+**Implementering med Azure Container Apps / API Management:**
+- Overvåk `Retry-After` header fra Azure OpenAI
+- Marker throttlede endepunkter som "unhealthy" i perioden angitt av `Retry-After`
+- Route trafikk til neste prioritet mens høyeste prioritet er throttlet
+- **Ingen ventetid** mellom failover-forsøk på server-side (immediate failover)
+
+**Referanse:** [Azure OpenAI Priority-Based Load Balancer (GitHub)](https://github.com/Azure-Samples/openai-aca-lb)
+
+### 2. Graceful Degradation Mode
+
+Basert på Azure Well-Architected Framework reliability-anbefalinger:
+
+**Design-prinsipper:**
+1. **Failure detection og automated initiation:** Monitoring-systemer detekterer degraderte komponenter og aktiverer automatisk graceful degradation-modus.
+2. **Degradert brukeropplevelse:** Notifiser brukere om redusert funksjonalitet (f.eks. "AI-anbefalinger midlertidig utilgjengelig").
+3. **Alternative paths:** Oppretthold kritiske flows selv når AI-komponenter feiler:
+   - Cached responses for vanlige queries
+   - Fallback til regelbasert logikk
+   - Read-only mode med tidligere genererte data
+
+**Eksempel:**
+```python
+def get_ai_recommendation(user_query):
+    try:
+        response = openai_client.chat.completions.create(...)
+        return response.choices[0].message.content
+    except openai.RateLimitError:
+        # Fallback: hent fra cache eller returner standard-anbefaling
+        return get_cached_recommendation(user_query)
+    except openai.APIError:
+        # Graceful degradation: informer bruker
+        return {
+            "status": "degraded",
+            "message": "AI-tjeneste midlertidig utilgjengelig. Prøv igjen om noen minutter."
+        }
+```
+
+### 3. Circuit Breaker Pattern
+
+Forhindrer at applikasjonen kontinuerlig prøver å nå en failende tjeneste.
+
+**States:**
+- **Closed:** Normal drift, requests går til Azure OpenAI
+- **Open:** Tjeneste ansett som failende, requests blokkeres umiddelbart
+- **Half-Open:** Test om tjeneste er tilbake, tillat begrenset trafikk
+
+**Implementering:**
+```python
+from pybreaker import CircuitBreaker
+
+breaker = CircuitBreaker(fail_max=5, timeout_duration=60)
+
+@breaker
+def call_openai(prompt):
+    return client.chat.completions.create(
+        model="gpt-4o",
+        messages=[{"role": "user", "content": prompt}]
+    )
+
+try:
+    response = call_openai("User query")
+except CircuitBreakerError:
+    # Fallback: bruk cached response eller default
+    response = get_fallback_response()
+```
+
+### 4. Bulkhead Pattern
+
+Isolerer feil ved å partisjonere tjeneste-instanser i separate pools. Hvis én pool feiler, påvirkes ikke andre pools.
+
+**Eksempel:**
+- Pool A: AI-generert content for marketing
+- Pool B: AI-generert content for kundesupport
+- Pool C: AI-analyse for rapporter
+
+Hvis Pool A throttles, fortsetter Pool B og C å fungere normalt.
+
+### 5. Checkpoint Pattern for Long-Running Operations
+
+For langvarige LLM-operasjoner (f.eks. batch-prosessering av dokumenter):
+
+**Implementering:**
+```python
+def process_documents_with_checkpoints(documents, checkpoint_file):
+    checkpoint = load_checkpoint(checkpoint_file)
+    start_index = checkpoint.get("last_processed_index", 0)
+
+    for i, doc in enumerate(documents[start_index:]):
+        try:
+            result = process_with_llm(doc)
+            save_result(result)
+
+            # Lagre checkpoint hvert 10. dokument
+            if (i + start_index) % 10 == 0:
+                save_checkpoint(checkpoint_file, {"last_processed_index": i + start_index})
+        except Exception as e:
+            log_error(e)
+            save_checkpoint(checkpoint_file, {"last_processed_index": i + start_index})
+            raise
+```
+
+---
+
+## Beslutningsveiledning
+
+### Når skal du bruke hvilken strategi?
+
+| Scenario | Anbefalt Strategi | Alternativ |
+|----------|-------------------|------------|
+| 429 Rate Limit | Respect `Retry-After`, exponential backoff, load balancing | Circuit breaker + fallback |
+| 500-feil (transient) | Automatisk retry med SDK (2-3 forsøk) | Circuit breaker |
+| Content filter block (400) | Pre-filter input med Azure AI Content Safety | Fallback til regelbasert output |
+| Usikre/ufullstendige svar | Lavere temperature, forenklet prompt | Fallback til enklere modell |
+| Token limit overskredet | Chunking + aggregering | Oppsummer input før sending |
+| Persistent service unavailable | Graceful degradation + cached responses | Fallback til regelbasert logikk |
+| Multi-tenant med ulik prioritet | Priority-based load balancing | Bulkhead pattern |
+| Long-running batch jobs | Checkpoint pattern | Background jobs med queue |
+
+### Sikkerhets- og Compliance-Hensyn
+
+**Offentlig sektor (Norge):**
+- **Logging:** Logg alle feil, men IKKE logg personopplysninger i error messages
+- **Retry-limits:** Begrens antall retries for å unngå unødvendig kostnad og ressursbruk
+- **Fallback-data:** Sikre at fallback-responses ikke eksponerer sensitiv informasjon
+- **Content Safety:** Alltid bruk Azure AI Content Safety for både input og output i offentlige tjenester
+
+---
+
+## Integrasjon med Microsoft-stakken
+
+### Azure OpenAI + Azure AI Content Safety
+
+**Pre-filtering av input:**
+```python
+from azure.ai.contentsafety import ContentSafetyClient
+from azure.core.credentials import AzureKeyCredential
+
+content_safety_client = ContentSafetyClient(
+    endpoint="https://YOUR-RESOURCE.cognitiveservices.azure.com",
+    credential=AzureKeyCredential("YOUR_KEY")
+)
+
+def safe_openai_call(user_input):
+    # Pre-filter input
+    analysis = content_safety_client.analyze_text(text=user_input)
+    if analysis.hate_result.severity > 2:
+        return {"error": "Input blocked by content filter"}
+
+    # Call OpenAI
+    response = openai_client.chat.completions.create(
+        model="gpt-4o",
+        messages=[{"role": "user", "content": user_input}]
+    )
+
+    # Post-filter output
+    output_text = response.choices[0].message.content
+    output_analysis = content_safety_client.analyze_text(text=output_text)
+    if output_analysis.violence_result.severity > 2:
+        return {"error": "Output blocked by content filter"}
+
+    return {"response": output_text}
+```
+
+### Azure API Management (APIM) med llm-content-safety Policy
+
+APIM kan enforces content safety checks automatisk:
+
+```xml
+<policies>
+    <inbound>
+        <llm-content-safety backend-id="content-safety-backend" shield-prompt="true">
+            <categories output-type="EightSeverityLevels">
+                <category name="Hate" threshold="4" />
+                <category name="Violence" threshold="4" />
+            </categories>
+        </llm-content-safety>
+    </inbound>
+</policies>
+```
+
+**Fordeler:**
+- Sentralisert content safety enforcement
+- Automatisk blokkering av requester som matcher attack patterns
+- Ingen endringer nødvendig i applikasjonskode
+
+### Azure Monitor + Action Groups for Automated Healing
+
+**Setup:**
+1. Azure Monitor overvåker Azure OpenAI metrics (rate limit errors, 5xx errors)
+2. Alert rule triggers ved definert terskel (f.eks. >10 429-feil per minutt)
+3. Action Group starter automated healing:
+   - Azure Function som scaler opp quota
+   - Automation Runbook som switcher til backup-region
+   - Logic App som sender varsling til on-call team
+
+**Eksempel alert rule:**
+```json
+{
+  "condition": {
+    "allOf": [
+      {
+        "metricName": "TooManyRequests",
+        "operator": "GreaterThan",
+        "threshold": 10,
+        "timeAggregation": "Total",
+        "dimensions": []
+      }
+    ]
+  },
+  "actions": {
+    "actionGroups": [
+      "/subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.Insights/actionGroups/OpenAI-AutoHealing"
+    ]
+  }
+}
+```
+
+### Azure AI Foundry Safety Evaluations
+
+For systematisk testing av error handling før produksjon:
+
+```python
+from azure.ai.evaluation import evaluate
+
+result = evaluate(
+    evaluation_name="error_handling_evaluation",
+    data="test_data.jsonl",
+    model="gpt-4o",
+    evaluators={
+        "robustness": robustness_evaluator,
+        "safety": safety_evaluator
+    }
+)
+```
+
+**Evalueringsscenarier:**
+- Hvordan håndterer modellen injected adversarial prompts?
+- Returnerer modellen sikre fallback-responses ved usikkerhet?
+- Er retry-logikken effektiv under simulert rate limiting?
+
+---
+
+## Offentlig sektor (Norge)
+
+### Spesifikke Krav og Anbefalinger
+
+**1. Personvern (GDPR/DPIA):**
+- **Problem:** Feilmeldinger kan utilsiktet eksponere personopplysninger
+- **Løsning:**
+  - Sanitize alle error messages før logging
+  - Bruk generic error messages til brukere
+  - Logg detaljert informasjon i secure audit trail
+
+**2. Tilgjengelighet og Redundans:**
+- **Krav:** Offentlige tjenester må være tilgjengelige 24/7 (eller i henhold til SLA)
+- **Løsning:**
+  - Multi-region deployment med automated failover
+  - Graceful degradation som opprettholder kritiske funksjoner
+  - Cached responses for vanlige queries
+
+**3. Kostnadsbevissthet:**
+- **Problem:** Ukontrollerte retries kan generere høye kostnader
+- **Løsning:**
+  - Sett max retry limits (f.eks. 3 forsøk)
+  - Implementer cost budgets i Azure Cost Management
+  - Alert ved unormal kostnadsøkning
+
+**4. Norsk språk og kulturell kontekst:**
+- **Problem:** Fallback-prompts må være kulturelt og språklig relevante
+- **Løsning:**
+  - Test fallback-prompts på norsk innhold
+  - Bruk norske eksempler i system prompts
+  - Valider at fallback-responses er forståelige for norske brukere
+
+**5. Compliance og Audit Trail:**
+- **Krav:** Dokumentasjon av alle feil og recovery-actions
+- **Løsning:**
+  - Log alle error events med timestamps og correlation IDs
+  - Implementer distributed tracing (Azure Application Insights)
+  - Monthly reporting av error rates og recovery success
+
+---
+
+## Kostnad og lisensiering
+
+### Kostnadsimplikasjoner av Error Handling
+
+**1. Retry-kostnader:**
+- **400-feil (content filter):** Du betaler for prompt tokens selv om requesten blokkeres
+- **429/5xx-feil:** Ingen kostnad for failede requests
+- **Retry-forsøk:** Hver retry koster som en ny request
+
+**Estimat (gpt-4o, NOK, februar 2026):**
+- Prompt: 5000 tokens × 0,0035 NOK = 17,50 NOK
+- Completion: 1000 tokens × 0,014 NOK = 14,00 NOK
+- **Total per request:** ~31,50 NOK
+
+**Med 3 retries:** 4 × 31,50 NOK = 126 NOK for én user query (hvis alle forsøk bruker full context)
+
+**Kostnadsoptimalisering:**
+- Reducer context size i retry-forsøk
+- Bruk billigere modeller for fallback (gpt-4o-mini, gpt-35-turbo)
+- Implementer aggressive caching
+- Bruk PTU (Provisioned Throughput) for forutsigbare kostnader
+
+**PTU vs. Pay-as-you-go for high-availability:**
+
+| Deployment | Kapasitet | Måndedskostnad (NOK) | Egnet for |
+|------------|-----------|----------------------|-----------|
+| PTU 100K TPM | 100 000 tokens/min | ~25 000 – 35 000 | Production med høy trafikk |
+| S0 (fallback) | Variabel (quota-basert) | Kun usage | Burst capacity, failover |
+
+**Anbefaling for offentlig sektor:**
+- PTU for kritiske tjenester (Priority 1)
+- S0 i multiple regioner som fallback (Priority 2-3)
+- Estimert total kostnad: 30 000 – 50 000 NOK/måned for medium-sized løsning med high availability
+
+### Lisensiering
+
+**Azure OpenAI:**
+- Ingen spesifikke lisenskrav utover Azure-abonnement
+- PTU krever commitment (minimum 1 måned)
+- S0 er pay-as-you-go uten commitment
+
+**Azure AI Content Safety:**
+- Gratis tier: 5000 transactions/måned
+- Standard: ~0,008 NOK per transaction
+- For production: estimér 10 000 – 50 000 transactions/måned = 80 – 400 NOK/måned
+
+**Azure Monitor / Application Insights:**
+- Inkludert i de fleste Azure-planer
+- Pay-as-you-go for høy logging-volumm
+
+---
+
+## For arkitekten (Cosmo)
+
+### Spørsmål å stille kunden
+
+**Reliability:**
+1. Hva er akseptabel downtime for AI-funksjonaliteten? (99%, 99.9%, 99.99%)
+2. Kan applikasjonen fungere i degradert modus uten AI?
+3. Hvilke kritiske flows er avhengige av AI-responses?
+
+**Performance:**
+4. Hva er forventet query-volum per minutt/time?
+5. Hva er akseptabel latency ved normal drift? Ved failover?
+6. Hvor mange concurrent users forventes?
+
+**Cost:**
+7. Hva er budsjettet for AI-infrastruktur per måned?
+8. Er PTU (forutsigbar kostnad) foretrukket over pay-as-you-go?
+9. Hvor mye kan en enkelt feilet request koste (retry-limits)?
+
+**Security:**
+10. Hvilke typer innhold må filtreres (hate, violence, sexual, self-harm)?
+11. Må dere logge alle AI-interaksjoner for compliance?
+12. Finnes det PII i prompts eller responses som må håndteres spesielt?
+
+**Operations:**
+13. Har dere on-call team for incident response?
+14. Hvilke monitoring-verktøy brukes allerede?
+15. Skal recovery-actions være automatiske eller manuelt godkjente?
+
+### Decision Tree for Error Handling-Arkitektur
+
+```
+START: Velg error handling-strategi
+│
+├─ Forventet query-volum?
+│  ├─ Lav (<100/min) → SDK retry (default) + graceful degradation
+│  ├─ Medium (100-1000/min) → Multi-instance + circuit breaker
+│  └─ Høy (>1000/min) → Priority-based load balancing + bulkhead
+│
+├─ Kritikalitet av AI-responses?
+│  ├─ Nice-to-have → Graceful degradation med cached fallback
+│  ├─ Viktig → Circuit breaker + fallback prompting
+│  └─ Kritisk → Multi-region + automated failover + PTU
+│
+├─ Compliance-krav?
+│  ├─ Offentlig sektor → Content Safety + audit logging + GDPR-compliant error messages
+│  ├─ Finansiell → PCI-DSS + encrypted logging + incident reporting
+│  └─ Generell → Standard logging + monitoring
+│
+└─ Budsjett?
+   ├─ Begrenset → S0 + SDK retry + cached fallback
+   ├─ Medium → S0 multi-region + circuit breaker + selective PTU
+   └─ Høyt → PTU primary + S0 fallback + full automation
+```
+
+### Vanlige Antipatterns (unngå disse)
+
+❌ **Infinite retries uten backoff**
+- Resultat: Thundering herd, continued cost accumulation
+- Fix: Maks 3-5 retries med exponential backoff
+
+❌ **Ignorering av `Retry-After` header**
+- Resultat: Fortsatt throttling, waste of resources
+- Fix: Respekter alltid `Retry-After`, eller wait lenger
+
+❌ **Manglende fallback ved persistent failure**
+- Resultat: Total service unavailability
+- Fix: Graceful degradation med cached/default responses
+
+❌ **Logging av PII i error messages**
+- Resultat: GDPR-brudd, security incident
+- Fix: Sanitize alle logs, bruk correlation IDs
+
+❌ **Ukontrollert retry uten cost limits**
+- Resultat: Budget overrun
+- Fix: Sett Azure Cost Management budgets + alerts
+
+### Referansearkitektur for High-Availability AI-Applikasjon
+
+```
+User Request
+     │
+     ↓
+[Azure Front Door] ← Global load balancing
+     │
+     ↓
+[Azure API Management] ← llm-content-safety policy, rate limiting
+     │
+     ├─ Priority 1: [Azure OpenAI PTU - Region 1]
+     │                   ↑
+     │                   └─ Health probe (429 detection)
+     │
+     ├─ Priority 2: [Azure OpenAI S0 - Region 1]
+     │                   ↑
+     │                   └─ Health probe (429 detection)
+     │
+     └─ Priority 3: [Azure OpenAI S0 - Region 2]
+                         ↑
+                         └─ Health probe (429 detection)
+     │
+     ↓
+[Circuit Breaker in App Logic]
+     │
+     ├─ Success → Return response
+     │
+     ├─ Rate Limit → Failover to next priority
+     │
+     └─ Total Failure → Graceful Degradation
+                             │
+                             ├─ [Azure Cache for Redis] ← Cached responses
+                             └─ [Fallback Logic] ← Rule-based / default responses
+     │
+     ↓
+[Azure Monitor + Application Insights] ← Logging, alerting, automated healing
+```
+
+### Implementeringsrekkefølge (anbefalt)
+
+**Fase 1: Grunnleggende (MVP):**
+1. Bruk SDK retry defaults (2 forsøk)
+2. Implementer basic error handling (try-catch)
+3. Logg alle feil til Application Insights
+4. Graceful degradation med generic error messages
+
+**Fase 2: Production-Ready:**
+5. Implementer circuit breaker pattern
+6. Setup Azure AI Content Safety pre/post-filtering
+7. Multi-instance deployment i samme region
+8. Cached fallback-responses
+
+**Fase 3: High Availability:**
+9. Multi-region deployment
+10. Priority-based load balancing
+11. Automated failover
+12. PTU for kritiske workloads
+
+**Fase 4: Advanced:**
+13. Bulkhead pattern for multi-tenant
+14. Checkpoint pattern for long-running jobs
+15. Advanced fallback prompting (temperature, model switching)
+16. Automated healing med Azure Monitor action groups
+
+---
+
+## Kilder og verifisering
+
+**Primærkilder (Microsoft Learn):**
+1. [Azure OpenAI supported programming languages - Error handling](https://learn.microsoft.com/en-us/azure/ai-foundry/openai/supported-languages) – Offisiell dokumentasjon for retry-mekanismer i alle SDK-er
+2. [Architecture strategies for self-preservation](https://learn.microsoft.com/en-us/azure/well-architected/reliability/self-preservation) – Azure Well-Architected Framework reliability-mønstre
+3. [Azure OpenAI Priority-Based Load Balancer (GitHub)](https://github.com/Azure-Samples/openai-aca-lb) – Referanseimplementasjon av smart load balancing
+4. [Troubleshooting Azure OpenAI On Your Data](https://learn.microsoft.com/en-us/azure/ai-foundry/openai/how-to/on-your-data-best-practices) – Best practices for debugging og error handling
+5. [llm-content-safety policy (APIM)](https://learn.microsoft.com/en-us/azure/api-management/llm-content-safety-policy) – Content safety enforcement i API Management
+
+**Sekundærkilder:**
+6. [Azure OpenAI FAQ](https://learn.microsoft.com/en-us/azure/ai-foundry/openai/faq) – Vanlige feilsituasjoner og workarounds
+7. [OWASP Top 10 for LLM - Improper Output Handling](https://genai.owasp.org/llmrisk/llm052025-improper-output-handling/) – Sikkerhetshensyn ved output validation
+8. [Reliability Maturity Model](https://learn.microsoft.com/en-us/azure/well-architected/reliability/maturity-model) – Graceful degradation og testing
+
+**Verifisert:** Alle tekniske detaljer er hentet fra offisielle Microsoft-kilder (learn.microsoft.com, GitHub samples). Kodeeksempler er basert på offisielle SDK-dokumentasjon (januar 2026).
+
+**Confidence markers:**
+- **Høy confidence:** HTTP error codes, SDK retry defaults, `Retry-After` header, content safety policies
+- **Medium confidence:** Kostnadsestimater (prisene kan variere), spesifikke PTU-priser for norske kunder
+- **Lav confidence:** N/A – alle anbefalinger er basert på etablerte mønstre
+
+---
+
+**For Cosmo Skyberg:**
+Bruk denne referansen når kunden spør om:
+- "Hvordan håndterer vi feil fra Azure OpenAI?"
+- "Hva gjør vi hvis vi får 429 rate limit errors?"
+- "Kan AI-applikasjonen vår fortsette å fungere hvis Azure OpenAI er nede?"
+- "Hvordan unngår vi at usikre AI-responses ødelegger brukeropplevelsen?"
+- "Hva koster det å ha high availability for AI-tjenesten?"
+
+Kombiner denne kunnskapen med andre referanser om RAG, sikkerhet og kostnadsoptimalisering for helhetlige anbefalinger.