diff --git a/README.md b/README.md
index 098873c..029cba7 100644
--- a/README.md
+++ b/README.md
@@ -23,7 +23,7 @@ npx skills add oracle/skills/graal
 
 ## Domains
 
-- `db/` is the active Oracle Database domain and includes database, ORDS, SQLcl, framework, container, and agent workflow skills.
+- `db/` is the active Oracle Database domain and includes database, ORDS, SQLcl, framework, Maximum Availability Architecture, container, and agent workflow skills.
 - `oci/` is the root for future Oracle Cloud Infrastructure skills.
 - `fusion/` is the root for future Oracle Fusion skills.
 - `apex/` is the root for future Oracle APEX skills.
@@ -50,6 +50,7 @@ npx skills add oracle/skills/graal
 │   ├── devops/
 │   ├── features/
 │   ├── frameworks/
+│   ├── maa/
 │   ├── migrations/
 │   ├── monitoring/
 │   ├── ords/
diff --git a/db/SKILL.md b/db/SKILL.md
index be2a7fb..873128c 100644
--- a/db/SKILL.md
+++ b/db/SKILL.md
@@ -1,11 +1,11 @@
 ---
 name: db
-description: Oracle Database guidance for SQL, PL/SQL, SQLcl, ORDS, administration, app development, performance, security, migrations, and agent-safe database workflows. Use when the user asks to write, edit, rewrite, review, format, debug, tune, or explain SQL; create or refactor PL/SQL; use SQLcl, Liquibase, ORDS, JDBC, node-oracledb, Python, Java, .NET, or database frameworks; troubleshoot queries, sessions, locks, waits, indexes, optimizer plans, AWR, ASH, migrations, schemas, users, roles, privileges, backup, recovery, Data Guard, RAC, multitenant, containers, monitoring, auditing, encryption, VPD, or safe agent database operations.
+description: Oracle Database guidance for SQL, PL/SQL, SQLcl, ORDS, administration, app development, performance, security, migrations, Maximum Availability Architecture (MAA), and agent-safe database workflows. Use when the user asks to write, edit, rewrite, review, format, debug, tune, or explain SQL; create or refactor PL/SQL; use SQLcl, Liquibase, ORDS, JDBC, node-oracledb, Python, Java, .NET, or database frameworks; troubleshoot queries, sessions, locks, waits, indexes, optimizer plans, AWR, ASH, migrations, schemas, users, roles, privileges, backup, recovery, Data Guard, RAC, Exadata, MAA tiers, Oracle Update Advisor, multicloud MAA, multitenant, containers, monitoring, auditing, encryption, VPD, or safe agent database operations.
 ---
 
 # Oracle Database Skills
 
-This domain contains Oracle Database skills for administration, SQL and PL/SQL development, performance tuning, security, ORDS, SQLcl, migrations, frameworks, OCR container guidance, and agent-safe database workflows.
+This domain contains Oracle Database skills for administration, SQL and PL/SQL development, performance tuning, security, ORDS, SQLcl, migrations, Maximum Availability Architecture, frameworks, OCR container guidance, and agent-safe database workflows.
 
 ## How to Use This Domain
 
@@ -26,6 +26,7 @@ db/
 ├── devops/
 ├── features/
 ├── frameworks/
+├── maa/
 ├── migrations/
 ├── monitoring/
 ├── ords/
@@ -50,6 +51,7 @@ db/
 | Schema migrations, online operations, edition-based redefinition, testing, version control | `db/devops/` |
 | AQ, DBMS_SCHEDULER, materialized views, DBLinks, APEX, vector search, SELECT AI | `db/features/` |
 | SQLAlchemy, Django, Pandas, Spring JPA, MyBatis, TypeORM, Sequelize, Dapper, GORM | `db/frameworks/` |
+| Maximum Availability Architecture, MAA tiers, Data Guard/RAC/Exadata MAA, Oracle Update Advisor, Edition-Based Redefinition, ZDLRA, multicloud MAA, mission-critical availability | `db/maa/` |
 | Migrations from PostgreSQL, MySQL, SQL Server, MongoDB, Snowflake, and more | `db/migrations/` |
 | Alert log, ADR, health monitor, space management, top SQL | `db/monitoring/` |
 | ORDS architecture, installation, REST design, authentication, monitoring, ORDS Concert Sample App | `db/ords/` |
@@ -69,6 +71,11 @@ db/
 - `db/devops/schema-migrations.md`
 - `db/agent/schema-discovery.md`
 - `db/containers/container-selection-matrix.md`
+- `db/maa/maa-overview.md`
+- `db/maa/maa-tiers.md`
+- `db/maa/data-guard-maa.md`
+- `db/maa/patching-update-advisor.md`
+- `db/maa/source-index.md`
 - `db/backup-recovery/autonomous-recovery-service.md`
 - `db/backup-recovery/cloud-protect.md`
 
@@ -82,3 +89,4 @@ db/
 | Build a Java JDBC service | `java-oracle-jdbc` → `java-oracle-jdbc/dependencies` → `java-oracle-jdbc/connections` → `java-oracle-jdbc/sql` → `java-oracle-jdbc/pooling-production` |
 | Perform agent-safe schema change | `schema-discovery` → `destructive-op-guards` → `idempotency-patterns` → `schema-migrations` |
 | Set up AI-driven database access via MCP | `sqlcl-basics` (save connections) → `security/privilege-management` (least-privilege user) → `sqlcl-mcp-server` (configure + start) |
