diff --git a/aws-sdp/POWER.md b/aws-sdp/POWER.md
new file mode 100644
index 0000000..9ef911d
--- /dev/null
+++ b/aws-sdp/POWER.md
@@ -0,0 +1,139 @@
+---
+name: aws-sdp
+description: AWS Service Delivery Program (SDP) documentation assistant. Helps AWS Partners create, complete and validate customer reference cases for APN designations.
+version: 1.0.0
+displayName: AWS SDP Agent for ITera
+author: ITERA Cloud Architecture Team - Stiven Avila
+keywords:
+  - SDP
+  - Service Delivery Program
+  - customer reference
+  - customer success
+  - APN
+  - AWS partner
+  - AWS Partner Network
+  - APN validation
+  - APN designation
+  - networking SDP
+  - EKS SDP
+  - ECS SDP
+  - Serverless SDP
+  - Database SDP
+  - Security SDP
+  - Migration SDP
+  - Data Analytics SDP
+  - Machine Learning SDP
+  - DevOps SDP
+  - SAP on AWS SDP
+  - Windows on AWS SDP
+  - VMware Cloud on AWS SDP
+  - Amazon Connect SDP
+  - Amazon EC2 for Windows Server SDP
+  - Amazon EC2 for Linux on AWS SDP
+  - Amazon RDS on AWS SDP
+  - Amazon Redshift on AWS SDP
+  - Amazon EMR on AWS SDP
+  - Amazon ElastiCache on AWS SDP
+  - Amazon DynamoDB on AWS SDP
+  - Amazon Neptune on AWS SDP
+  - Amazon DocumentDB on AWS SDP
+  - Amazon Keyspaces on AWS SDP
+  - Amazon Timestream on AWS SDP
+  - Amazon Quantum Ledger Database (QLDB) on AWS SDP
+  - Amazon Managed Streaming for Apache Kafka (MSK) on AWS SDP
+  - Amazon OpenSearch Service on AWS SDP
+  - Amazon Kinesis on AWS SDP
+  - Amazon Kinesis Data Firehose on AWS SDP
+  - Amazon Kinesis Data Analytics on AWS SDP
+  - Amazon Kinesis Video Streams on AWS SDP
+  - Amazon Athena on AWS SDP
+  - Amazon QuickSight on AWS SDP
+  - Amazon Managed Service for Apache Flink on AWS SDP
+  - Amazon Managed Service for Apache Flink on AWS SDP
+  - Amazon Managed Service for Apache Flink on AWS SDP
+  - Amazon Newtworking on AWS SDP
+  - case study 
+  - partner case study
+---
+
+# AWS Service Delivery Program (SDP) — Power
+
+You are an expert in AWS Service Delivery Program documentation. Your job is to help the ITERA team write, complete, and validate customer references to obtain and maintain SDP designations from AWS.
+
+## Onboarding
+
+When this power activates, follow these steps:
+
+1. **Identify the context**: Is a new case being created, an existing one being completed, or one being validated before submission to AWS?
+2. **Identify the target SDP**: Networking, EKS, ECS, Serverless, Database, Security, Migration, or other.
+3. **Gather inputs**: Request or read available project documents (proposals, closure reports, technical specs, architecture diagrams).
+4. **Guide the correct flow**: Use the steering files based on the task at hand.
+
+## Critical Rules
+
+- **NEVER fabricate data**: AWS manually verifies every case with the customer. Dates, Account IDs, services, and outcomes must be real and verifiable.
+- **Always include Account IDs** when available — they increase credibility with AWS.
+- **Architecture diagrams are mandatory**: Without a visual architecture, the case may be rejected.
+- **The customer must be able to confirm** everything documented — write in language the customer would recognize as their own.
+- **Measurable outcomes first**: AWS values concrete metrics over generic benefits.
+
+## SDP Form Fields
+
+Each customer reference must complete these fields:
+
+| Field | Key Notes |
+|---|---|
+| Name of the Publicly Available Case Study | Format: `[Customer] – [Solution] with [Main AWS Services]` |
+| Customer Challenge | Customer's perspective — do not mention the partner |
+| Proposed Solution | Detailed architecture, component by component |
+| Third-party Applications or Solutions | ISVs, external vendors, non-AWS tools |
+| How AWS is used | Table: AWS Service → Specific role in the solution |
+| Engagement Start Date | Kickoff or signed proposal date |
+| Engagement End Date | Formal closure report or delivery date |
+| Date Project Went into Production | Real go-live date, must be verifiable |
+| Result(s)/Outcomes | Prioritize measurable metrics |
+| Architecture Diagrams | PNG/JPG/PDF — mandatory attachment |
+
+## Available Steering Files
+
+Refer to these files based on the task:
+
+- `workflow-writing.md` — Step-by-step process for writing a case from project documents
+- `fields-detail.md` — Detailed field-by-field guide with examples and common mistakes
+- `outcomes-bank.md` — Bank of metrics and typical outcomes by SDP type
+- `validation-checklist.md` — Checklist before submitting to AWS
+
+## Quick Workflow
+
+```
+1. Read project documents (proposals, closure reports, technical specs)
+       ↓
+2. Extract: customer, AWS services, problem, solution, dates, outcomes
+       ↓
+3. Draft fields in order: Challenge → Solution → Services → Dates → Outcomes
+       ↓
+4. Build AWS services table
+       ↓
+5. Validate with checklist before submitting
+       ↓
+6. Generate final Word document (field by field matching the form)
+```
+
+## Supported SDPs and Expected Services
+
+| SDP | Minimum Expected AWS Services |
+|---|---|
+| **Networking** | VPC, Transit Gateway, Direct Connect or VPN, Route 53, Network Firewall or WAF |
+| **Containers EKS** | EKS, ECR, ELB, VPC, IAM, CloudWatch |
+| **Containers ECS** | ECS, ECR, Fargate or EC2, ELB, VPC |
+| **Serverless** | Lambda, API Gateway, DynamoDB or S3, IAM, CloudWatch |
+| **Database RDS** | RDS or Aurora, VPC, Subnets, Security Groups, CloudWatch |
+| **Security** | IAM, CloudTrail, Config, GuardDuty, Security Hub, WAF |
+| **Migration** | MGN or DMS, S3, EC2, VPC |
+
+## Notes About AWS Review
+
+- AWS verifies with the customer: the case must be accurate
+- Naming the customer's AWS account with an Account ID increases credibility
+- Production dates are critical: the project must already be in production
+- Without an attached architecture diagram, the case may be rejected
diff --git a/aws-sdp/steering/fields-detail.md b/aws-sdp/steering/fields-detail.md
new file mode 100644
index 0000000..3eed856
--- /dev/null
+++ b/aws-sdp/steering/fields-detail.md
@@ -0,0 +1,156 @@
+# Detailed Field Guide — With Examples and Common Mistakes
+
+## Field: Name of the Publicly Available Case Study
+
+**Format**: `[Customer] – [Solution Description] with [Main AWS Services]`
+
+**Good examples**:
+- "Comfandi – Network Infrastructure Transformation on AWS with Transit Gateway, Site-to-Site VPN, Network Firewall, CloudFront, and Route 53"
+- "Bancolombia – Microservices Platform on Amazon EKS with Multi-AZ High Availability"
+- "EPM – Real-Time Analytics with Serverless Architecture on AWS Lambda and Kinesis"
+
+**Common mistakes**:
+- "Infrastructure project for financial customer" — too vague
+- "AWS implementation for Comfandi" — doesn't mention services or solution
+- Just reading the name should identify which SDP it applies to
+
+---
+
+## Field: Customer Challenge
+
+**Ideal length**: 300–500 words
+
+**What AWS wants to see**:
+- A real business problem, not just a technical one
+- The impact of NOT solving the problem
+- Enough context to understand the scope of the engagement
+- The customer's language (as if the customer wrote it)
+
+**Common mistakes**:
+- Mentioning the partner: "Comfandi contacted ITERA to..."
+- Being generic: "they needed to improve their cloud infrastructure"
+- Mixing challenge and solution in the same paragraph
+- "The Fovis and Fosfec applications lacked centralized web perimeter protection, exposing them to OWASP threats with no network traffic visibility."
+
+**Opening templates by industry**:
+
+*Compensation fund / social sector:*
+> "[Customer] is one of the [adjective] family compensation funds in Colombia, with operations in [region] serving more than [N] beneficiaries. Its technology infrastructure supports critical applications for [subsidies/health/education] that require continuous availability."
+
+*Financial sector:*
+> "[Customer] operates in [N] countries with a [services] platform processing [N] transactions daily. The growing demand for secure connectivity between cloud environments and legacy systems represented a significant operational risk."
+
+---
+
+## Field: Proposed Solution
+
+**Level of detail expected by AWS**:
+
+| Element | Poor | Good |
+|---|---|---|
+| Service name | "database" | "Amazon Aurora PostgreSQL-Compatible" |
+| Configuration | "multi-zone" | "3 availability zones: us-east-1a, 1b, 1c" |
+| Network | "private VPC" | "VPC CIDR 10.249.36.0/22 with private subnets under Control Tower" |
+| Security | "with WAF" | "AWS WAF with 1 Web ACL, 9 custom rules, and 1 Managed Rule Group" |
+
+**Introductory paragraph template**:
+> "[Partner] designed and implemented a [type: network/container/serverless] architecture on AWS that [what it solves]. The solution integrates the following components..."
+
+**Services table template** (always include):
+```
+| AWS Service | Role in the Solution |
+|---|---|
+| AWS Transit Gateway | Central routing hub between N VPCs across [customer]'s accounts |
+| AWS Site-to-Site VPN | N encrypted tunnels connecting [A] to [B] |
+```
+
+---
+
+## Field: Third-party Applications or Solutions
+
+**When it applies**:
+- External CI/CD tools (Jenkins, GitLab, GitHub Actions)
+- Third-party monitoring (Datadog, New Relic, Grafana)
+- Identity providers (Keycloak, Okta, Active Directory)
+- On-premises systems connected to the solution
+- External providers connected via VPN/Direct Connect
+- IaC tools: Terraform, Pulumi, Ansible (if part of the delivered solution)
+
+**If no third parties**:
+> "No third-party solutions were used. The solution was implemented 100% on native AWS services."
+
+---
+
+## Field: How AWS Is Used as Part of the Solution
+
+**Recommended format**: table + integration flow paragraph
+
+**Tip**: Be specific per service. Examples:
+
+| Vague | Specific |
+|---|---|
+| "Amazon VPC for networking" | "Amazon VPC with CIDR 10.249.36.0/22, private subnets across 3 AZs under Control Tower" |
+| "CloudWatch for monitoring" | "CloudWatch for ingesting VPC Flow Logs (20 GB/month) and network traffic auditing" |
+| "S3 for storage" | "Amazon S3 as the origin for static assets distributed via CloudFront" |
+
+---
+
+## Date Fields
+
+### Important rules:
+- `Start ≤ End ≤ Production` — AWS checks for consistency
+- If there are multiple sub-projects, document the full range
+- Use the closure report date as the end reference when available
+- The project MUST already be in production — if not, it doesn't qualify for SDP
+
+### When there are multiple phases:
+```
+Start date: [date of the first sub-project]
+End date: [date of the last closure]
+Production date: [go-live date of the main component]
+```
+
+---
+
+## Field: Results/Outcomes
+
+### Value hierarchy for AWS:
+1. Business metrics (USD saved, % cost reduction, time-to-market)
+2. Measurable technical metrics (latency, uptime %, throughput RPS)
+3. perational improvements (reduced tickets, eliminated processes)
+4. Security improvements (achieved compliance, mitigated risks)
+
+### Templates by outcome type:
+
+**Connectivity/Networking**:
+> "Connectivity across [N] AWS accounts was consolidated via Transit Gateway, replacing bilateral peering management with a hub-and-spoke model with a single control point."
+
+**Security**:
+> "The centralized WAF with [N] active rules protects [N] applications against OWASP Top 10 threats, with full traffic visibility through VPC Flow Logs."
+
+**High availability**:
+> "The multi-AZ architecture guarantees continuous 7x24x365 availability with automatic failover in case of availability zone failures."
+
+**Content delivery**:
+> "CloudFront reduced static content delivery latency for [application] users in [region], with functional tests approved in both QA and production environments."
+
+---
+
+## Field: Architecture Diagrams
+
+**Accepted formats**: PNG, JPG, PDF
+
+**Diagram checklist**:
+- [ ] All AWS services in the case appear in the diagram
+- [ ] Data/connectivity flow between components is shown
+- [ ] Separate AWS accounts are identified (if applicable)
+- [ ] Availability zones are shown (if there is HA)
+- [ ] Connections to external/on-premises systems are shown
+
+**Recommended tools**:
+- draw.io / diagrams.net (free, official AWS icons available)
+- Official AWS Architecture Icons: https://aws.amazon.com/architecture/icons/
+- Cloudcraft (AWS-specialized)
+- Lucidchart
+
+**If the diagram doesn't exist**: flag it explicitly in the document and create a task for the technical team to produce it before submitting to AWS.
diff --git a/aws-sdp/steering/outcomes-bank.md b/aws-sdp/steering/outcomes-bank.md
new file mode 100644
index 0000000..008b9a0
--- /dev/null
+++ b/aws-sdp/steering/outcomes-bank.md
@@ -0,0 +1,347 @@
+# Outcomes and Metrics Bank by SDP Type
+
+Use this bank when the user doesn't have exact metrics available.
+Always prioritize real project data over these templates.
+
+---
+
+## SDP Networking
+
+**Centralized connectivity (Transit Gateway)**
+- "Connectivity across [N] AWS accounts was consolidated via Transit Gateway, eliminating the management of [N*(N-1)/2] bilateral peerings and simplifying routing to a single central hub."
+- "The hub-and-spoke architecture allows [customer]'s IT team to manage all network connectivity from a centralized Networking account."
+
+**Site-to-Site VPN**
+- "[N] AES-256 encrypted Site-to-Site VPN tunnels were established, eliminating the transmission of sensitive data over the public internet between [A] and [B]."
+- "The [N] integration environments with [external provider] (production, contingency, and testing) went live with end-to-end encryption."
+
+**WAF / Web perimeter security**
+- "The centralized WAF with [N] active rules protects [N] applications against the most common web threats (OWASP Top 10)."
+- "Enabling VPC Flow Logs with CloudWatch ingestion provides complete network traffic visibility, enabling anomaly detection and forensic auditing."
+
+**CloudFront + S3**
+- "The CloudFront distribution reduced static content delivery latency for [application] users by serving content from AWS edge locations."
+- "Deployment across QA and Production environments with approved functional tests ensures a validated continuous delivery pipeline."
+
+**High availability**
+- "The network infrastructure operates across 3 availability zones (us-east-1a, 1b, 1c), guaranteeing continuity in case of zone failures."
+- "7x24x365 availability documented and supported by a dedicated technical support team."
+
+---
+
+## SDP Containers (EKS)
+
+- "The multi-AZ EKS cluster guarantees high availability with automatic failover, with no service interruptions in case of zone failures."
+- "Migrating [application] to containers on EKS reduced deployment time from [X hours] to [Y minutes]."
+- "Horizontal Pod Autoscaler (HPA) absorbs traffic spikes automatically without requiring operations team intervention."
+- "New environment provisioning time was reduced from [X days] to [Y hours] through infrastructure as code."
+- "Separating workloads into Kubernetes namespaces improved security isolation between environments."
+
+---
+
+## SDP Containers (ECS / Fargate)
+
+- "Fargate eliminated the need to manage EC2 instances, reducing hours spent on OS patching and maintenance."
+- "ECS with Fargate automatically scales based on demand, optimizing costs by paying only for resources used."
+- "The CI/CD pipeline integrated with ECR reduced time-to-production for new releases."
+
+---
+
+## SDP Serverless
+
+- "Lambda with API Gateway supports up to [N] transactions per second without pre-provisioning infrastructure."
+- "The serverless model eliminated server management, reducing operational maintenance hours by [X]%."
+- "Event-driven architecture with Lambda reduced compute costs compared to the previous always-on EC2-based model."
+- "Time-to-market for new features was reduced by eliminating infrastructure provisioning cycles."
+
+---
+
+## SDP Database (RDS / Aurora)
+
+- "Aurora PostgreSQL with multi-AZ replication guarantees an RTO of less than [N] minutes and RPO of less than [N] minutes in case of failure."
+- "Migrating to Aurora Serverless v2 eliminated database over-provisioning, reducing monthly costs by [X]%."
+- "Production database availability of [99.9/99.99]% was achieved."
+- "RDS automated backups and point-in-time recovery ensure data protection without manual intervention."
+
+---
+
+## SDP Security
+
+- "AWS Security Hub centralizes security findings from [N] accounts in a single dashboard, reducing incident response time."
+- "GuardDuty detected and alerted on anomalous behavior within the first weeks of operation."
+- "The customer achieved compliance with [ISO 27001/SOC 2/PCI DSS] enabled by the implemented controls."
+- "AWS Config with custom rules ensures continuous compliance with corporate security policies."
+
+---
+
+## SDP Migration
+
+- "The migration of [N] servers to AWS was completed in [N weeks] with zero downtime for end users."
+- "Total infrastructure cost was reduced by [X]% compared to the previous on-premises model."
+- "The cloud-native architecture allows scaling resources in minutes, without hardware procurement cycles."
+
+---
+
+## SDP Data Analytics
+
+- "The data analytics platform on AWS reduced report generation time from [X hours] to [Y minutes], enabling near real-time business decision-making."
+- "Centralizing data pipelines on AWS eliminated [N] manual ETL processes, reducing data engineering overhead by [X]%."
+- "The scalable analytics architecture supports [N]x data volume growth without infrastructure re-provisioning."
+- "Data availability for business teams improved from [X]% to [99.9]% with automated pipeline monitoring and alerting."
+
+---
+
+## SDP Machine Learning
+
+- "Model training time was reduced by [X]% using Amazon SageMaker managed infrastructure compared to on-premises GPU clusters."
+- "The ML pipeline went from experimentation to production deployment in [N days], reducing time-to-value for AI initiatives."
+- "Automated model retraining and monitoring ensured prediction accuracy remained above [X]% in production."
+- "The customer reduced manual data labeling effort by [X]% using SageMaker Ground Truth."
+- "Model inference latency was reduced to under [N] milliseconds, enabling real-time prediction at scale."
+
+---
+
+## SDP DevOps
+
+- "CI/CD pipeline implementation reduced average deployment time from [X hours] to [Y minutes]."
+- "Deployment frequency increased from [X per month] to [Y per week] with automated pipelines and quality gates."
+- "Mean Time to Recovery (MTTR) was reduced from [X hours] to [Y minutes] through automated rollback mechanisms."
+- "Infrastructure provisioning time was reduced from [X days] to [Y minutes] using Infrastructure as Code with AWS CDK/CloudFormation."
+- "The team achieved [X]% reduction in production incidents through automated testing integrated into the CI/CD pipeline."
+
+---
+
+## SDP SAP on AWS
+
+- "SAP system performance improved by [X]% after migration to AWS, leveraging EC2 instances optimized for SAP HANA workloads."
+- "SAP environment provisioning time was reduced from [X weeks] to [Y hours] using AWS Launch Wizard for SAP."
+- "The customer achieved high availability for SAP with RPO < [N] minutes and RTO < [N] minutes using multi-AZ deployment."
+- "Total SAP infrastructure cost was reduced by [X]% by right-sizing instances and leveraging Reserved Instances."
+- "SAP system refresh cycles were reduced from [X days] to [Y hours] using automated snapshots and fast restore."
+
+---
+
+## SDP Windows on AWS
+
+- "Windows Server workloads were migrated to AWS with zero application downtime using AWS Application Migration Service."
+- "Windows licensing costs were reduced by [X]% through AWS License Included instances and BYOL optimization."
+- "Active Directory integration with AWS Managed Microsoft AD eliminated the need to manage on-premises domain controllers."
+- "Windows environment patching compliance reached [X]% using AWS Systems Manager Patch Manager."
+- "Remote desktop infrastructure costs were reduced by [X]% migrating to Amazon WorkSpaces."
+
+---
+
+## SDP VMware Cloud on AWS
+
+- "VMware workloads were migrated to VMware Cloud on AWS with no application refactoring required, reducing migration risk."
+- "The customer retained existing VMware operational tools and skills while gaining AWS infrastructure elasticity."
+- "Data center footprint was reduced by [X]% by consolidating VMware workloads on VMware Cloud on AWS."
+- "Disaster recovery RTO was reduced from [X hours] to [Y minutes] using VMware Site Recovery on AWS."
+- "Hardware refresh costs were eliminated by moving VMware workloads to AWS managed infrastructure."
+
+---
+
+## SDP Amazon Connect
+
+- "Contact center setup time was reduced from [X months] to [Y weeks] using Amazon Connect's cloud-native architecture."
+- "Agent productivity improved by [X]% through AI-powered features including Contact Lens real-time call analytics."
+- "Customer wait times were reduced by [X]% using Amazon Connect's intelligent routing and callback capabilities."
+- "Contact center infrastructure costs were reduced by [X]% by eliminating on-premises PBX hardware and licensing."
+- "The customer achieved [X]% improvement in First Contact Resolution (FCR) using Amazon Connect with integrated CRM."
+
+---
+
+## SDP Amazon EC2 for Windows Server
+
+- "Windows Server workload performance improved by [X]% by selecting EC2 instance types optimized for the specific workload profile."
+- "Infrastructure costs were reduced by [X]% through a combination of Reserved Instances and Savings Plans."
+- "Automated EC2 scaling policies eliminated over-provisioning, reducing idle compute costs by [X]%."
+- "Windows Server patch compliance reached [X]% using AWS Systems Manager across all EC2 instances."
+
+---
+
+## SDP Amazon EC2 for Linux on AWS
+
+- "Linux workload migration to EC2 was completed in [N weeks] with [X]% performance improvement over previous on-premises servers."
+- "Compute costs were reduced by [X]% by leveraging EC2 Spot Instances for non-critical batch workloads."
+- "Auto Scaling groups ensured application availability during traffic spikes while maintaining cost efficiency."
+- "EC2 instance right-sizing reduced monthly compute spend by [X]% without impacting application performance."
+
+---
+
+## SDP Amazon RDS on AWS
+
+- "RDS automated backups and multi-AZ replication guarantee an RTO of less than [N] minutes and RPO near zero."
+- "Database administration overhead was reduced by [X]% by offloading patching, backups, and replication to RDS managed service."
+- "Read replica deployment improved read query performance by [X]% for reporting workloads."
+- "Database storage costs were optimized by [X]% using RDS storage autoscaling instead of pre-provisioned capacity."
+
+---
+
+## SDP Amazon Redshift on AWS
+
+- "Data warehouse query performance improved by [X]x after migrating to Amazon Redshift compared to the previous on-premises solution."
+- "Data loading time for [N GB/TB] daily datasets was reduced from [X hours] to [Y minutes] using Redshift Spectrum and S3."
+- "Analytics infrastructure costs were reduced by [X]% using Redshift Serverless for variable query workloads."
+- "The customer enabled self-service analytics for [N] business users through Redshift integration with Amazon QuickSight."
+- "Concurrency scaling ensured consistent query performance even during peak analytics workloads with [N] simultaneous users."
+
+---
+
+## SDP Amazon EMR on AWS
+
+- "Big data processing jobs that previously ran for [X hours] on on-premises Hadoop clusters now complete in [Y minutes] on EMR."
+- "Data processing costs were reduced by [X]% using EMR with EC2 Spot Instances for transient clusters."
+- "The customer processes [N TB] of data daily using EMR, with automatic cluster scaling based on workload demand."
+- "Migration from on-premises Hadoop to EMR eliminated [N] servers and associated hardware maintenance costs."
+
+---
+
+## SDP Amazon ElastiCache on AWS
+
+- "Application response time was reduced by [X]% by caching frequently accessed data in ElastiCache, reducing database load."
+- "Database read traffic decreased by [X]% after implementing ElastiCache as a caching layer."
+- "ElastiCache multi-AZ with automatic failover ensures cache availability with RTO under [N] seconds."
+- "Session management was centralized using ElastiCache Redis, enabling stateless application scaling across [N] EC2 instances."
+
+---
+
+## SDP Amazon DynamoDB on AWS
+
+- "DynamoDB handles [N] million requests per day with single-digit millisecond latency at any scale."
+- "Database infrastructure management was eliminated by migrating to DynamoDB, reducing operational overhead by [X]%."
+- "DynamoDB on-demand capacity eliminated over-provisioning, reducing database costs by [X]% for variable traffic patterns."
+- "Global Tables enabled multi-region replication with under [N] milliseconds replication lag for globally distributed users."
+- "DynamoDB Streams enabled real-time event-driven architecture, replacing [N] scheduled batch jobs."
+
+---
+
+## SDP Amazon Neptune on AWS
+
+- "Graph query performance improved by [X]x compared to the previous relational database approach for relationship-heavy queries."
+- "Neptune managed service eliminated graph database administration overhead, reducing DBA time dedicated to the database by [X]%."
+- "Fraud detection accuracy improved by [X]% by leveraging Neptune's graph traversal capabilities for relationship analysis."
+- "Neptune enabled the customer to model and query [N] billion relationships with millisecond latency."
+
+---
+
+## SDP Amazon DocumentDB on AWS
+
+- "MongoDB-compatible workloads were migrated to DocumentDB with minimal application code changes, reducing migration effort by [X]%."
+- "DocumentDB managed service eliminated replica set management, reducing operational complexity significantly."
+- "Document database read performance improved by [X]% using DocumentDB read replicas for reporting workloads."
+- "Storage costs were reduced by [X]% with DocumentDB's distributed storage that automatically scales in 10 GB increments."
+
+---
+
+## SDP Amazon Keyspaces on AWS
+
+- "Apache Cassandra workloads were migrated to Amazon Keyspaces with no infrastructure management required."
+- "Keyspaces on-demand capacity mode eliminated capacity planning overhead for unpredictable Cassandra workloads."
+- "The customer achieved [99.99]% availability for Cassandra-compatible workloads using Keyspaces multi-AZ replication."
+- "Infrastructure costs were reduced by [X]% by eliminating self-managed Cassandra cluster operations."
+
+---
+
+## SDP Amazon Timestream on AWS
+
+- "Time-series data ingestion rate reached [N million] data points per second using Amazon Timestream's purpose-built architecture."
+- "Query performance on time-series data improved by [X]x compared to the previous relational database solution."
+- "IoT telemetry storage costs were reduced by [X]% using Timestream's automated data tiering between memory and magnetic stores."
+- "The customer reduced time-series data query complexity by leveraging Timestream's built-in time-series functions."
+
+---
+
+## SDP Amazon QLDB on AWS
+
+- "Audit trail integrity was guaranteed cryptographically using QLDB's immutable and verifiable ledger, eliminating the need for custom audit logging."
+- "Regulatory compliance requirements for data provenance were met using QLDB's complete transaction history."
+- "The customer reduced audit preparation time by [X]% with QLDB's built-in cryptographic verification capabilities."
+- "QLDB eliminated [N] custom audit tables and triggers from the relational database, simplifying the data model."
+
+---
+
+## SDP Amazon MSK (Managed Streaming for Apache Kafka) on AWS
+
+- "Kafka cluster provisioning time was reduced from [X days] to [Y hours] using Amazon MSK managed service."
+- "The customer streams [N million] events per day through MSK with end-to-end latency under [N] milliseconds."
+- "Kafka operational overhead was reduced by [X]% by offloading broker management, patching, and scaling to MSK."
+- "MSK multi-AZ deployment ensures message durability and streaming continuity in case of availability zone failures."
+- "Migration from self-managed Kafka to MSK eliminated [N] dedicated Kafka servers and associated maintenance costs."
+
+---
+
+## SDP Amazon OpenSearch Service on AWS
+
+- "Search query response time was reduced from [X seconds] to [Y milliseconds] after migrating to Amazon OpenSearch Service."
+- "Log analytics ingestion capacity scaled to [N GB] per day without infrastructure changes using OpenSearch managed service."
+- "The customer unified search and log analytics on a single OpenSearch domain, replacing [N] separate tools."
+- "OpenSearch Service automated snapshots and multi-AZ deployment ensure data durability and [99.9]% availability."
+
+---
+
+## SDP Amazon Kinesis on AWS
+
+**Kinesis Data Streams**
+- "Real-time data streaming latency was reduced to under [N] milliseconds, enabling immediate event processing at [N million] events/day."
+- "Kinesis Data Streams replaced [N] batch jobs with real-time pipelines, reducing data freshness from [X hours] to seconds."
+
+**Kinesis Data Firehose**
+- "Data delivery to S3, Redshift, and OpenSearch was fully automated with Kinesis Data Firehose, eliminating custom ETL code."
+- "Streaming data delivery costs were reduced by [X]% compared to the previous custom ingestion pipeline."
+- "Kinesis Firehose automatically scales to handle peak ingestion rates of [N GB/hour] without capacity planning."
+
+**Kinesis Data Analytics / Managed Apache Flink**
+- "Real-time fraud detection latency was reduced from [X minutes] (batch) to [N seconds] using Kinesis Data Analytics."
+- "The customer replaced [N] complex batch jobs with a single Apache Flink application on Managed Service for Apache Flink."
+- "Real-time dashboards were enabled by processing [N million] events per hour with sub-second analytical results."
+
+**Kinesis Video Streams**
+- "Video ingestion from [N] cameras was centralized on Kinesis Video Streams, eliminating on-premises video storage infrastructure."
+- "Real-time video analytics latency was reduced to [N seconds] using Kinesis Video Streams with Amazon Rekognition."
+
+---
+
+## SDP Amazon Athena on AWS
+
+- "Ad-hoc query costs were reduced by [X]% using Athena's pay-per-query model compared to always-on data warehouse clusters."
+- "Business teams can now query [N TB] of S3 data in seconds without requiring data warehouse provisioning or loading."
+- "Data lake query time was reduced by [X]% by converting raw data to Parquet format with Athena's columnar query optimization."
+- "The customer eliminated [N] ETL jobs by enabling direct S3 querying with Athena, reducing data pipeline complexity."
+
+---
+
+## SDP Amazon QuickSight on AWS
+
+- "Business intelligence deployment time was reduced from [X months] to [Y weeks] using QuickSight's managed BI service."
+- "Self-service analytics was enabled for [N] business users without requiring SQL expertise, through QuickSight's visual interface."
+- "BI infrastructure costs were reduced by [X]% using QuickSight's pay-per-session pricing compared to traditional BI tools."
+- "Dashboard load time improved by [X]% using QuickSight SPICE in-memory engine for frequently accessed datasets."
+- "The customer consolidated [N] separate reporting tools into a single QuickSight deployment, reducing maintenance overhead."
+
+---
+
+## Generic Useful Metrics (when no exact data is available)
+
+When no numerical metrics are available, document at least:
+
+- Number of AWS accounts integrated in the solution
+- Number of environments covered (dev, QA, staging, production)
+- Number of applications protected or connected
+- Number of regions or AZs used
+- Number of tunnels/connections established
+- Number of security rules configured
+- Before vs. after state description (descriptive but verifiable)
+
+---
+
+## How to Get Metrics from the Customer
+
+If no documented metrics are available, ask the customer contact:
+
+1. How long did the process that is now automated take before?
+2. How many connectivity/security incidents did they have before vs. now?
+3. How much were they spending on infrastructure before? How much now with AWS?
+4. How many people were needed to manage X before vs. now?
+5. What is the recovery time after failures now vs. before?
+6. How many applications or users benefit from the solution?
\ No newline at end of file
diff --git a/aws-sdp/steering/validation-checklist.md b/aws-sdp/steering/validation-checklist.md
new file mode 100644
index 0000000..71290c0
--- /dev/null
+++ b/aws-sdp/steering/validation-checklist.md
@@ -0,0 +1,108 @@
+# Validation Checklist — Before Submitting to AWS
+
+Run this full validation before submitting any customer reference to the APN portal.
+
+---
+
+## Content Validation
+
+### Mandatory fields
+- [ ] **Case name** is complete and mentions the AWS services of the target SDP
+- [ ] **Customer challenge** has at least 3 paragraphs and describes a real, specific problem
+- [ ] **Proposed solution** describes the architecture component by component
+- [ ] **AWS services table** is included with the specific role of each service
+- [ ] **Third parties/ISVs** are listed (or explicitly stated as not applicable)
+- [ ] **All three dates** are complete: start, end, production
+- [ ] **Outcomes** include at least 3 documented results
+- [ ] **Diagrams** are identified and ready to attach
+
+### Content quality
+- [ ] The challenge does NOT mention the partner/implementer
+- [ ] The solution names AWS services with their exact and complete names
+- [ ] Dates are consistent: start ≤ end ≤ production
+- [ ] Outcomes are verifiable by the customer (not fabricated)
+- [ ] At least one AWS Account ID of the customer is included
+- [ ] Language is professional and can be understood without internal context
+
+---
+
+## Technical Validation
+
+### AWS Services
+- [ ] Listed services correspond to the SDP being applied for
+- [ ] Services are in production (not just planned or in development)
+- [ ] Mentioned Account IDs are correct for the customer
+
+### For Networking SDP specifically:
+- [ ] At least one of the following is mentioned: Transit Gateway, Direct Connect, Site-to-Site VPN
+- [ ] Amazon VPC is mentioned with subnet configuration
+- [ ] If WAF: number of rules and Web ACLs is specified
+- [ ] If CloudFront: origin configuration is mentioned (S3 or ALB)
+- [ ] If Route 53: DNS role in the solution is described
+
+---
+
+## Date Validation
+
+| Check | OK? |
+|---|---|
+| Start date ≤ end date | [ ] |
+| End date ≤ production date (or equal) | [ ] |
+| Project is already in production (not planned) | [ ] |
+| Dates match supporting documents (closure reports, proposals) | [ ] |
+| If sub-projects exist, all dates are consistent | [ ] |
+
+---
+
+## Diagram Validation
+
+- [ ] At least one architecture diagram is ready to attach
+- [ ] The diagram shows all AWS services mentioned in the case
+- [ ] The diagram is in PNG, JPG, or PDF format
+- [ ] The diagram is readable (not too small or compressed)
+- [ ] If multiple AWS accounts exist, the diagram clearly distinguishes them
+
+**If no diagram exists**: STOP — do not submit until one is available. It is a mandatory requirement.
+
+---
+
+## Customer Validation
+
+- [ ] A customer contact is identified who can validate the case with AWS
+- [ ] The contact has a relevant title (IT Manager, Architect, CTO, etc.)
+- [ ] The customer has agreed to be referenced publicly (or privately)
+- [ ] Customer data (name, Account ID, industry) is correct
+
+---
+
+## Final Submission Validation
+
+- [ ] The Word document is complete and well formatted
+- [ ] The architecture diagram is attached as a separate file
+- [ ] Customer contact details are ready for the APN form
+- [ ] The target SDP has the minimum required services
+- [ ] Spelling and professional writing have been reviewed
+
+---
+
+## Red Flags (do not submit if any of these apply)
+
+- Production dates in the future
+- No architecture diagram
+- Outcomes the customer could not confirm
+- Incorrect or fictitious Account IDs
+- AWS services not yet in production
+- No customer contact identified for AWS validation
+- The case mixes services from multiple SDPs without a clear focus
+
+---
+
+## Supporting Documents to Keep on File
+
+Save these alongside the case study in case AWS requests evidence:
+
+1. Customer-signed closure report
+2. Accepted economic proposal or SOW
+3. Technical spec / Architecture requirements document
+4. AWS console screenshots showing deployed services
+5. Architecture diagram in editable format (draw.io, Lucidchart)
diff --git a/aws-sdp/steering/workflow-writing.md b/aws-sdp/steering/workflow-writing.md
new file mode 100644
index 0000000..483eec8
--- /dev/null
+++ b/aws-sdp/steering/workflow-writing.md
@@ -0,0 +1,123 @@
+# Workflow: Writing an SDP Customer Reference from Project Documents
+
+Follow this process when the user has project documents and needs to write a customer reference case.
+
+## Step 1 — Gather and Read Documents
+
+Request or read the following documents in priority order:
+
+| Document | What to Extract |
+|---|---|
+| Closure report / delivery acceptance | Real dates, delivered scope, customer signatories |
+| Technical spec / Architecture doc | AWS services, architecture, Account IDs, subnets, configurations |
+| Economic proposal / SOW | Start date, original scope, proposed services |
+| Architecture diagrams | Attach directly to the SDP form |
+| Emails or meeting minutes | Additional context, outcomes mentioned by the customer |
+
+## Step 2 — Extract Key Information
+
+With the available documents, identify and note:
+
+**About the customer:**
+- Full name and type of organization (sector, country)
+- Involved AWS Account ID(s)
+- Contact who can validate the case with AWS (name + title)
+
+**About the project:**
+- Full list of AWS services used
+- Original problem that motivated the engagement
+- Dates: start, end, go-live (if sub-projects exist, dates for each)
+- Third-party tools involved
+
+**About the outcomes:**
+- Any documented metrics (latency, cost, availability, time)
+- Clear qualitative benefits even without exact numbers
+- Resolved problems that are verifiable by the customer
+
+## Step 3 — Draft "Customer Challenge" Field
+
+**Length**: 3–5 paragraphs (300–500 words)
+
+**Structure**:
+1. Customer context (who they are, industry, scale of operations)
+2. Specific technical problem (what wasn't working or was missing)
+3. Why it was critical or urgent to solve
+4. Limitations of the previous approach (if applicable)
+
+**Rules**:
+- Write from the customer's perspective
+- Do NOT mention the partner/implementer in this section
+- Use language the customer would recognize as their own
+- Avoid generic phrases like "they needed to improve their cloud infrastructure"
+
+**Example of a strong opening**:
+> "[Customer] operates [N] business-critical applications distributed across [N] AWS accounts under an AWS Control Tower organization. Without a centralized network layer, each new project required manually configuring bilateral connectivity, increasing operational risk and deployment lead times."
+
+## Step 4 — Draft "Proposed Solution" Field
+
+**Length**: 4–7 technical paragraphs + services table
+
+**Structure**:
+1. Introductory paragraph: high-level architecture overview
+2. One paragraph per major component (use exact AWS service names)
+3. Mandatory table: AWS Service | Role in the solution
+4. Mention of the Well-Architected Framework if applicable
+
+**Expected level of detail**:
+- Exact names: "Amazon Aurora PostgreSQL" not "database"
+- Relevant configurations: number of AZs, CIDRs, number of instances
+- Data flow between components
+
+**Service table template**:
+```
+| AWS Service | Role in the Solution |
+|---|---|
+| [Service] | [What it specifically does in this project] |
+```
+
+## Step 5 — Complete Date Fields
+
+If there are multiple sub-projects, document dates per sub-project:
+
+```
+Start date: [date of first kickoff or accepted proposal]
+End date: [date of last closure report]
+Production date: [real go-live date, most recent if phased]
+```
+
+If there is only one closure report, use that date as the reference for end and production.
+
+## Step 6 — Draft "Results/Outcomes" Field
+
+**Impact order for AWS**:
+1. Business metrics (cost savings, speed, revenue)
+2. Measurable technical metrics (latency ms, uptime %, throughput RPS)
+3. Operational improvements (reduced tickets, eliminated manual processes)
+4. Security improvements (achieved compliance, mitigated risks)
+
+**Recommended format** (numbered list, each item with bold title + description):
+```
+1. **[Outcome Name]**: [Verifiable description of the benefit achieved].
+2. **[Outcome Name]**: [Verifiable description of the benefit achieved].
+```
+
+**If no exact metrics are available**, use:
+- Number of accounts/environments/applications connected or protected
+- Elimination of a specific risk or problem
+- Before vs. after description of the state
+
+## Step 7 — Architecture Diagrams Section
+
+Always include this section indicating:
+- Which documents contain the existing diagrams
+- Which diagrams should be attached to the form
+- If no diagram exists, clearly flag it so the team can create one
+
+## Step 8 — Generate Word Document
+
+Once all fields are drafted, generate a professional `.docx` using `docx-js` with:
+- Header with customer name and target SDP
+- Each field as a section with a heading title
+- AWS services table with color formatting
+- Clear and organized dates section
+- Footer with customer contact info and ITERA team details