+| Answer an MAA architecture or availability question | `maa-overview` → focused MAA topic file → `source-index` when citations are needed |
diff --git a/db/maa/application-continuity.md b/db/maa/application-continuity.md
new file mode 100644
index 0000000..5407c64
--- /dev/null
+++ b/db/maa/application-continuity.md
@@ -0,0 +1,48 @@
+# Application Continuity And Client Failover
+
+Use this file when users ask how to reduce or hide application interruption during database outages, planned maintenance, service relocation, RAC node failure, Data Guard switchover/failover, or connection pool disruptions.
+
+## Core Guidance
+
+- Availability is not complete until clients reconnect to the right service quickly and safely.
+- Use database services as the unit of availability and workload placement. Do not connect applications to individual instances unless there is a deliberate reason.
+- Use HA-aware connection strings with multiple addresses, appropriate connect timeouts, retry behavior, and service names.
+- Use Fast Application Notification (FAN) so clients and pools react quickly to service up/down and load events.
+- Use Transaction Guard to determine transaction outcome after recoverable errors.
+- Use Application Continuity or Transparent Application Continuity where supported to replay safe requests and mask outages from users.
+- Use connection draining and service relocation for planned maintenance instead of abruptly breaking sessions.
+
+## RAC And Data Guard Application Pattern
+
+| Layer | MAA expectation |
+|---|---|
+| Database services | Define services by workload and role; use role-based services for Data Guard when appropriate. |
+| Connection string | Include all relevant SCAN/listener endpoints and tune timeouts so failures are detected quickly. |
+| Driver/pool | Use Oracle drivers/pools that understand FAN, Runtime Load Balancing, and Application Continuity features. |
+| Application | Make requests replay-safe where possible; handle non-replayable calls explicitly. |
+| Operations | Test service relocation, node failure, switchover, failover, and planned maintenance paths. |
+
+## What Can And Cannot Be Hidden
+
+- Connection failures can often be shortened with HA connection strings, FAN, and pool integration.
+- Planned maintenance interruption can often be minimized with service draining and rolling operations.
+- Some in-flight work can be replayed when Application Continuity requirements are met.
+- Non-idempotent external side effects, unprotected session state, and unsafe calls may still require application logic.
+- Data Guard role transitions require service and client behavior to be designed and tested; the database switchover alone is not the full user experience.
+
+## Common Mistakes
+
+- Using a single host in the connect descriptor.
+- Setting long TCP/connect timeouts that make failover appear hung.
+- Forgetting role-based services after Data Guard switchover.
+- Assuming AC/TAC can replay every request without checking driver, service, and application requirements.
+- Testing only database role transition and not the application pool behavior.
+
+## Sources
+
+- RAC Administration and Deployment Guide: https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/index.html
+- RAC technical architecture: https://docs.oracle.com/en/database/oracle/oracle-database/26/adrac/index.html
+- Continuous Availability: https://www.oracle.com/a/ocom/docs/database/continuous-availabiliity.pdf
+- Fast Application Notification: https://www.oracle.com/a/ocom/docs/database/fast-application-notification.pdf
+- Application checklist for continuous availability: https://www.oracle.com/a/tech/docs/application-checklist-for-continuous-availability-for-maa.pdf
+- High availability connection string: https://blogs.oracle.com/maa/the-high-availability-connection-string-explained
diff --git a/db/maa/backup-recovery-zdlra.md b/db/maa/backup-recovery-zdlra.md
new file mode 100644
index 0000000..3308fec
--- /dev/null
+++ b/db/maa/backup-recovery-zdlra.md
@@ -0,0 +1,48 @@
+# Backup, Recovery, RMAN, And ZDLRA
+
+Use this file for MAA backup/recovery strategy, RMAN, restore validation, corruption protection, recovery objectives, and Zero Data Loss Recovery Appliance positioning.
+
+## Core Guidance
+
+- Backups remain mandatory even with RAC, Data Guard, or Active Data Guard.
+- Design recovery around both RTO and recovery point requirements, including logical corruption and user error.
+- Validate restore and recovery, not just backup job success.
+- Keep backup retention, immutability, encryption, offsite copies, and compliance requirements explicit.
+- Use standby databases to offload backups where it fits the architecture and licensing.
+- Use ZDLRA when the requirement is centralized, database-aware protection, incremental-forever strategy, recovery validation, and stronger recovery automation for Oracle databases.
+
+## Data Guard Versus Backup
+
+| Capability | Data Guard | Backup/RMAN/ZDLRA |
+|---|---|---|
+| Fast database failover | Yes | No |
+| Protection from site failure | Yes, with remote standby | Yes, depending on copy location and restore time |
+| Point-in-time recovery | Limited by standby/flashback strategy | Core capability |
+| Logical error recovery | Not sufficient by itself | Core capability |
+| Long retention | Not the primary purpose | Core capability |
+| Corruption detection/repair workflow | Helps in database-aware ways | Required for full recovery strategy |
+
+## Recovery Readiness Checklist
+
+- Define the recovery scenarios: media failure, site loss, operator error, corruption, ransomware, failed patch, failed deployment.
+- Confirm where backups live and whether they survive the failure domain.
+- Test restore to alternate location.
+- Test point-in-time recovery.
+- Track backup encryption keys and wallet/secret availability.
+- Monitor backup age, recoverability, failed jobs, restore performance, and recovery catalog health where used.
+
+## Common Mistakes
+
+- Reporting “backup succeeded” without proving restore works.
+- Keeping backups in the same failure domain as the database.
+- Assuming Data Guard protects against all logical mistakes.
+- Ignoring recovery time for very large databases.
+- Not testing wallet/key availability during restore.
+
+## Sources
+
+- Backup and Recovery IAD: https://docs.oracle.com/en/database/oracle/oracle-database/26/bkupr/index.html
+- Backup and Recovery User's Guide: https://docs.oracle.com/en/database/oracle/oracle-database/26/bradv/index.html
+- Backup and Recovery Reference: https://docs.oracle.com/en/database/oracle/oracle-database/26/rcmrf/index.html
+- ZDLRA Protected Database Configuration Guide: https://docs.oracle.com/en/engineered-systems/zero-data-loss-recovery-appliance/23.1/ampdb/index.html
+- ZDLRA Administrator's Guide: https://docs.oracle.com/en/engineered-systems/zero-data-loss-recovery-appliance/23.1/amagd/index.html
diff --git a/db/maa/data-guard-maa.md b/db/maa/data-guard-maa.md
new file mode 100644
index 0000000..590addb
--- /dev/null
+++ b/db/maa/data-guard-maa.md
@@ -0,0 +1,57 @@
+# Data Guard MAA Guidance
+
+Use this file for the MAA layer of Data Guard and Active Data Guard decisions. For low-level Data Guard syntax and administration mechanics, lean on existing Oracle Database Data Guard skills or current product documentation.
+
+## MAA Positioning
+
+- Data Guard is the primary Oracle database-aware DR technology for physical standby, role transition, and redo-based recovery across sites or clouds.
+- Active Data Guard adds read-only workload offload, reporting, backups from standby, and additional use cases while redo apply continues.
+- Data Guard Broker should be the default management path for MAA-style operations because it centralizes configuration, validation, switchover, failover, and Fast-Start Failover.
+- Use Data Guard for planned maintenance as well as disaster recovery: standby-first patching, switchover, validation, and fallback planning reduce outage risk.
+
+## Key Architecture Decisions
+
+| Decision | Guidance |
+|---|---|
+| Protection mode | Match RPO and latency. Maximum Performance favors distance and commit latency; Maximum Availability targets zero/near-zero data loss where SYNC latency is acceptable; Maximum Protection is specialized and can stop the primary if protection is unavailable. |
+| Transport | Choose SYNC/ASYNC based on RPO, distance, latency, redo rate, and application commit sensitivity. Validate with workload, not only network theory. |
+| Standby type | Physical standby is the default for broad compatibility and DR. Snapshot standby is for temporary testing. Logical approaches or GoldenGate solve different requirements. |
+| Broker | Prefer Broker for operational consistency, validation, and role transitions. |
+| FSFO | Use when automatic failover is required and the organization accepts the operational model. Deploy observers carefully and test failure conditions. |
+| Client failover | Data Guard alone does not make applications transparent. Pair role transitions with services, connection strings, FAN, AC/TAC, and pool behavior. |
+
+## Operational Best Practices
+
+- Configure standby redo logs appropriately and validate real-time apply when low RPO matters.
+- Enable and test Flashback Database where reinstatement after failover is part of the operational plan.
+- Run regular switchovers, not just tabletop exercises.
+- Monitor transport lag, apply lag, archive gaps, observer health, database role, protection level, and service placement.
+- Size and test redo transport for peak redo generation, not only average redo rate.
+- Document decision criteria for switchover, failover, reinstate, and fallback. During an incident, ambiguity burns RTO.
+- For hybrid or multicloud deployments, validate network latency, routing, security controls, DNS behavior, and operational ownership across providers.
+
+## Standby-First Maintenance Pattern
+
+1. Validate the Data Guard configuration and application failover readiness.
+2. Patch or upgrade the standby side first where supported.
+3. Allow redo/apply to catch up and validate health.
+4. Switchover to make the patched standby primary.
+5. Patch the former primary.
+6. Optionally switch back after validation, or keep the new role if that is the operational standard.
+
+## Common Mistakes
+
+- Failing over manually without checking for redo gaps and data loss implications.
+- Having Data Guard configured but not application services and connection strings.
+- Letting the standby lag silently grow until RTO/RPO assumptions are false.
+- Using storage replication as if it provided the same database-aware protection as Data Guard.
+- Not testing reinstate after failover.
+
+## Sources
+
+- Data Guard Concepts and Administration: https://docs.oracle.com/en/database/oracle/oracle-database/26/sbydb/index.html
+- Data Guard Broker: https://docs.oracle.com/en/database/oracle/oracle-database/26/dgbkr/index.html
+- Data Guard patch maintenance: https://docs.oracle.com/en/database/oracle/oracle-database/26/dbpdg/index.html
+- Active Data Guard scaling context: https://blogs.oracle.com/maa/application-and-ai-scalability-with-oracle-active-data-guard
+- Redo transport throughput context: https://blogs.oracle.com/maa/higher-data-guard-redo-transport-throughput
+- ADG vs. storage mirroring: https://www.oracle.com/docs/tech/adg-vs-storage-mirroring-v1.pdf
diff --git a/db/maa/edition-based-redefinition.md b/db/maa/edition-based-redefinition.md
new file mode 100644
index 0000000..ba9910a
--- /dev/null
+++ b/db/maa/edition-based-redefinition.md
@@ -0,0 +1,42 @@
+# Edition-Based Redefinition
+
+Use this file for zero or near-zero downtime application upgrades that involve database object changes. EBR is an application/database deployment technique, not a DR substitute.
+
+## When EBR Fits
+
+- The application requires database schema changes while existing users continue running.
+- Changes involve editionable objects such as PL/SQL, views, synonyms, and related application-facing database APIs.
+- The team can route old and new application code to different editions during rollout.
+- The deployment can be broken into phases: prepare, expose compatibility layer, run old and new code, cut over, and clean up.
+
+## Core Concepts
+
+- An edition provides a private namespace for editioned objects.
+- Editioning views decouple application-facing table shape from physical table changes.
+- Crossedition triggers can keep old and new representations synchronized during online rollout.
+- Sessions run in an edition; application services or connection configuration can control which edition new sessions use.
+- Cleanup is a separate step after confidence is established.
+
+## MAA Guidance
+
+- Use EBR for application upgrade downtime, not infrastructure failure.
+- Combine EBR with RAC services and connection draining for controlled rollout.
+- Combine EBR with Data Guard only after considering redo/apply impact and operational sequencing.
+- Test rollback/fallback explicitly. EBR can make fallback easier, but only if the deployment plan preserves compatibility.
+- Keep external side effects, batch jobs, and non-editioned objects in the plan.
+
+## Common Mistakes
+
+- Treating EBR as a switch that makes any schema change online without design.
+- Forgetting that tables are not editioned in the same way as PL/SQL and views.
+- Skipping editioning views and exposing physical table changes directly to the application.
+- Not planning cleanup of old editions and compatibility objects.
+- Rolling out application servers without controlling which edition their sessions use.
+
+## Sources
+
+- EBR overview: https://www.oracle.com/database/technologies/high-availability/ebr.html
+- EBR documentation: https://docs.oracle.com/en/database/oracle/oracle-database/26/adfns/editions.html
+- EBR technical deep dive: https://www.oracle.com/a/tech/docs/ebr-technical-deep-dive-overview.pdf
+- EBR FAQ: https://www.oracle.com/a/tech/docs/ebr-faq.pdf
+- EBR MAA blog: https://blogs.oracle.com/maa/edition-based-redefinition-a-solution-for-zero-downtime-application-upgrades
diff --git a/db/maa/maa-overview.md b/db/maa/maa-overview.md
new file mode 100644
index 0000000..2dd831a
--- /dev/null
+++ b/db/maa/maa-overview.md
@@ -0,0 +1,44 @@
+# Oracle Maximum Availability Architecture (MAA)
+
+## Overview
+
+Use this file to answer Oracle Maximum Availability Architecture questions with practical MAA guidance, not by loading a large list of links. Start with the routing table, read only the topic file needed for the user's question, and open `source-index.md` only when citations, source verification, or a less common source is needed.
+
+## Routing
+
+| User asks about | Read |
+|---|---|
+| MAA principles, tier selection, RTO/RPO framing, Bronze/Silver/Gold/Platinum/Diamond | `maa-tiers.md` |
+| Data Guard, Active Data Guard, role transitions, standby-first maintenance, redo transport, hybrid cloud DR | `data-guard-maa.md` |
+| RAC, Exadata, engineered systems, local HA, consolidation, platform maintenance | `rac-exadata.md` |
+| Services, client failover, continuous availability, connection strings, FAN, AC/TAC | `application-continuity.md` |
+| Patching, maintenance, Oracle Update Advisor, building Oracle Update Advisor clients or agents | `patching-update-advisor.md` |
+| Edition-Based Redefinition or zero-downtime application upgrades | `edition-based-redefinition.md` |
+| Oracle multicloud, Oracle Database@Azure/AWS/GCP, OCI Full Stack DR in OCI, regional and DNS failures | `multicloud-dr.md` |
+| Backup strategy, RMAN, restore validation, ZDLRA, corruption protection | `backup-recovery-zdlra.md` |
+| Exact source links, citations, or less common public docs/blogs | `source-index.md` |
+
+## Answering Rules
+
+1. Answer from the topic guidance first. Do not make the source index the primary context.
+2. State assumptions that materially affect the recommendation: Oracle Database release, deployment model, cloud/on-premises target, RAC/Data Guard/Exadata use, latency, RTO/RPO, and application failover needs.
+3. Separate durable MAA principles from release-specific syntax or supportability.
+4. Prefer current public Oracle documentation for release-specific behavior, API details, certification, command syntax, and procedural steps.
+5. Use blogs for announcements, examples, and explanatory context; use documentation and white papers for architecture and procedure.
+6. When the question overlaps existing Oracle Database skills, use MAA guidance for the availability architecture decision and rely on database-topic skills for low-level mechanics.
+7. Cite source titles or links when making specific claims that users may need to verify.
+
+## Common Response Shape
+
+- Recommendation: direct answer and preferred MAA pattern.
+- Rationale: why this pattern fits the RTO/RPO, topology, maintenance, or application requirement.
+- Implementation considerations: key prerequisites, decisions, and risks.
+- Sources to verify: concise list of the most relevant public Oracle docs or blogs.
+
+## Oracle Version Notes (19c vs 26ai)
+
+- Use Oracle Database 19c as the baseline for mixed-version estates unless the user explicitly targets a newer release.
+- Use Oracle Database 26ai documentation as the preferred current documentation set for new guidance when a 26ai version is available.
+- Call out newer features, APIs, or operational improvements that require 23ai/26ai or a specific cloud service level.
+- When recommending MAA designs for 19c, verify that 26ai-only capabilities have a 19c-compatible alternative or clearly mark them as unavailable.
+- Oracle Update Advisor and newer Data Guard/MAA automation flows may have 26ai-specific documentation or API coverage; verify current support before prescribing an automated workflow.
diff --git a/db/maa/maa-tiers.md b/db/maa/maa-tiers.md
new file mode 100644
index 0000000..2efb008
--- /dev/null
+++ b/db/maa/maa-tiers.md
@@ -0,0 +1,48 @@
+# MAA Principles And Tiers
+
+Use this file for MAA tier selection, architecture positioning, and RTO/RPO framing. Keep the answer business-outcome driven: data loss tolerance, downtime tolerance, local HA, disaster recovery distance, maintenance windows, application failover behavior, and operational automation.
+
+## Core Principles
+
+- Design for both unplanned outages and planned maintenance. A design that survives failures but requires long patch outages is incomplete.
+- Treat HA and DR as related but different goals. RAC and service relocation address local HA; Data Guard and backups address site/database recovery; application continuity addresses user-visible interruption.
+- Eliminate single points of failure across compute, storage, network, database services, clients, DNS, identity, and operations.
+- Test role transitions, failover, restore, and application reconnect behavior. Untested availability architecture is an assumption.
+- Prefer automation for repeated operational paths: patch planning, switchover, failover orchestration, health checks, and validation.
+- Use database-aware replication for database recovery decisions. Storage mirroring may copy blocks, but Data Guard understands Oracle redo, recovery, corruption isolation, role transitions, and database consistency.
+- Keep backups even when using Data Guard. Data Guard protects availability and disaster recovery posture; backups protect against logical corruption, user error, retention requirements, and recovery to prior points.
+
+## Tier Guidance
+
+| Tier | Best fit | Typical capabilities | Watch-outs |
+|---|---|---|---|
+| Bronze | Single-instance or basic restart availability | Basic backup/recovery, restart, monitoring | Usually not enough for mission-critical RTO/RPO or rolling maintenance |
+| Silver | Local HA with reduced downtime | RAC or equivalent local HA, services, rolling maintenance where applicable | Does not by itself provide remote DR |
+| Gold | HA plus disaster recovery | Data Guard, role transitions, backup/recovery, application failover planning | Client failover and operational drills decide whether objectives are actually met |
+| Platinum | Near-zero downtime and stronger continuous availability | RAC + Active Data Guard, Application Continuity/FAN, standby-first maintenance, automation | Requires careful service design, driver/pool readiness, and tested operational runbooks |
+| Diamond | Highest resilience and automation posture for AI-era mission-critical systems | Builds on Platinum with stronger automation, multicloud/region awareness, operational intelligence, and agent/API integration | Use current Oracle guidance; treat blogs as positioning unless docs confirm implementation detail |
+
+## Decision Heuristics
+
+- If the main risk is instance or node failure inside one site, start with RAC/service design and client failover.
+- If the main risk is database, site, region, or cloud failure, include Data Guard/Active Data Guard and tested role transitions.
+- If the main risk is patching downtime, consider RAC rolling maintenance, Data Guard standby-first patching, Oracle Update Advisor, and service draining.
+- If application errors during failover matter, include FAN, connection string design, Transaction Guard, Application Continuity, or Transparent Application Continuity.
+- If schema/application upgrades drive downtime, consider Edition-Based Redefinition rather than treating it as an infrastructure failover problem.
+- If full application stacks must fail over, distinguish database DR from OCI Full Stack DR orchestration. Treat OCI Full Stack DR as primarily OCI application-stack orchestration; in multicloud, do not assume it can discover or manage non-OCI application containers and resources.
+
+## Common Mistakes
+
+- Equating RAC with DR. RAC improves local availability; it does not replace a remote standby.
+- Equating Data Guard with backup. Data Guard is not a substitute for retention and point-in-time recovery.
+- Designing only the database and ignoring clients, services, DNS, connection pools, and retry behavior.
+- Assuming maximum availability mode is always correct. SYNC transport depends on latency, distance, workload, and commit impact.
+- Treating a blog announcement as procedural support detail without verifying current documentation.
+
+## Sources
+
+- High Availability Overview and Best Practices: https://docs.oracle.com/en/database/oracle/oracle-database/26/haovw/index.html
+- Oracle MAA Reference Architectures: https://docs.oracle.com/en/database/oracle/oracle-database/26/haiad/index.html
+- MAA Overview Technical Brief: https://www.oracle.com/a/tech/docs/maa-overview-technical-brief.pdf
+- MAA data sheet: https://www.oracle.com/a/tech/docs/maa-data-sheet.pdf
+- Diamond tier context: https://blogs.oracle.com/maa/ascend-to-the-diamond-tier-introducing-the-next-gen-oracle-maximum-availability-architecture-maa
diff --git a/db/maa/multicloud-dr.md b/db/maa/multicloud-dr.md
new file mode 100644
index 0000000..31fe97b
--- /dev/null
+++ b/db/maa/multicloud-dr.md
@@ -0,0 +1,47 @@
+# Multicloud And OCI Full Stack Disaster Recovery
+
+Use this file for Oracle Database cloud best practices, Oracle multicloud deployments, Oracle Database@Azure/AWS/GCP, OCI Full Stack DR in OCI, regional failures, DNS failures, and cross-cloud MAA patterns.
+
+## Core Guidance
+
+- Start with the failure domain: instance, cluster, availability domain, region, cloud provider, network, DNS, identity, application tier, or operator workflow.
+- Database DR and application-stack DR are different layers. Data Guard handles database role transition; OCI Full Stack DR coordinates application, network, storage, middleware, and operational steps primarily for resources it can discover and manage in OCI.
+- Validate certification and supportability for the exact Oracle Database service and cloud combination before recommending a topology.
+- Design client connectivity as a first-class part of DR. DNS, connection strings, load balancers, routing, and service names determine the user-visible outcome.
+- Keep operational ownership clear across providers. Cross-cloud DR fails slowly when teams do not know who controls network, DNS, security, observability, and change windows.
+
+## Multicloud Decision Points
+
+| Question | Why it matters |
+|---|---|
+| What clouds and database services are involved? | Certification, networking, and operations differ by service. |
+| Is the goal HA, DR, migration, reporting, database failover, or OCI application-stack failover? | The architecture and tooling differ. |
+| What RTO/RPO is required? | Determines Data Guard mode, automation, and failover process. |
+| How will clients find the new primary? | DNS and connection strategy can dominate RTO. |
+| Who operates each layer? | Cross-team procedures must be explicit and tested. |
+
+## OCI Full Stack DR
+
+- Use OCI Full Stack DR primarily when the user needs orchestrated recovery plans across OCI application infrastructure, not just database role transition.
+- In multicloud deployments, do not describe OCI Full Stack DR as a general-purpose way to discover or orchestrate non-OCI application containers or other non-Oracle resources. It can integrate with supported Oracle database resources such as ADB-S@AWS or ExaDB-D@Azure, but it does not discover the broader application stack in those clouds.
+- Keep Data Guard as the database-level mechanism where appropriate; do not ask full-stack orchestration to replace database recovery semantics.
+- Include prechecks, ordered steps, validation, and rollback/fallback paths in recovery plans.
+- For OCI troubleshooting, log summarization and MCP integrations can help operators navigate DR plan output, but the recovery plan still needs deterministic controls.
+
+## Common Mistakes
+
+- Assuming cross-cloud DNS updates are instant and reliable enough without testing.
+- Designing database failover but not application routing.
+- Assuming OCI Full Stack DR can automatically discover or orchestrate application containers and resources running in non-OCI clouds.
+- Ignoring identity, secrets, observability, and operational access in the standby cloud.
+- Treating a certified combination matrix as a full architecture design.
+- Not rehearsing failover across provider boundaries.
+
+## Sources
+
+- Oracle AI Database Cloud Best Practices: https://docs.oracle.com/en/database/oracle/oracle-database/26/haovw/overview-oracle-ai-database-cloud-best-practices.html
+- Oracle Multicloud Certification Matrix: https://docs.oracle.com/en/database/oracle/oracle-database/26/haovw/multilcoud-certification-matrix.html
+- MAA Platinum across Oracle multicloud: https://blogs.oracle.com/maa/maa-platinum-tier-across-oracle-multicloud
+- OCI Full Stack DR integration with supported Oracle database resources across multicloud targets: https://blogs.oracle.com/maa/oci-full-stack-dr-supports-oracle-ai-databaseazure-aws-and-google-cloud
+- Regional and DNS failures: https://blogs.oracle.com/maa/surviving-regional-and-dns-failures-in-the-cloud
+- OCI Full Stack DR MCP Server: https://blogs.oracle.com/maa/introducing-the-oci-full-stack-disaster-recovery-mcp-server
diff --git a/db/maa/patching-update-advisor.md b/db/maa/patching-update-advisor.md
new file mode 100644
index 0000000..2936e9b
--- /dev/null
+++ b/db/maa/patching-update-advisor.md
@@ -0,0 +1,67 @@
+# Patching, Maintenance, And Oracle Update Advisor
+
+Use this file for MAA patching strategy, maintenance planning, Oracle Update Advisor, and agent/client integration with the Oracle Update Advisor REST API.
+
+## MAA Maintenance Principles
+
+- Treat patching as an availability workflow, not a one-time command.
+- Separate database home patching, Grid Infrastructure patching, Exadata platform maintenance, application changes, and client failover readiness.
+- Prefer rolling and standby-first approaches where supported and appropriate.
+- Validate the target state before changing roles or moving workload.
+- Use automation and repeatable runbooks for patch analysis, prechecks, execution, validation, and fallback.
+- Keep patch recommendations current; patching guidance is release- and environment-sensitive.
+
+## Choosing A Patching Pattern
+
+| Environment | Common MAA pattern |
+|---|---|
+| Single-instance, no standby | Plan outage or use migration/upgrade techniques; backups and restore validation become critical. |
+| RAC | Use rolling maintenance where supported; drain services and validate client failover. |
+| Data Guard | Patch standby first where supported, validate, switchover, then patch former primary. |
+| Exadata | Separate database, GI, and platform maintenance. Follow Exadata-specific maintenance guidance. |
+| Multicloud | Account for provider networking, DNS, service routing, and cross-cloud operational ownership. |
+
+## Oracle Update Advisor
+
+Use Oracle Update Advisor when the user needs current patch/maintenance recommendations, software health assessment, or a programmatic path to patch planning.
+
+- For human workflow: explain what Oracle Update Advisor evaluates and how it helps move from manual patch research to guided maintenance decisions.
+- For automation: point to the public REST API and recommend building clients that retrieve recommendations, surface required actions, and integrate with runbooks or agents.
+- For agents: keep the agent in an advisory/planning lane unless the user explicitly authorizes changes. Agents should collect environment metadata, call the API, summarize recommendations, and ask before taking operational action.
+
+## Typical Client Workflow
+
+Use this sequence when designing a CLI, web application, CI/CD integration, or agent:
+
+1. Register the client with Oracle Update Advisor.
+2. Submit a software health request and review the returned health status.
+3. Request recommendations when the health status or policy indicates action is needed.
+4. Poll asynchronous requests until the result is available.
+5. Present the result in a useful form for DBAs and platform teams, preserving the original payload.
+6. Feed approved actions into the patch-planning workflow.
+
+For an ongoing agent, schedule health checks, identify systems that fall behind policy, watch for credential-lifecycle messages, and prepare reviewable reports or tickets. Keep infrastructure changes and availability-affecting actions behind human review and approval.
+
+## Agent/CLI Client Considerations
+
+- Authenticate using the approved mechanism for the target environment.
+- Treat API responses as advisory input; do not patch automatically without policy checks and human approval.
+- Preserve the original recommendation payload for auditability.
+- Include database release, patch level, deployment type, Data Guard/RAC status, and Exadata/cloud context in the workflow.
+- Render recommendations by urgency, dependency, downtime impact, and MAA tier impact.
+
+## Common Mistakes
+
+- Patching primary first in a Data Guard configuration when standby-first maintenance would reduce risk.
+- Ignoring application connection draining and pool behavior during rolling maintenance.
+- Treating patching, upgrade, and platform maintenance as the same workflow.
+- Using old patch assumptions without checking current Oracle Update Advisor or documentation.
+
+## Sources
+
+- Database Patch Maintenance Guidelines: https://docs.oracle.com/en/database/oracle/oracle-database/26/dbptc/index.html
+- Oracle Update Advisor section: https://docs.oracle.com/en/database/oracle/oracle-database/26/dbptc/#GUID-7C39B9BE-8988-41C1-8C3D-C10F5AFB3DE1
+- Oracle Update Advisor REST API: https://docs.oracle.com/en/database/oracle/oracle-database/26/dgoui/#GUID-251DAB7C-80FD-40ED-84D0-459695FC7B0D
+- Data Guard patch maintenance: https://docs.oracle.com/en/database/oracle/oracle-database/26/dbpdg/index.html
+- RAC patch maintenance: https://docs.oracle.com/en/database/oracle/oracle-database/26/dbprc/index.html
+- Build an Oracle Update Advisor client or agent: https://blogs.oracle.com/maa/accept-the-ai-challenge-build-your-own-oracle-update-advisor-client-or-agent
diff --git a/db/maa/rac-exadata.md b/db/maa/rac-exadata.md
new file mode 100644
index 0000000..722422b
--- /dev/null
+++ b/db/maa/rac-exadata.md
@@ -0,0 +1,46 @@
+# RAC, Exadata, And Engineered Systems
+
+Use this file for MAA guidance involving Oracle RAC, Oracle Clusterware, Exadata Database Machine, Exadata Database Service, Exadata Cloud@Customer, consolidation, and platform maintenance.
+
+## RAC MAA Role
+
+- RAC provides local high availability and scale-out by allowing services to run across database instances in a cluster.
+- RAC is not disaster recovery by itself. Pair RAC with Data Guard or another DR architecture when site, region, or cloud failure is in scope.
+- Services are the operational abstraction. Place, drain, relocate, and fail over services intentionally.
+- Use rolling maintenance where supported, but validate application behavior because local rolling database maintenance still depends on client failover and service draining.
+- Use Clusterware to manage resources consistently; avoid hand-built failover logic around cluster-managed components.
+
+## Exadata MAA Role
+
+- Exadata is an engineered database platform with integrated compute, storage, networking, and database optimizations. MAA guidance should account for the whole platform, not only the database homes.
+- Distinguish Exadata Database Machine, Exadata Database Service, Exadata Cloud@Customer, and Oracle Database@Cloud deployments. Operational responsibility and maintenance procedures differ.
+- Exadata MAA commonly combines RAC for local HA, Data Guard/Active Data Guard for DR, RMAN/ZDLRA for recovery, and application continuity patterns for client experience.
+- Consolidation requires workload isolation, service design, backup/recovery planning, patch coordination, and capacity headroom for failover.
+- Platform maintenance needs explicit sequencing across database, Grid Infrastructure, storage/server software, and cloud-service operations.
+
+## Design Checklist
+
+- Define which failure domains are covered: instance, node, cell, rack, site, region, cloud provider.
+- Use services for workload separation, planned draining, role-based routing, and client failover.
+- Validate that interconnect, storage, SCAN/listeners, DNS, and client networks are redundant and monitored.
+- Maintain capacity for degraded operations. HA architecture fails in practice when the surviving side cannot carry required workload.
+- Align backup and DR strategy with consolidation density; one platform outage can affect many databases.
+- For security, patching, and STIG-style hardening questions, verify current Exadata documentation before giving step-by-step commands.
+
+## Common Mistakes
+
+- Calling an Exadata RAC deployment "Platinum" without Data Guard, application continuity, and tested operational practices.
+- Consolidating many critical databases without capacity reservation for failover or maintenance.
+- Patching the database layer while ignoring Grid Infrastructure, Exadata software, client drivers, or application pools.
+- Treating Exadata Cloud operations exactly like on-premises Exadata operations.
+- Skipping application connection testing because the database cluster failover itself succeeded.
+
+## Sources
+
+- RAC Administration and Deployment Guide: https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/index.html
+- RAC technical architecture: https://docs.oracle.com/en/database/oracle/oracle-database/26/adrac/index.html
+- Clusterware Administration and Deployment Guide: https://docs.oracle.com/en/database/oracle/oracle-database/26/cwadd/index.html
+- RAC patch maintenance: https://docs.oracle.com/en/database/oracle/oracle-database/26/dbprc/index.html
+- Exadata Database Machine MAA: https://www.oracle.com/docs/tech/exadata-maa.pdf
+- Exadata security architecture: https://www.oracle.com/a/tech/docs/exadata-maximum-security-architecture.pdf
+- Exadata maintenance guide: https://docs.oracle.com/en/engineered-systems/exadata-database-machine/dbmmn/index.html
diff --git a/db/maa/source-index.md b/db/maa/source-index.md
new file mode 100644
index 0000000..dafa47b
--- /dev/null
+++ b/db/maa/source-index.md
@@ -0,0 +1,317 @@
+# MAA Source Index
+
+Use this file only when exact public source links, citations, freshness checks, or less common source lookup is needed. For normal answers, load the focused topic files first and use their built-in MAA guidance.
+
+This index identifies primary public Oracle Maximum Availability Architecture (MAA) sources for source selection, source weighting, and answer grounding. It keeps authoritative links and concise summaries so agents can choose the right source quickly without treating the full URL catalog as the main context.
+
+## Retrieval Principles
+
+- Prefer current Oracle public documentation over memory when the answer depends on release behavior, supported procedure, API details, certification, syntax, or operational steps.
+- Use this file as a navigation and summarization layer, not as a replacement for retrieving the current source when exact details matter.
+- Weight sources in this order for external-facing answers: public MAA documentation, product documentation, public API/tool documentation, white papers and technical briefs, Oracle MAA blogs.
+- Use blogs for announcements, examples, and context. Use documentation for supportability and procedural detail.
+
+## Topic Guide
+
+### MAA Architecture And Tiers
+
+Use the MAA overview and reference architecture docs when explaining Bronze, Silver, Gold, Platinum, and newer Diamond-tier concepts. Anchor the answer on the business requirement: local HA, disaster recovery, zero or near-zero downtime maintenance, data protection, multicloud resilience, or operational automation.
+
+Primary sources:
+
+- High Availability Overview and Best Practices: https://docs.oracle.com/en/database/oracle/oracle-database/26/haovw/index.html
+- Oracle MAA Reference Architectures: https://docs.oracle.com/en/database/oracle/oracle-database/26/haiad/index.html
+- MAA Platinum Reference Architecture: https://docs.oracle.com/en/database/oracle/oracle-database/26/haiad/maa_platinum.html
+- Technical Brief Paper: Oracle Maximum Availability Architecture Overview: https://www.oracle.com/a/tech/docs/maa-overview-technical-brief.pdf
+- Oracle MAA data sheet, updated Feb 2026: https://www.oracle.com/a/tech/docs/maa-data-sheet.pdf
+- Ascend to the Diamond Tier: Introducing the Next-Gen Oracle Maximum Availability Architecture (MAA): https://blogs.oracle.com/maa/ascend-to-the-diamond-tier-introducing-the-next-gen-oracle-maximum-availability-architecture-maa
+
+### Oracle AI Database Cloud And Multicloud
+
+Use these sources for Oracle AI Database cloud deployment best practices, certified multicloud combinations, and cross-cloud MAA architecture discussions. Focus on topology, client connectivity, DNS, Data Guard role transitions, service placement, security boundaries, and cloud-specific operational responsibilities. For multicloud, treat OCI Full Stack DR as integration for supported Oracle database resources rather than a general-purpose discovery/orchestration layer for non-OCI application resources.
+
+Primary sources:
+
+- Oracle AI Database Cloud Best Practices: https://docs.oracle.com/en/database/oracle/oracle-database/26/haovw/overview-oracle-ai-database-cloud-best-practices.html
+- Oracle Multicloud Certification Matrix: https://docs.oracle.com/en/database/oracle/oracle-database/26/haovw/multilcoud-certification-matrix.html
+- MAA Platinum Tier Across Oracle Multicloud: https://blogs.oracle.com/maa/maa-platinum-tier-across-oracle-multicloud
+- OCI Full Stack DR Supports Oracle AI Database, Azure, AWS, and Google Cloud: https://blogs.oracle.com/maa/oci-full-stack-dr-supports-oracle-ai-databaseazure-aws-and-google-cloud
+- DR with Azure and OCI: https://blogs.oracle.com/maa/dr-azure-oci
+- Surviving Regional and DNS Failures in the Cloud: https://blogs.oracle.com/maa/surviving-regional-and-dns-failures-in-the-cloud
+
+### Data Guard And Active Data Guard
+
+Use Data Guard sources for disaster recovery, data protection, role transitions, redo transport, standby-first maintenance, hybrid cloud DR, and read-only/offload use cases. Ask for protection mode, database version, deployment model, distance, latency, redo rate, RTO/RPO, and client failover requirements.
+
+Primary sources:
+
+- Data Guard Concepts and Administration: https://docs.oracle.com/en/database/oracle/oracle-database/26/sbydb/index.html
+- Data Guard Broker: https://docs.oracle.com/en/database/oracle/oracle-database/26/dgbkr/index.html
+- Oracle Database Recommended Patch Maintenance for Databases Deployed with Oracle Data Guard: https://docs.oracle.com/en/database/oracle/oracle-database/26/dbpdg/index.html
+- Application and AI Scalability with Oracle Active Data Guard: https://blogs.oracle.com/maa/application-and-ai-scalability-with-oracle-active-data-guard
+- ONNX on Active Data Guard: https://blogs.oracle.com/maa/onnx-on-active-data-guard
+- DG 26ai Online Tablespace Encryption: https://blogs.oracle.com/maa/dg26ai-online-tablespace-encryption
+- Higher Data Guard Redo Transport Throughput: https://blogs.oracle.com/maa/higher-data-guard-redo-transport-throughput
+- Introducing DG Redo Decrypt for Hybrid Cloud: https://blogs.oracle.com/maa/introducing-dg-redo-decrypt-for-hybrid-cloud
+- Simplified Exadata Platform Migrations with Data Guard in Oracle Cloud: https://blogs.oracle.com/maa/simplified-exadata-platform-migrations-with-data-guard-in-oracle-cloud
+- ADG vs. Storage Mirroring: https://www.oracle.com/docs/tech/adg-vs-storage-mirroring-v1.pdf
+
+### RAC, Clusterware, Services, And Client Failover
+
+Use RAC and Clusterware sources for local high availability, service placement, rolling maintenance, scale-out, and client failover readiness. For applications, emphasize services, HA-aware connection strings, FAN, Application Continuity, Transaction Guard, connection draining, and driver/pool behavior.
+
+Primary sources:
+
+- Real Application Clusters Administration and Deployment Guide: https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/index.html
+- Oracle Real Application Clusters 26ai Technical Architecture: https://docs.oracle.com/en/database/oracle/oracle-database/26/adrac/index.html
+- Clusterware Administration and Deployment Guide: https://docs.oracle.com/en/database/oracle/oracle-database/26/cwadd/index.html
+- Oracle Database Recommended Patch Maintenance for Oracle Real Application Clusters: https://docs.oracle.com/en/database/oracle/oracle-database/26/dbprc/index.html
+- Oracle RAC 26ai: Unlocking Resilient, Scalable, and AI-Driven Applications: https://blogs.oracle.com/maa/oracle-rac-26ai-unlocking-resilient-scalable-and-ai-driven-applications
+- The High Availability Connection String Explained: https://blogs.oracle.com/maa/the-high-availability-connection-string-explained
+
+### Application Continuity, FAN, And Continuous Availability
+
+Use these sources when the question is about avoiding or masking application interruptions during planned maintenance, outages, failover, switchover, connection failures, or database service relocation. Explain which failures can be hidden from the application, which require retry logic, and which require application or driver changes.
+
+Primary sources:
+
+- Continuous Availability: https://www.oracle.com/a/ocom/docs/database/continuous-availabiliity.pdf
+- Application Continuity for Oracle Database 23ai: https://www.oracle.com/a/otn/docs/application-continuity-oracle-database-23ai.pdf
+- Fast Application Notification: https://www.oracle.com/a/ocom/docs/database/fast-application-notification.pdf
+- Application Checklist for Continuous Availability for MAA: https://www.oracle.com/a/tech/docs/application-checklist-for-continuous-availability-for-maa.pdf
+- Application Continuity Checklist for ADB-S: https://www.oracle.com/a/tech/docs/application-continuity-checklist-for-adb-s.pdf
+
+### Patching, Maintenance, And Oracle Update Advisor
+
+Use these sources for patch planning, recommended patching methods, rolling approaches, Data Guard standby-first patterns, RAC maintenance, and Oracle Update Advisor automation. Separate database patching, Grid Infrastructure patching, Exadata platform maintenance, and application deployment changes.
+
+Primary sources:
+
+- Database Patch Maintenance Guidelines: https://docs.oracle.com/en/database/oracle/oracle-database/26/dbptc/index.html
+- Oracle Database Patch Maintenance Guidelines, Oracle Update Advisor section: https://docs.oracle.com/en/database/oracle/oracle-database/26/dbptc/#GUID-7C39B9BE-8988-41C1-8C3D-C10F5AFB3DE1
+- Oracle Update Advisor REST API: https://docs.oracle.com/en/database/oracle/oracle-database/26/dgoui/#GUID-251DAB7C-80FD-40ED-84D0-459695FC7B0D
+- From Green Lights to Gold Tiers: MAA and Oracle Update Advisor: https://blogs.oracle.com/maa/from-green-lights-to-gold-tiers-maa-oracleupdateadvisor
+- Accept the AI Challenge: Build Your Own Oracle Update Advisor Client or Agent: https://blogs.oracle.com/maa/accept-the-ai-challenge-build-your-own-oracle-update-advisor-client-or-agent
+- Announcing Oracle Update Advisor: https://blogs.oracle.com/maa/announcing-oracle-update-advisor
+
+### Backup, Recovery, RMAN, And ZDLRA
+
+Use these sources for backup strategy, recovery validation, restore performance, corruption protection, recovery objectives, and Zero Data Loss Recovery Appliance architecture. Keep the distinction clear: backups are required even when Data Guard is deployed, and Data Guard is not a substitute for backup and recovery planning.
+
+Primary sources:
+
+- Backup and Recovery IAD: https://docs.oracle.com/en/database/oracle/oracle-database/26/bkupr/index.html
+- Database Backup and Recovery User's Guide: https://docs.oracle.com/en/database/oracle/oracle-database/26/bradv/index.html
+- Database Backup and Recovery Reference: https://docs.oracle.com/en/database/oracle/oracle-database/26/rcmrf/index.html
+- Zero Data Loss Recovery Appliance Protected Database Configuration Guide: https://docs.oracle.com/en/engineered-systems/zero-data-loss-recovery-appliance/23.1/ampdb/index.html
+- Zero Data Loss Recovery Appliance Administrator's Guide: https://docs.oracle.com/en/engineered-systems/zero-data-loss-recovery-appliance/23.1/amagd/index.html
+
+### Exadata And Engineered Systems
+
+Use Exadata sources for engineered system architecture, Exadata-specific MAA patterns, maintenance, security, platform migration, consolidation, and KVM considerations. Clarify whether the user means Exadata Database Machine, Exadata Database Service, Exadata Cloud@Customer, or a multicloud Oracle Database@Cloud deployment.
+
+Primary sources:
+
+- Security Guide for Exadata Database Machine: https://docs.oracle.com/en/engineered-systems/exadata-database-machine/dbmsq/index.html
+- Maintenance Guide for Exadata Database Machine: https://docs.oracle.com/en/engineered-systems/exadata-database-machine/dbmmn/index.html
+- System Overview for Exadata Database Machine: https://docs.oracle.com/en/engineered-systems/exadata-database-machine/dbmso/index.html
+- Oracle Exadata Database Machine: Maximum Availability Architecture: https://www.oracle.com/docs/tech/exadata-maa.pdf
+- Exadata Maximum Security Architecture: https://www.oracle.com/a/tech/docs/exadata-maximum-security-architecture.pdf
+- Exadata KVM Overview: https://www.oracle.com/docs/tech/exadata-kvm-overview.pdf
+- MAA Consolidation: https://www.oracle.com/docs/tech/database/maa-consolidation.pdf
+- OCI Managed/Co-managed Consolidation Deployment Strategies: https://www.oracle.com/a/otn/docs/database/oci-managed-comanaged-consolidation-deployment-strategies.pdf
+
+### Edition-Based Redefinition
+
+Use EBR sources for zero or near-zero downtime application upgrades involving database object changes. Explain editions, editioned objects, editioning views, crossedition triggers, phased rollout, and fallback planning at a high level; then point users to the documentation and technical papers for implementation details.
+
+Primary sources:
+
+- Edition-Based Redefinition overview: https://www.oracle.com/database/technologies/high-availability/ebr.html
+- Edition-Based Redefinition documentation: https://docs.oracle.com/en/database/oracle/oracle-database/26/adfns/editions.html
+- EBR Technical Deep Dive Overview: https://www.oracle.com/a/tech/docs/ebr-technical-deep-dive-overview.pdf
+- EBR Overview Presentation: https://www.oracle.com/a/tech/docs/ebr-overview-presentation.pdf
+- EBR FAQ: https://www.oracle.com/a/tech/docs/ebr-faq.pdf
+- Edition-Based Redefinition: A Solution for Zero-Downtime Application Upgrades: https://blogs.oracle.com/maa/edition-based-redefinition-a-solution-for-zero-downtime-application-upgrades
+
+### OCI Full Stack Disaster Recovery
+
+Use these sources when the user asks about OCI full-stack disaster recovery, DR orchestration, generative AI log summarization, or MCP-based integrations. Distinguish OCI application-stack orchestration from database-level Data Guard configuration. In multicloud, OCI Full Stack DR can integrate with supported Oracle database resources, but do not imply it can discover or orchestrate non-OCI application containers and resources.
+
+Primary sources:
+
+- Faster Disaster Recovery Troubleshooting with Generative AI Log Summarization in OCI Full Stack DR: https://blogs.oracle.com/maa/faster-disaster-recovery-troubleshooting-generative-ai-log-summarization-in-oci-full-stack-dr
+- Introducing the OCI Full Stack Disaster Recovery MCP Server: https://blogs.oracle.com/maa/introducing-the-oci-full-stack-disaster-recovery-mcp-server
+- OCI Full Stack DR Supports Oracle AI Database, Azure, AWS, and Google Cloud: https://blogs.oracle.com/maa/oci-full-stack-dr-supports-oracle-ai-databaseazure-aws-and-google-cloud
+
+### Security, Health, And Operations
+
+Use these sources for security architecture, Exadata security, health diagnostics, and operational readiness. For vulnerability findings or support-specific diagnostics, answer only from the public sources in this external catalog.
+
+Primary sources:
+
+- Security Guide for Exadata Database Machine: https://docs.oracle.com/en/engineered-systems/exadata-database-machine/dbmsq/index.html
+- Exadata Maximum Security Architecture: https://www.oracle.com/a/tech/docs/exadata-maximum-security-architecture.pdf
+- Oracle Autonomous Health Framework User's Guide: https://docs.oracle.com/en/engineered-systems/health-diagnostics/autonomous-health-framework/ahfug/index.html
+
+## Complete Public Source List
+
+### P1 Public MAA Documentation
+
+- High Availability Overview and Best Practices: https://docs.oracle.com/en/database/oracle/oracle-database/26/haovw/index.html
+  Summary: Start here for public MAA best practices, architecture context, HA/DR concepts, cloud best-practice entry points, and general decision framing.
+- Oracle AI Database Cloud Best Practices: https://docs.oracle.com/en/database/oracle/oracle-database/26/haovw/overview-oracle-ai-database-cloud-best-practices.html
+  Summary: Use for cloud deployment best practices for Oracle AI Database, including availability, resilience, and operational considerations in cloud environments.
+- Oracle Multicloud Certification Matrix: https://docs.oracle.com/en/database/oracle/oracle-database/26/haovw/multilcoud-certification-matrix.html
+  Summary: Use to verify certified Oracle Database multicloud combinations before recommending an architecture.
+- Oracle MAA Reference Architectures: https://docs.oracle.com/en/database/oracle/oracle-database/26/haiad/index.html
+  Summary: Use for MAA architecture patterns and tier-oriented guidance.
+- MAA Platinum Reference Architecture: https://docs.oracle.com/en/database/oracle/oracle-database/26/haiad/maa_platinum.html
+  Summary: Use for Platinum-tier MAA architecture guidance and near-zero downtime/continuous availability architecture discussions.
+
+### P2 Public Product Documentation
+
+1. Data Guard Broker: https://docs.oracle.com/en/database/oracle/oracle-database/26/dgbkr/index.html
+   Summary: Use for broker-based Data Guard configuration, management, switchover/failover operations, and automation-adjacent Data Guard administration.
+2. Data Guard Concepts and Administration: https://docs.oracle.com/en/database/oracle/oracle-database/26/sbydb/index.html
+   Summary: Use for Data Guard architecture, redo transport, apply, protection modes, role transitions, and standby database operations.
+3. Backup and Recovery IAD: https://docs.oracle.com/en/database/oracle/oracle-database/26/bkupr/index.html
+   Summary: Use for backup/recovery implementation and administration topics.
+4. Database Backup and Recovery User's Guide: https://docs.oracle.com/en/database/oracle/oracle-database/26/bradv/index.html
+   Summary: Use for RMAN and recovery planning, backup strategies, restore/recover procedures, and recovery validation.
+5. Database Backup and Recovery Reference: https://docs.oracle.com/en/database/oracle/oracle-database/26/rcmrf/index.html
+   Summary: Use for exact RMAN command and reference details.
+6. Database Patch Maintenance Guidelines: https://docs.oracle.com/en/database/oracle/oracle-database/26/dbptc/index.html
+   Summary: Use for database patch planning and Oracle patch maintenance guidance.
+7. Oracle Database Recommended Patch Maintenance for Databases Deployed with Oracle Data Guard: https://docs.oracle.com/en/database/oracle/oracle-database/26/dbpdg/index.html
+   Summary: Use for Data Guard-aware patching approaches and standby-first maintenance planning.
+8. Oracle Database Recommended Patch Maintenance for Oracle Real Application Clusters: https://docs.oracle.com/en/database/oracle/oracle-database/26/dbprc/index.html
+   Summary: Use for RAC patching and maintenance approaches.
+9. Oracle Database Upgrade Guide: https://docs.oracle.com/en/database/oracle/oracle-database/26/upgrd/index.html
+   Summary: Use for database upgrade planning and procedures.
+10. Real Application Clusters Administration and Deployment Guide: https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/index.html
+    Summary: Use for RAC deployment, services, management, workload placement, and operational guidance.
+11. Oracle Real Application Clusters 26ai Technical Architecture: https://docs.oracle.com/en/database/oracle/oracle-database/26/adrac/index.html
+    Summary: Use for RAC architecture details and 26ai-specific RAC technical positioning.
+12. Clusterware Administration and Deployment Guide: https://docs.oracle.com/en/database/oracle/oracle-database/26/cwadd/index.html
+    Summary: Use for Oracle Clusterware administration and deployment.
+13. Fleet Patching and Provisioning Administrator's Guide: https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/index.html
+    Summary: Use for Fleet Patching and Provisioning operations.
+14. Automatic Storage Management Administrator's Guide: https://docs.oracle.com/en/database/oracle/oracle-database/26/ostmg/index.html
+    Summary: Use for ASM storage administration.
+15. Oracle Globally Distributed Database Guide: https://docs.oracle.com/en/database/oracle/oracle-database/26/shard/index.html
+    Summary: Use for globally distributed database topics and sharding-related HA/scale considerations.
+16. Security Guide for Exadata Database Machine: https://docs.oracle.com/en/engineered-systems/exadata-database-machine/dbmsq/index.html
+    Summary: Use for Exadata security configuration and operational security guidance.
+17. Maintenance Guide for Exadata Database Machine: https://docs.oracle.com/en/engineered-systems/exadata-database-machine/dbmmn/index.html
+    Summary: Use for Exadata maintenance tasks and platform operations.
+18. System Overview for Exadata Database Machine: https://docs.oracle.com/en/engineered-systems/exadata-database-machine/dbmso/index.html
+    Summary: Use for Exadata platform overview and component context.
+19. Zero Data Loss Recovery Appliance Protected Database Configuration Guide: https://docs.oracle.com/en/engineered-systems/zero-data-loss-recovery-appliance/23.1/ampdb/index.html
+    Summary: Use for protected database configuration with Zero Data Loss Recovery Appliance.
+20. Zero Data Loss Recovery Appliance Administrator's Guide: https://docs.oracle.com/en/engineered-systems/zero-data-loss-recovery-appliance/23.1/amagd/index.html
+    Summary: Use for ZDLRA administration and operations.
+21. Oracle Autonomous Health Framework User's Guide: https://docs.oracle.com/en/engineered-systems/health-diagnostics/autonomous-health-framework/ahfug/index.html
+    Summary: Use for AHF diagnostics, health checks, and operational troubleshooting support.
+
+### Public APIs And Tools
+
+- Oracle Database Patch Maintenance Guidelines, Oracle Update Advisor section: https://docs.oracle.com/en/database/oracle/oracle-database/26/dbptc/#GUID-7C39B9BE-8988-41C1-8C3D-C10F5AFB3DE1
+  Summary: Use to orient users to Oracle Update Advisor in the patch maintenance flow.
+- Oracle Update Advisor REST API: https://docs.oracle.com/en/database/oracle/oracle-database/26/dgoui/#GUID-251DAB7C-80FD-40ED-84D0-459695FC7B0D
+  Summary: Use when helping users create CLI tools, custom clients, or agents that integrate directly with Oracle Update Advisor.
+
+### Public MAA White Papers And Technical Resources
+
+- Public MAA best-practices index: https://www.oracle.com/database/technologies/high-availability/oracle-database-maa-best-practices.html
+  Summary: Use as the landing page for Oracle public MAA papers and best-practice resources.
+- Technical Brief Paper: Oracle Maximum Availability Architecture Overview: https://www.oracle.com/a/tech/docs/maa-overview-technical-brief.pdf
+  Summary: Use for a concise MAA overview suitable for executive or architecture-level explanations.
+- Oracle MAA data sheet, updated Feb 2026: https://www.oracle.com/a/tech/docs/maa-data-sheet.pdf
+  Summary: Use for compact positioning and summary-level MAA messaging.
+- Oracle Exadata Database Machine: Maximum Availability Architecture: https://www.oracle.com/docs/tech/exadata-maa.pdf
+  Summary: Use for Exadata-specific MAA architecture and best-practice discussions.
+- Exadata Maximum Security Architecture: https://www.oracle.com/a/tech/docs/exadata-maximum-security-architecture.pdf
+  Summary: Use for Exadata security architecture positioning and best practices.
+- Exadata KVM Overview: https://www.oracle.com/docs/tech/exadata-kvm-overview.pdf
+  Summary: Use for Exadata KVM architecture and operational context.
+- MAA Consolidation: https://www.oracle.com/docs/tech/database/maa-consolidation.pdf
+  Summary: Use for consolidation architecture and MAA considerations.
+- ADG vs. Storage Mirroring: https://www.oracle.com/docs/tech/adg-vs-storage-mirroring-v1.pdf
+  Summary: Use when comparing database-aware disaster recovery with storage-level replication.
+- Continuous Availability: https://www.oracle.com/a/ocom/docs/database/continuous-availabiliity.pdf
+  Summary: Use for application-level continuous availability patterns.
+- Application Continuity for Oracle Database 23ai: https://www.oracle.com/a/otn/docs/application-continuity-oracle-database-23ai.pdf
+  Summary: Use for Application Continuity concepts and deployment considerations.
+- Fast Application Notification: https://www.oracle.com/a/ocom/docs/database/fast-application-notification.pdf
+  Summary: Use for FAN behavior and application/client reaction to database service events.
+- Application Checklist for Continuous Availability for MAA: https://www.oracle.com/a/tech/docs/application-checklist-for-continuous-availability-for-maa.pdf
+  Summary: Use as an application-readiness checklist for continuous availability.
+- Application Continuity Checklist for ADB-S: https://www.oracle.com/a/tech/docs/application-continuity-checklist-for-adb-s.pdf
+  Summary: Use for Application Continuity readiness with Autonomous Database Serverless scenarios.
+- ZDM GoldenGate Performance: https://www.oracle.com/docs/tech/zdm-gg-performance.pdf
+  Summary: Use for Zero Downtime Migration and GoldenGate performance context.
+- OCI Managed/Co-managed Consolidation Deployment Strategies: https://www.oracle.com/a/otn/docs/database/oci-managed-comanaged-consolidation-deployment-strategies.pdf
+  Summary: Use for deployment strategy decisions involving OCI managed or co-managed database consolidation.
+
+### Edition-Based Redefinition Resources
+
+- Edition-Based Redefinition overview: https://www.oracle.com/database/technologies/high-availability/ebr.html
+  Summary: Use for an external overview of EBR and zero-downtime application upgrade positioning.
+- Edition-Based Redefinition documentation: https://docs.oracle.com/en/database/oracle/oracle-database/26/adfns/editions.html
+  Summary: Use for implementation detail about editions and EBR features.
+- EBR Technical Deep Dive Overview: https://www.oracle.com/a/tech/docs/ebr-technical-deep-dive-overview.pdf
+  Summary: Use for detailed technical explanation of EBR patterns.
+- EBR Overview Presentation: https://www.oracle.com/a/tech/docs/ebr-overview-presentation.pdf
+  Summary: Use for presentation-oriented EBR overview material.
+- EBR FAQ: https://www.oracle.com/a/tech/docs/ebr-faq.pdf
+  Summary: Use for frequently asked EBR questions and concise clarifications.
+
+### Oracle MAA Blogs
+
+Use Oracle MAA blog posts for current announcements, applied examples, and explanatory context. Prefer product documentation, MAA white papers, or API docs for definitive procedural and supportability guidance.
+
+- MAA blog category index: https://blogs.oracle.com/maa/category/maa
+  Summary: Use to find current public MAA blog posts.
+- Raising the Standard for Mission-Critical Availability and Security in the Age of AI: https://blogs.oracle.com/database/raising-the-standard-for-mission-critical-availability-and-security-in-the-age-of-ai
+  Summary: Use for Oracle AI Database mission-critical availability and security positioning.
+- Analyst Perspectives on Oracle AI Database Mission-Critical Capabilities: https://blogs.oracle.com/database/analyst-perspectives-on-oracle-ai-database-mission-critical-capabilities
+  Summary: Use for analyst-view context on Oracle AI Database mission-critical capabilities.
+- Ascend to the Diamond Tier: Introducing the Next-Gen Oracle Maximum Availability Architecture (MAA): https://blogs.oracle.com/maa/ascend-to-the-diamond-tier-introducing-the-next-gen-oracle-maximum-availability-architecture-maa
+  Summary: Use for MAA Diamond-tier positioning and next-generation MAA concepts.
+- MAA Platinum Tier Across Oracle Multicloud: https://blogs.oracle.com/maa/maa-platinum-tier-across-oracle-multicloud
+  Summary: Use for Active Data Guard and MAA Platinum-tier context across Oracle multicloud deployments.
+- From Green Lights to Gold Tiers: MAA and Oracle Update Advisor: https://blogs.oracle.com/maa/from-green-lights-to-gold-tiers-maa-oracleupdateadvisor
+  Summary: Use for Oracle Update Advisor's role in operationalizing software health and MAA resilience.
+- Accept the AI Challenge: Build Your Own Oracle Update Advisor Client or Agent: https://blogs.oracle.com/maa/accept-the-ai-challenge-build-your-own-oracle-update-advisor-client-or-agent
+  Summary: Use for examples and motivation around clients or agents that use Oracle Update Advisor.
+- ONNX on Active Data Guard: https://blogs.oracle.com/maa/onnx-on-active-data-guard
+  Summary: Use for in-database AI inference on Active Data Guard and read-mostly AI workload context.
+- OCI Full Stack DR Supports Oracle AI Database, Azure, AWS, and Google Cloud: https://blogs.oracle.com/maa/oci-full-stack-dr-supports-oracle-ai-databaseazure-aws-and-google-cloud
+  Summary: Use for OCI Full Stack DR integration with supported Oracle AI Database resources across multicloud targets; do not treat it as broad non-OCI application-stack discovery.
+- DG 26ai Online Tablespace Encryption: https://blogs.oracle.com/maa/dg26ai-online-tablespace-encryption
+  Summary: Use for Data Guard 26ai online tablespace encryption context.
+- Higher Data Guard Redo Transport Throughput: https://blogs.oracle.com/maa/higher-data-guard-redo-transport-throughput
+  Summary: Use for redo transport throughput improvement context.
+- Oracle RAC 26ai: Unlocking Resilient, Scalable, and AI-Driven Applications: https://blogs.oracle.com/maa/oracle-rac-26ai-unlocking-resilient-scalable-and-ai-driven-applications
+  Summary: Use for RAC 26ai availability, scalability, and AI-driven application positioning.
+- DR with Azure and OCI: https://blogs.oracle.com/maa/dr-azure-oci
+  Summary: Use for Data Guard disaster recovery across Oracle Database@Azure and OCI.
+- Introducing DG Redo Decrypt for Hybrid Cloud: https://blogs.oracle.com/maa/introducing-dg-redo-decrypt-for-hybrid-cloud
+  Summary: Use for hybrid cloud Data Guard redo decryption context.
+- Surviving Regional and DNS Failures in the Cloud: https://blogs.oracle.com/maa/surviving-regional-and-dns-failures-in-the-cloud
+  Summary: Use for regional outage and DNS failure resilience patterns.
+- Application and AI Scalability with Oracle Active Data Guard: https://blogs.oracle.com/maa/application-and-ai-scalability-with-oracle-active-data-guard
+  Summary: Use for Active Data Guard application and AI workload scaling context.
+- Simplified Exadata Platform Migrations with Data Guard in Oracle Cloud: https://blogs.oracle.com/maa/simplified-exadata-platform-migrations-with-data-guard-in-oracle-cloud
+  Summary: Use for Exadata platform migration patterns using Data Guard.
+- Faster Disaster Recovery Troubleshooting with Generative AI Log Summarization in OCI Full Stack DR: https://blogs.oracle.com/maa/faster-disaster-recovery-troubleshooting-generative-ai-log-summarization-in-oci-full-stack-dr
+  Summary: Use for OCI Full Stack DR troubleshooting and generative AI log summarization context.
+- Introducing the OCI Full Stack Disaster Recovery MCP Server: https://blogs.oracle.com/maa/introducing-the-oci-full-stack-disaster-recovery-mcp-server
+  Summary: Use for MCP integration with OCI Full Stack Disaster Recovery.
+- Announcing Oracle Update Advisor: https://blogs.oracle.com/maa/announcing-oracle-update-advisor
+  Summary: Use for Oracle Update Advisor announcement and purpose.
+- The High Availability Connection String Explained: https://blogs.oracle.com/maa/the-high-availability-connection-string-explained
+  Summary: Use for practical explanation of high availability connection strings.
+- Edition-Based Redefinition: A Solution for Zero-Downtime Application Upgrades: https://blogs.oracle.com/maa/edition-based-redefinition-a-solution-for-zero-downtime-application-upgrades
+  Summary: Use for EBR as a zero-downtime application upgrade pattern.