diff --git a/livestack-workshop-finance/ai-operations-agent-console/ai-operations-agent-console.md b/livestack-workshop-finance/ai-operations-agent-console/ai-operations-agent-console.md
new file mode 100644
index 000000000..92c99fb1d
--- /dev/null
+++ b/livestack-workshop-finance/ai-operations-agent-console/ai-operations-agent-console.md
@@ -0,0 +1,113 @@
+# AI Operations Agent Console: Trusted Actions
+
+## Introduction
+
+This lab uses database-backed helper functions behind the agent console pattern. You call a function that summarizes current risk signals, log an agent decision, and review the audit trail.
+
+The final operating step is controlled action. An AI-assisted workflow should not only summarize risk; it should use approved tools and leave a durable record of what action was proposed or taken.
+
+
+
+### Objectives
+
+- Call the risk signal helper function.
+- Log and inspect an agent decision.
+
+Estimated Time: **8 minutes**
+
+### Operating Story
+
+| Step | Finance focus |
+| --- | --- |
+| Business Problem | AI-assisted operations need a record of what was decided, why, and when. |
+| Technical Challenge | Agent workflows need controlled tools and durable audit rows instead of untracked chat actions. |
+| Persona Focus | Operations leaders review actions; AI engineers and database developers expose approved PL/SQL tools and audit records. |
+| What You Will Prove | PL/SQL tools can return grounded summaries and write auditable action history. |
+| Database Capability | Stored functions and AGENT\_ACTIONS provide controlled tool execution and audit records. |
+| Outcome | Agent workflows become reviewable database events instead of untracked chat output. |
+
+Persona focus: You support the operations leader by turning an AI-assisted action into a database event that can be inspected and governed.
+
+## Task 1: Call the trend detection function
+
+1. Run the approved PL/SQL helper function.
+
+ ```sql
+
+ SELECT detect_trending_products(48, 50) AS risk_signal_summary
+ FROM dual;
+
+ ```
+
+ Expected output: Risk Signal Tool Summary
+
+ | Risk Signal Summary |
+ | --- |
+ | Found 10 critical financial products (last 48h): Options Trading Enablement (Civic National Bank) - 1 signals, risk severity 72.3, 512667 exposure,... |
+
+
+2. Review the summary text.
+ Expected output starts with a phrase like `Found 10 critical financial products`. The function turns current signal data into an operations-ready summary that an agent or analyst can use to decide what needs escalation.
+
+ This matters because the summary is produced by an approved database function, not by free-form interpretation outside the governed data boundary.
+
+## Task 2: Log an auditable agent action
+
+1. Log a validation action.
+
+ ```sql
+
+ SELECT log_agent_decision(
+ 'RISK_SIGNAL_TEAM',
+ 'ESCALATE',
+ 'RISK_SIGNAL',
+ 'Workshop validation escalation based on critical signal exposure'
+ ) AS result
+ FROM dual;
+
+ ```
+
+ Expected output: Agent Decision Result
+
+ | Result |
+ | --- |
+ | Decision logged: ESCALATE by RISK\_SIGNAL\_TEAM |
+
+
+2. Inspect the latest audit rows.
+
+ ```sql
+
+ SELECT agent_name,
+ action_type,
+ entity_type,
+ execution_status,
+ executed_at
+ FROM agent_actions
+ ORDER BY action_id DESC
+ FETCH FIRST 5 ROWS ONLY;
+
+ ```
+
+ Expected output: Agent Action Audit Trail
+
+ | Agent Name | Action Type | Entity Type | Execution Status | Executed At |
+ | --- | --- | --- | --- | --- |
+ | RISK\_SIGNAL\_TEAM | ESCALATE | RISK\_SIGNAL | completed | timestamp varies |
+ | RISK\_SIGNAL\_TEAM | ESCALATE | RISK\_SIGNAL | completed | timestamp varies |
+ | RISK\_SIGNAL\_TEAM | ESCALATE | RISK\_SIGNAL | completed | timestamp varies |
+ | RISK\_SIGNAL\_TEAM | ESCALATE | RISK\_SIGNAL | completed | timestamp varies |
+ | RISK\_SIGNAL\_TEAM | ESCALATE | RISK\_SIGNAL | completed | timestamp varies |
+
+
+3. Confirm the action is recorded.
+ The audit row is the database evidence that the action occurred. It records who the agent acted as, what action was requested, what entity type was affected, the execution status, and the timestamp.
+
+ This closes the workshop story: the same database foundation that produced risk evidence also records the AI-assisted operational response for later review.
+
+
+## Acknowledgements
+
+* **Author** - Pat Shepherd, Senior Principal Database Product Manager
+* **Contributor** - Linda Foinding, Principal Database Product Manager
+* **Last Updated By/Date** - Oracle Database Product Management, June 2026
diff --git a/livestack-workshop-finance/ai-operations-agent-console/images/agent-console-runbook.png b/livestack-workshop-finance/ai-operations-agent-console/images/agent-console-runbook.png
new file mode 100644
index 000000000..71800857b
Binary files /dev/null and b/livestack-workshop-finance/ai-operations-agent-console/images/agent-console-runbook.png differ
diff --git a/livestack-workshop-finance/ai-operations-agent-console/images/agent-console.png b/livestack-workshop-finance/ai-operations-agent-console/images/agent-console.png
new file mode 100644
index 000000000..71800857b
Binary files /dev/null and b/livestack-workshop-finance/ai-operations-agent-console/images/agent-console.png differ
diff --git a/livestack-workshop-finance/ai-operations-agent-console/images/agent-console.svg b/livestack-workshop-finance/ai-operations-agent-console/images/agent-console.svg
new file mode 100644
index 000000000..7bf91467d
--- /dev/null
+++ b/livestack-workshop-finance/ai-operations-agent-console/images/agent-console.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/livestack-workshop-finance/conclusion-business-outcomes/conclusion-business-outcomes.md b/livestack-workshop-finance/conclusion-business-outcomes/conclusion-business-outcomes.md
new file mode 100644
index 000000000..d1e9a664f
--- /dev/null
+++ b/livestack-workshop-finance/conclusion-business-outcomes/conclusion-business-outcomes.md
@@ -0,0 +1,65 @@
+# Conclusion
+
+## Introduction
+
+You followed the Seer Bank Finance LiveStack operating story from foundation to action. A single Oracle Database 26ai foundation supported risk awareness, product exposure, transaction evidence, semantic signal search, fraud traversal, service coverage, prediction, governed answers, and auditable agent actions.
+
+The business point is that financial intelligence is only useful when teams can move from signal to evidence to action without losing trust. If each step lives in a different system, Seer Bank must reconcile copies, rebuild security rules, explain inconsistent results, and audit decisions after the fact. With a converged Oracle Database foundation, the same governed data can serve dashboards, APIs, graph investigations, spatial analysis, model scoring, copilot answers, and agent workflows.
+
+That convergence is critical for finance because risk, fraud, AML, service, revenue, and compliance questions rarely stay inside one data type. A high-risk product may involve transaction rows, regulatory signal text, client exposure, fraud relationships, service-center capacity, predictive pressure, and an auditable escalation. The workshop showed how Oracle Database brings those workloads together so business users can make faster decisions and technical teams can prove where the evidence came from.
+
+### Objectives
+
+- Review the workshop outcomes.
+- Connect each finance outcome to database evidence.
+- Explain why convergence matters for finance risk, operations, analytics, governed AI, and auditability.
+
+Estimated Time: **5 minutes**
+
+## Task 1: Review what you proved
+
+1. Review the outcome map.
+
+ | Outcome | Database evidence |
+ | --- | --- |
+ | Shared finance foundation | Semantic finance views and object inventory checks |
+ | Risk operations dashboard | SQL aggregates over risk signals, exposure, transactions, and service data |
+ | Transaction documents | JSON Relational Duality and SQL/JSON projection |
+ | Risk signal intelligence | MiniLM embeddings and VECTOR\_DISTANCE |
+ | Financial crime investigation | FRAUD\_NETWORK and SQL/PGQ GRAPH\_TABLE traversal |
+ | Client service coverage | Spatial distance and SLA zone queries |
+ | Predictive operations | Persisted OML models scored in SQL |
+ | Governed copilot | Approved finance views and visible answer SQL |
+ | Trusted agent actions | PL/SQL tools and AGENT\_ACTIONS audit records |
+
+2. Review how the personas connect to those outcomes.
+
+ | Persona | Workshop value |
+ | --- | --- |
+ | Risk analyst | Moves from dashboard signals to explainable product, fraud, and exposure evidence. |
+ | Service operations leader | Uses spatial distance and SLA zones to reason about coverage pressure. |
+ | Application developer | Serves document-style transaction payloads without duplicating governed data. |
+ | Database developer | Proves relational, JSON, vector, graph, spatial, OML, PL/SQL, and audit evidence from one schema. |
+ | AI engineer | Grounds copilot answers and agent actions in approved SQL, tools, and audit records. |
+
+3. Connect the business use case back to convergence.
+
+ | Business pressure | Why a converged Oracle Database foundation matters |
+ | --- | --- |
+ | Emerging risk and fraud signals | Signal text, product exposure, transactions, and graph relationships can be investigated without moving evidence across systems. |
+ | Regulatory and AML review | Governed SQL, semantic views, security policies, and audit records keep answers reviewable. |
+ | Client service and operational capacity | Spatial coverage, transactions, service centers, and demand indicators can be analyzed together. |
+ | Predictive planning | OML scores run close to the finance records that supply model features and business context. |
+ | AI-assisted decisions | Copilot answers and agent actions remain tied to approved SQL, PL/SQL tools, and durable database evidence. |
+
+4. Use the workshop story as the final takeaway.
+
+ Seer Bank does not need separate architectures for every data type in the decision loop. Oracle Database 26ai lets the bank keep the data model governed while exposing the right access pattern for each job: relational SQL for operations, JSON for applications, vectors for semantic search, graph for financial-crime relationships, spatial for service coverage, OML for prediction, and audit tables for AI-assisted actions.
+
+ The result is a stronger finance operating model: fewer copies of sensitive data, fewer reconciliation points, clearer governance, faster investigation, and decisions that can be explained from database evidence.
+
+## Acknowledgements
+
+* **Author** - Pat Shepherd, Senior Principal Database Product Manager
+* **Contributor** - Linda Foinding, Principal Database Product Manager
+* **Last Updated By/Date** - Oracle Database Product Management, June 2026
diff --git a/livestack-workshop-finance/final-quiz/final-quiz.md b/livestack-workshop-finance/final-quiz/final-quiz.md
new file mode 100644
index 000000000..5e2046b45
--- /dev/null
+++ b/livestack-workshop-finance/final-quiz/final-quiz.md
@@ -0,0 +1,90 @@
+# Final Quiz
+
+```quiz-config
+passing: 75
+badge: images/badge.png
+```
+
+## Introduction
+
+Use this scored quiz to check your understanding of the Seer Bank Finance LiveStack workshop. The questions connect each finance outcome to the database evidence you inspected in the labs.
+
+### Objectives
+
+- Review the main database capabilities used in the workshop.
+- Connect each finance outcome to supporting database evidence.
+- Earn the workshop badge by answering the scored questions.
+
+Estimated Time: **5 minutes**
+
+## Task 1: Answer the quiz questions
+
+1. Complete the scored quiz.
+
+ ```quiz score
+ Q: Why does the workshop start by checking the finance data foundation before running later labs?
+ * It proves that the shared schema can support risk, operations, prediction, governed answers, and agent actions from one evidence base.
+ - It asks each learner to build a separate database before using the Finance LiveStack Demo.
+ - It replaces the need to inspect the business outcome in later labs.
+ - It moves finance records into external spreadsheets before analysis.
+ > The foundation lab ties the business workflow to a single governed database foundation. That makes later dashboard, vector, graph, spatial, OML, copilot, and agent results more explainable.
+
+ Q: What is the main business value of recreating dashboard evidence with SQL?
+ - It hides the underlying evidence from risk operations users.
+ * It lets operators move from a KPI to trusted detail without switching systems or relying on disconnected pipelines.
+ - It proves that screenshots are enough for audit review.
+ - It removes the need for governed finance views.
+ > The dashboard lab is about explainability. SQL aggregates connect the application summary to reviewable signal, exposure, transaction, service, and audit evidence.
+
+ Q: Which persona benefit does JSON Relational Duality provide in the transaction lab?
+ - Risk teams lose SQL access once the application receives a JSON document.
+ - Application teams must copy transaction records into a separate document store.
+ * Application developers can serve document-shaped payloads while database teams preserve relational controls.
+ - Business users must manually parse JSON strings before reviewing transactions.
+ > The business outcome is API-friendly transaction access without sacrificing relational integrity, governance, or SQL projection.
+
+ Q: Why is in-database AI Vector Search valuable for risk signal intelligence?
+ - It limits analysts to exact keyword matches.
+ * It lets analysts search by meaning while keeping source text, embeddings, and scoring inside the governed database.
+ - It replaces reviewable SQL with hidden prompt output.
+ - It searches only table and column names.
+ > The vector lab shows semantic search by intent, not just keywords. The governance value is that embedding and similarity scoring stay near the finance data.
+
+ Q: What business problem does the property graph lab solve for fraud investigators?
+ - It predicts revenue for finance products.
+ * It exposes relationship paths so investigators can explain why accounts, devices, payees, IP addresses, and phones are connected.
+ - It replaces audit history with untracked graph output.
+ - It stores service coverage regions for operations teams.
+ > The graph lab focuses on relationship evidence. A fraud analyst can prioritize connected entities without relying on fragile chains of manual joins.
+
+ Q: Why does the service coverage lab use spatial data?
+ - To make coverage decisions outside the database.
+ * To support location-aware decisions such as nearest service center, demand region pressure, and SLA zone coverage.
+ - To hide capacity evidence from service operations leaders.
+ - To replace maps and spatial queries with static labels.
+ > Spatial data lets operations teams reason about distance and coverage from database evidence, which supports mapping, spatial queries, and location-aware applications.
+
+ Q: What outcome does in-database OML scoring support?
+ - Sensitive finance records must be exported before each prediction.
+ * Risk, revenue, segmentation, and demand predictions can be scored where governed finance records already live.
+ - The application UI becomes the only place where model output can be reviewed.
+ - Models can be trusted without any SQL evidence.
+ > The OML lab is not only about model names. It shows how deployed models produce reviewable predictions close to the data that drives them.
+
+ Q: What makes the governed copilot and agent console patterns trustworthy?
+ - Hidden prompts and untracked actions.
+ - Unapproved tables with no visible SQL.
+ * Natural-language answers and agent actions are tied to approved views, visible SQL, controlled tools, and audit records.
+ - Browser-only answers that cannot be repeated.
+ > The governed AI outcome is reviewability. Business users can ask questions or request actions while technical teams prove what data, SQL, tool, and audit record supported the result.
+ ```
+
+2. Review the completion badge.
+
+ 
+
+## Acknowledgements
+
+* **Author** - Pat Shepherd, Senior Principal Database Product Manager
+* **Contributor** - Linda Foinding, Principal Database Product Manager
+* **Last Updated By/Date** - Oracle Database Product Management, June 2026
diff --git a/livestack-workshop-finance/final-quiz/images/badge.png b/livestack-workshop-finance/final-quiz/images/badge.png
new file mode 100644
index 000000000..3a4022834
Binary files /dev/null and b/livestack-workshop-finance/final-quiz/images/badge.png differ
diff --git a/livestack-workshop-finance/final-quiz/images/livestack-finance-badge.png b/livestack-workshop-finance/final-quiz/images/livestack-finance-badge.png
new file mode 100644
index 000000000..3a4022834
Binary files /dev/null and b/livestack-workshop-finance/final-quiz/images/livestack-finance-badge.png differ
diff --git a/livestack-workshop-finance/final-quiz/images/livestack-finance-badge.svg b/livestack-workshop-finance/final-quiz/images/livestack-finance-badge.svg
new file mode 100644
index 000000000..5b95d7fd8
--- /dev/null
+++ b/livestack-workshop-finance/final-quiz/images/livestack-finance-badge.svg
@@ -0,0 +1,62 @@
+
diff --git a/livestack-workshop-finance/finance-data-foundation/finance-data-foundation.md b/livestack-workshop-finance/finance-data-foundation/finance-data-foundation.md
new file mode 100644
index 000000000..17b361833
--- /dev/null
+++ b/livestack-workshop-finance/finance-data-foundation/finance-data-foundation.md
@@ -0,0 +1,133 @@
+# Finance Data Foundation
+
+## Introduction
+
+This lab confirms that the current Seer Bank data foundation is present. You inspect finance semantic views, core data groups, vectors, graphs, spatial objects, OML models, and agent functions before relying on later results.
+
+The rest of the workshop depends on this foundation. If these views and object families are missing, later dashboard metrics, vector matches, graph paths, spatial distances, OML scores, copilot answers, and agent audit rows cannot be trusted as one connected operating story.
+
+
+
+### Objectives
+
+- Confirm the finance semantic views are present.
+- Check the scale of the current data.
+- Map application pages to Oracle Database 26ai capabilities.
+
+Estimated Time: **10 minutes**
+
+### Operating Story
+
+| Step | Finance focus |
+| --- | --- |
+| Business Problem | Later risk, prediction, and agent outputs are not trustworthy unless the shared finance data foundation is complete. |
+| Technical Challenge | Platform teams must confirm that the same schema supports semantic views, vectors, graphs, spatial data, OML models, and PL/SQL tools. |
+| Persona Focus | Database developers and platform engineers validate the foundation before business users rely on downstream evidence. |
+| What You Will Prove | The schema contains the views and object families used by the current Finance LiveStack application. |
+| Database Capability | Oracle catalog views and finance semantic views expose the governed object inventory. |
+| Outcome | Every later lab starts from a known and queryable finance foundation. |
+
+Persona focus: You are the database developer proving that Seer Bank's shared foundation is ready for risk, operations, prediction, and AI workflows.
+
+## Task 1: Inventory the finance object families
+
+1. Run this inventory query to check the semantic views and database features used later in the workshop.
+
+ ```sql
+
+ SELECT 'Finance semantic views' AS "Area", COUNT(*) AS "Count"
+ FROM user_views
+ WHERE view_name IN (
+ 'FINANCE_INSTITUTIONS_V','FINANCE_PRODUCTS_V','RISK_SIGNALS_V',
+ 'SIGNAL_SOURCES_V','CLIENT_TRANSACTIONS_V','SERVICE_CENTERS_V',
+ 'SERVICE_CAPACITY_V','SERVICE_ROUTES_V'
+ )
+ UNION ALL
+ SELECT 'Finance property graphs', COUNT(*)
+ FROM user_property_graphs
+ WHERE graph_name IN ('FRAUD_NETWORK','INFLUENCER_NETWORK')
+ UNION ALL
+ SELECT 'MiniLM vector columns', COUNT(*)
+ FROM user_tab_cols
+ WHERE data_type = 'VECTOR'
+ AND table_name IN ('PRODUCT_EMBEDDINGS','SIGNAL_EMBEDDINGS')
+ UNION ALL
+ SELECT 'OML mining models', COUNT(*)
+ FROM user_mining_models
+ WHERE model_name IN (
+ 'DEMAND_SURGE_MODEL','CUSTOMER_SEGMENT_MODEL',
+ 'REVENUE_PREDICT_MODEL','PRODUCT_CLUSTER_MODEL'
+ )
+ UNION ALL
+ SELECT 'Agent helper functions', COUNT(*)
+ FROM user_objects
+ WHERE object_type = 'FUNCTION'
+ AND object_name IN (
+ 'DETECT_TRENDING_PRODUCTS','CHECK_PRODUCT_INVENTORY',
+ 'FIND_BEST_FULFILLMENT','GET_INFLUENCER_NETWORK','LOG_AGENT_DECISION'
+ );
+
+ ```
+
+ Expected output: Foundation Object Inventory
+
+ | Area | Count |
+ | --- | --- |
+ | Finance semantic views | 8 |
+ | Finance property graphs | 2 |
+ | MiniLM vector columns | 2 |
+ | OML mining models | 4 |
+ | Agent helper functions | 5 |
+
+
+2. Review the counts.
+ The rows confirm that the workshop schema contains every major capability used later: semantic views for governed SQL, property graphs for fraud reach, vector columns for semantic search, OML models for prediction, and helper functions for controlled agent actions.
+
+ Treat this as a readiness check. A zero or lower-than-expected count tells you which later lab would fail or lose business context.
+
+## Task 2: Count the current finance data groups
+
+1. Run this data group count query.
+
+ ```sql
+
+ SELECT 'Institutions' AS "Data Group", COUNT(*) AS "Rows" FROM finance_institutions_v
+ UNION ALL SELECT 'Financial products', COUNT(*) FROM finance_products_v
+ UNION ALL SELECT 'Risk signals', COUNT(*) FROM risk_signals_v
+ UNION ALL SELECT 'Signal sources', COUNT(*) FROM signal_sources_v
+ UNION ALL SELECT 'Client transactions', COUNT(*) FROM client_transactions_v
+ UNION ALL SELECT 'Service centers', COUNT(*) FROM service_centers_v
+ UNION ALL SELECT 'SLA zones', COUNT(*) FROM fulfillment_zones
+ UNION ALL SELECT 'Demand regions', COUNT(*) FROM demand_regions
+ UNION ALL SELECT 'Fraud entities', COUNT(*) FROM fraud_entities
+ UNION ALL SELECT 'Fraud relationships', COUNT(*) FROM fraud_relationships;
+
+ ```
+
+ Expected output: Finance Row Counts
+
+ | Data Group | Rows |
+ | --- | --- |
+ | Institutions | 50 |
+ | Financial products | 79 |
+ | Risk signals | 5000 |
+ | Signal sources | 463 |
+ | Client transactions | 3000 |
+ | Service centers | 30 |
+ | SLA zones | 120 |
+ | Demand regions | 20 |
+ | Fraud entities | 25 |
+ | Fraud relationships | 35 |
+
+
+2. Use the counts as the baseline for later labs.
+ These counts establish the scale of the finance scenario: products and institutions provide the business catalog, risk signals and transactions drive the dashboard, service centers and SLA zones support operations, and fraud entities plus relationships support the graph investigation.
+
+ The exact number matters because later results are aggregates over this same foundation. When a dashboard count, graph path, or spatial summary looks surprising, this baseline helps you decide whether the issue is data volume, filtering, or business logic.
+
+
+## Acknowledgements
+
+* **Author** - Pat Shepherd, Senior Principal Database Product Manager
+* **Contributor** - Linda Foinding, Principal Database Product Manager
+* **Last Updated By/Date** - Oracle Database Product Management, June 2026
diff --git a/livestack-workshop-finance/finance-data-foundation/images/data-foundation-runbook.png b/livestack-workshop-finance/finance-data-foundation/images/data-foundation-runbook.png
new file mode 100644
index 000000000..55dcfbbf7
Binary files /dev/null and b/livestack-workshop-finance/finance-data-foundation/images/data-foundation-runbook.png differ
diff --git a/livestack-workshop-finance/finance-data-foundation/images/data-foundation.png b/livestack-workshop-finance/finance-data-foundation/images/data-foundation.png
new file mode 100644
index 000000000..55dcfbbf7
Binary files /dev/null and b/livestack-workshop-finance/finance-data-foundation/images/data-foundation.png differ
diff --git a/livestack-workshop-finance/finance-data-foundation/images/foundation-map.svg b/livestack-workshop-finance/finance-data-foundation/images/foundation-map.svg
new file mode 100644
index 000000000..d8239e2be
--- /dev/null
+++ b/livestack-workshop-finance/finance-data-foundation/images/foundation-map.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/livestack-workshop-finance/financial-crime-network/financial-crime-network.md b/livestack-workshop-finance/financial-crime-network/financial-crime-network.md
new file mode 100644
index 000000000..b50ed5317
--- /dev/null
+++ b/livestack-workshop-finance/financial-crime-network/financial-crime-network.md
@@ -0,0 +1,143 @@
+# Financial Crime Network with Property Graph
+
+## Introduction
+
+This lab investigates a fraud network with Oracle Property Graph and SQL/PGQ. You start from suspicious account `ACCT-8841` and trace connected devices, IP addresses, payees, phones, and other entities.
+
+Fraud patterns often hide in relationships rather than in a single transaction row. This lab shows how a suspicious account can lead to connected devices, mule payees, IP addresses, and phone numbers that may explain coordinated activity.
+
+
+
+
+
+### Objectives
+
+- Traverse fraud ring reach from a seed account.
+- Find shared device and IP clusters.
+
+Estimated Time: **12 minutes**
+
+### Operating Story
+
+| Step | Finance focus |
+| --- | --- |
+| Business Problem | Fraud teams need to see relationships that are hard to detect from transaction tables alone. |
+| Technical Challenge | Investigators need path-based relationship analysis without writing and maintaining long chains of self-joins. |
+| Persona Focus | Fraud analysts interpret the network; database developers provide the graph pattern that explains why entities are connected. |
+| What You Will Prove | A property graph exposes fraud ring reach and shared entity clusters with SQL. |
+| Database Capability | FRAUD\_NETWORK and GRAPH\_TABLE support SQL/PGQ traversal. |
+| Outcome | Investigators can explain why entities are related and prioritize high-risk nodes. |
+
+Persona focus: You are helping a fraud analyst move from a suspicious account to explainable relationship evidence without turning the investigation into fragile join logic.
+
+## Task 1: Trace two-hop fraud reach
+
+1. Run the SQL/PGQ traversal from `ACCT-8841`.
+
+ This query treats the fraud data as a graph. In the `MATCH` pattern, `(seed IS entity)` is the starting account, `-[e IS related_to]->{1,2}` means follow one or two relationship hops, and `(reached IS entity)` is every entity reached from that starting point. The `WHERE` clause anchors the search on `ACCT-8841`, and the `COLUMNS` clause projects graph properties back into a normal SQL result table.
+
+ This is much easier than writing the same logic with ordinary joins. Without SQL/PGQ graph pattern matching, you would need separate self-joins for one-hop and two-hop paths, extra union logic for each relationship depth, and more code every time investigators want to follow another type of relationship. The graph pattern says what the investigator means: start here, follow related entities, and return the reached nodes.
+
+ ```sql
+
+ SELECT DISTINCT entity_key, display_name, entity_type,
+ risk_score, risk_level, total_amount, channel
+ FROM GRAPH_TABLE ( fraud_network
+ MATCH (seed IS entity) -[e IS related_to]->{1,2} (reached IS entity)
+ WHERE seed.entity_key = 'ACCT-8841'
+ COLUMNS (
+ reached.entity_key AS entity_key,
+ reached.display_name AS display_name,
+ reached.entity_type AS entity_type,
+ reached.risk_score AS risk_score,
+ reached.risk_level AS risk_level,
+ reached.total_amount AS total_amount,
+ reached.channel AS channel
+ )
+ )
+ ORDER BY risk_score DESC
+ FETCH FIRST 25 ROWS ONLY;
+
+ ```
+
+ Expected output: High Risk Fraud Entities
+
+ | Entity Key | Display Name | Entity Type | Risk Score | Risk Level | Total Amount | Channel |
+ | --- | --- | --- | --- | --- | --- | --- |
+ | DEV-fp-91a7 | Mobile Fingerprint 91a7 | device | 98.0 | critical | 42211.05 | network |
+ | PAYEE-MULE-017 | Mule Payee 017 | payee | 97.0 | critical | 36110.75 | payments |
+ | IP-198.51.100.44 | Residential Proxy 198.51.100.44 | ip\_address | 95.0 | critical | 38200.25 | network |
+ | PHONE-212-0199 | Reused VOIP 212-0199 | phone | 90.0 | critical | 25110.25 | contact\_center |
+ | PAYEE-CRYPTO-3 | Crypto Ramp Wallet 3 | payee | 87.0 | high | 14325.5 | payments |
+ | BRANCH-NY-014 | NY Midtown Branch 014 | branch | 49.0 | medium | 2800.0 | branch |
+
+
+2. Review the high-risk entities.
+ Expected rows include `DEV-fp-91a7`, `PAYEE-MULE-017`, `IP-198.51.100.44`, and `PHONE-212-0199`. These are not just labels; they are connected entities that help explain why the seed account deserves attention.
+
+ The result gives investigators a prioritized reach map. High risk scores and large amounts point to entities that may require account holds, case escalation, or deeper review before looking at lower-risk branches of the network.
+
+## Task 2: Find accounts sharing device, IP, phone, or email
+
+1. Run this shared-entity graph query.
+
+ This query looks for an account-to-shared-entity-to-account pattern. In graph terms, it finds `(a) -> (shared) <- (b)`: two accounts connected through the same device, IP address, phone, or email. The `a.entity_id < b.entity_id` filter prevents returning the same account pair twice, and the risk filter keeps the result focused on relationships where at least one account is already concerning.
+
+ This is where SQL/PGQ is especially useful. A relational version would need multiple joins back to the same entity and relationship tables, separate conditions for each shared entity type, and careful duplicate handling for account pairs. The graph query is shorter and closer to the fraud question: "Which risky accounts share the same identifying evidence?"
+
+ ```sql
+
+ SELECT account_a, shared_entity, shared_type, account_b,
+ a_risk, b_risk,
+ ROUND((a_risk + b_risk) / 2, 1) AS combined_risk,
+ e1_type, e2_type
+ FROM GRAPH_TABLE ( fraud_network
+ MATCH (a IS entity) -[e1 IS related_to]-> (shared IS entity) <-[e2 IS related_to]- (b IS entity)
+ WHERE a.entity_type = 'account'
+ AND b.entity_type = 'account'
+ AND a.entity_id < b.entity_id
+ AND shared.entity_type IN ('device','ip_address','phone','email')
+ AND (a.risk_score >= 70 OR b.risk_score >= 70)
+ COLUMNS (
+ a.entity_key AS account_a,
+ shared.entity_key AS shared_entity,
+ shared.entity_type AS shared_type,
+ b.entity_key AS account_b,
+ a.risk_score AS a_risk,
+ b.risk_score AS b_risk,
+ e1.relationship_type AS e1_type,
+ e2.relationship_type AS e2_type
+ )
+ )
+ ORDER BY combined_risk DESC, shared_entity
+ FETCH FIRST 25 ROWS ONLY;
+
+ ```
+
+ Expected output: Shared Entity Connections
+
+ | Account A | Shared Entity | Shared Type | Account B | A Risk | B Risk | Combined Risk | E1 Type | E2 Type |
+ | --- | --- | --- | --- | --- | --- | --- | --- | --- |
+ | ACCT-8841 | DEV-fp-91a7 | device | ACCT-1190 | 96.5 | 91.0 | 93.8 | shared\_device | shared\_device |
+ | ACCT-8841 | IP-198.51.100.44 | ip\_address | ACCT-1190 | 96.5 | 91.0 | 93.8 | shared\_ip | shared\_ip |
+ | ACCT-8841 | PHONE-212-0199 | phone | ACCT-1190 | 96.5 | 91.0 | 93.8 | same\_phone | same\_phone |
+ | ACCT-8841 | DEV-fp-91a7 | device | ACCT-5077 | 96.5 | 88.0 | 92.3 | shared\_device | shared\_device |
+ | ACCT-9204 | DEV-emulator-22 | device | ACCT-2188 | 94.0 | 86.0 | 90 | shared\_device | shared\_device |
+ | ACCT-9204 | IP-203.0.113.17 | ip\_address | ACCT-2188 | 94.0 | 86.0 | 90 | shared\_ip | shared\_ip |
+ | ACCT-1190 | DEV-fp-91a7 | device | ACCT-5077 | 91.0 | 88.0 | 89.5 | shared\_device | shared\_device |
+ | ACCT-8841 | IP-198.51.100.44 | ip\_address | ACCT-3320 | 96.5 | 81.5 | 89 | shared\_ip | shared\_ip |
+ | ACCT-1190 | IP-198.51.100.44 | ip\_address | ACCT-3320 | 91.0 | 81.5 | 86.3 | shared\_ip | shared\_ip |
+ | ACCT-5077 | EMAIL-risk-drop-01 | email | ACCT-3320 | 88.0 | 81.5 | 84.8 | same\_email | same\_email |
+
+
+2. Use the result to explain investigation priority.
+ A shared device, IP address, phone, or email can connect accounts that look separate in transaction tables. The combined risk score helps prioritize pairs where both sides of the relationship are risky, not just connected.
+
+ This is relevant to the overall workshop because it turns dashboard suspicion into explainable relationship evidence. The fraud analyst can say which accounts are connected, what they share, and why that connection matters.
+
+
+## Acknowledgements
+
+* **Author** - Pat Shepherd, Senior Principal Database Product Manager
+* **Contributor** - Linda Foinding, Principal Database Product Manager
+* **Last Updated By/Date** - Oracle Database Product Management, June 2026
diff --git a/livestack-workshop-finance/financial-crime-network/images/fraud-graph-investigation-flow.svg b/livestack-workshop-finance/financial-crime-network/images/fraud-graph-investigation-flow.svg
new file mode 100644
index 000000000..cc2303d3d
--- /dev/null
+++ b/livestack-workshop-finance/financial-crime-network/images/fraud-graph-investigation-flow.svg
@@ -0,0 +1,67 @@
+
diff --git a/livestack-workshop-finance/financial-crime-network/images/fraud-graph.svg b/livestack-workshop-finance/financial-crime-network/images/fraud-graph.svg
new file mode 100644
index 000000000..81e05682a
--- /dev/null
+++ b/livestack-workshop-finance/financial-crime-network/images/fraud-graph.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/livestack-workshop-finance/financial-crime-network/images/fraud-network-runbook.png b/livestack-workshop-finance/financial-crime-network/images/fraud-network-runbook.png
new file mode 100644
index 000000000..3e45a30e0
Binary files /dev/null and b/livestack-workshop-finance/financial-crime-network/images/fraud-network-runbook.png differ
diff --git a/livestack-workshop-finance/financial-crime-network/images/fraud-network.png b/livestack-workshop-finance/financial-crime-network/images/fraud-network.png
new file mode 100644
index 000000000..3e45a30e0
Binary files /dev/null and b/livestack-workshop-finance/financial-crime-network/images/fraud-network.png differ
diff --git a/livestack-workshop-finance/getting-started/getting-started.md b/livestack-workshop-finance/getting-started/getting-started.md
new file mode 100644
index 000000000..3529e47f3
--- /dev/null
+++ b/livestack-workshop-finance/getting-started/getting-started.md
@@ -0,0 +1,101 @@
+# Getting Started
+
+## Introduction
+
+Use this lab to open the LiveLabs reservation, access the provisioned **Autonomous Database 26ai** instance, and prepare SQL Worksheet for the hands-on finance exercises. This setup matters because every later lab depends on running SQL as the correct workshop user against the prepared finance schema.
+
+Estimated Time: **5 minutes**
+
+### Objectives
+
+In this lab, you will:
+
+- Launch the LiveLabs workshop environment.
+- Use the reservation login information to open Database Actions.
+- Confirm that SQL Worksheet is ready for the finance schema.
+- Confirm that the prepared workshop schema is available before continuing.
+
+## Task 1: Launch the LiveLabs environment
+
+Launch the LiveLabs environment first so the learner starts from the correct reservation, tenancy context, and workshop resources.
+
+1. Sign in to [LiveLabs](https://livelabs.oracle.com) with your Oracle account.
+
+2. Open this workshop, select **Start**, and select **Run on LiveLabs Sandbox**.
+
+3. In **My Reservations**, select **Launch Workshop** for this reservation.
+
+4. Select **View Login Info** and keep the database credentials available for the next task.
+
+ 
+
+ *Figure 1: The Reservation Information dialog shows the `LLUSER` login, password, and Login URL for Database Actions.*
+
+## Task 2: Open SQL Worksheet
+
+1. In the **Reservation Information** dialog, confirm that **1 - Login** shows `LLUSER`.
+
+2. Select **Copy** for **2 - Password**.
+
+ 
+
+ *Figure 2: Copy the `LLUSER` password from the Reservation Information dialog.*
+
+3. Select **Open Link** for **3 - Login URL**.
+
+ 
+
+ *Figure 3: Use Open Link for the Login URL, then use the copied password to sign in as `LLUSER`.*
+
+4. On the Database Actions sign-in page, confirm that **Username** shows `LLUSER`, paste the password from the reservation information, and select **Sign in**.
+
+ 
+
+ *Figure 4: Sign in to Database Actions as `LLUSER` with the password from the reservation information.*
+
+5. Before SQL Worksheet opens, select **Development**, then select **SQL** from the tools menu.
+
+ 
+
+ *Figure 5: Open SQL from the Development tools menu.*
+
+6. Use the same SQL Worksheet pattern throughout the workshop.
+
+ 
+
+ *Figure 6: Use SQL Worksheet to confirm the active user, paste each workshop SQL block, run the statement, and review the result table.*
+
+ - Confirm the user dropdown shows the main workshop user, usually `LLUSER`.
+ - Paste each workshop SQL block into the editor.
+ - Select **Run Statement** or press **Ctrl+Enter** to run the current SQL statement.
+ - Review the output in **Query Result** or **Script Output**, depending on the step.
+ - Use **Navigator** only when you want to inspect tables, views, or other objects.
+
+7. Run this check.
+
+ This check reads Oracle session context directly from the database. `USER` shows the authenticated account, while `SYS_CONTEXT('USERENV', 'CURRENT_SCHEMA')` shows where unqualified table names will resolve. If the user is not `LLUSER`, use the SQL Worksheet user dropdown to switch before continuing.
+
+ ```sql
+
+ SELECT USER AS "User",
+ SYS_CONTEXT('USERENV', 'CURRENT_SCHEMA') AS "Schema",
+ SYSTIMESTAMP AS "Checked At";
+
+ ```
+
+ Expected output: Connected SQL Worksheet Session
+
+ | User | Schema | Checked At |
+ | --- | --- | --- |
+ | LLUSER | LLUSER | 19-MAY-26 10.30.00.000000 AM UTC |
+
+
+8. If the schema is not present, ask the instructor to run the workshop handoff loader before continuing.
+
+You can now continue to the finance labs.
+
+## Acknowledgements
+
+* **Author** - Pat Shepherd, Senior Principal Database Product Manager
+* **Contributor** - Linda Foinding, Principal Database Product Manager
+* **Last Updated By/Date** - Oracle Database Product Management, May 2026
diff --git a/livestack-workshop-finance/getting-started/images/database-actions-development-sql.svg b/livestack-workshop-finance/getting-started/images/database-actions-development-sql.svg
new file mode 100644
index 000000000..812c1e620
--- /dev/null
+++ b/livestack-workshop-finance/getting-started/images/database-actions-development-sql.svg
@@ -0,0 +1,84 @@
+
diff --git a/livestack-workshop-finance/getting-started/images/database-actions-login-main-user.svg b/livestack-workshop-finance/getting-started/images/database-actions-login-main-user.svg
new file mode 100644
index 000000000..de2720ab7
--- /dev/null
+++ b/livestack-workshop-finance/getting-started/images/database-actions-login-main-user.svg
@@ -0,0 +1,24 @@
+
diff --git a/livestack-workshop-finance/getting-started/images/reservation-login-copy-password.svg b/livestack-workshop-finance/getting-started/images/reservation-login-copy-password.svg
new file mode 100644
index 000000000..9b1ed7bdc
--- /dev/null
+++ b/livestack-workshop-finance/getting-started/images/reservation-login-copy-password.svg
@@ -0,0 +1,62 @@
+
diff --git a/livestack-workshop-finance/getting-started/images/reservation-login-info.svg b/livestack-workshop-finance/getting-started/images/reservation-login-info.svg
new file mode 100644
index 000000000..2229a8003
--- /dev/null
+++ b/livestack-workshop-finance/getting-started/images/reservation-login-info.svg
@@ -0,0 +1,61 @@
+
diff --git a/livestack-workshop-finance/getting-started/images/reservation-login-open-link.svg b/livestack-workshop-finance/getting-started/images/reservation-login-open-link.svg
new file mode 100644
index 000000000..1354c726b
--- /dev/null
+++ b/livestack-workshop-finance/getting-started/images/reservation-login-open-link.svg
@@ -0,0 +1,62 @@
+
diff --git a/livestack-workshop-finance/getting-started/images/sql-worksheet-orientation-retail.svg b/livestack-workshop-finance/getting-started/images/sql-worksheet-orientation-retail.svg
new file mode 100644
index 000000000..65deb3cac
--- /dev/null
+++ b/livestack-workshop-finance/getting-started/images/sql-worksheet-orientation-retail.svg
@@ -0,0 +1,180 @@
+
diff --git a/livestack-workshop-finance/getting-started/images/sql-worksheet-orientation.svg b/livestack-workshop-finance/getting-started/images/sql-worksheet-orientation.svg
new file mode 100644
index 000000000..65deb3cac
--- /dev/null
+++ b/livestack-workshop-finance/getting-started/images/sql-worksheet-orientation.svg
@@ -0,0 +1,180 @@
+
diff --git a/livestack-workshop-finance/governed-data-copilot/governed-data-copilot.md b/livestack-workshop-finance/governed-data-copilot/governed-data-copilot.md
new file mode 100644
index 000000000..b1c31628c
--- /dev/null
+++ b/livestack-workshop-finance/governed-data-copilot/governed-data-copilot.md
@@ -0,0 +1,113 @@
+# Governed Data Copilot: Trusted Answers
+
+## Introduction
+
+This lab prepares governed questions for a data copilot workflow. The goal is to require approved finance views, visible SQL, and reviewable database evidence.
+
+Natural-language answers are useful only when risk and governance teams can review the source. This lab shows how a copilot-style answer can stay grounded in approved views and visible SQL instead of relying on untraceable generated text.
+
+
+
+### Objectives
+
+- List approved finance views.
+- Run a trusted answer query that could back a copilot response.
+
+Estimated Time: **8 minutes**
+
+### Operating Story
+
+| Step | Finance focus |
+| --- | --- |
+| Business Problem | Business users want natural-language answers, but risk teams need approved data boundaries. |
+| Technical Challenge | AI teams need copilot answers that expose SQL and stay inside approved semantic views instead of relying on opaque prompt output. |
+| Persona Focus | Business users ask questions; AI engineers and database developers enforce governed data boundaries and reviewable evidence. |
+| What You Will Prove | Trusted answers can be grounded in finance semantic views and explicit SQL. |
+| Database Capability | Semantic finance views and catalog comments expose controlled business meaning. |
+| Outcome | Copilot-style answers can be reviewed, repeated, and governed. |
+
+Persona focus: You support business users who want natural-language answers while proving to risk and governance teams that every answer has visible SQL behind it.
+
+## Task 1: Review approved finance views
+
+1. Run this catalog query before asking finance questions.
+
+ ```sql
+
+ SELECT view_name,
+ text_length
+ FROM user_views
+ WHERE view_name LIKE 'FINANCE_%'
+ OR view_name IN (
+ 'RISK_SIGNALS_V','SIGNAL_SOURCES_V','CLIENT_TRANSACTIONS_V',
+ 'SERVICE_CENTERS_V','SERVICE_CAPACITY_V','SERVICE_ROUTES_V'
+ )
+ ORDER BY view_name;
+
+ ```
+
+ Expected output: Governed View Comments
+
+ | View Name | Text Length |
+ | --- | --- |
+ | CLIENT\_TRANSACTIONS\_V | 326 |
+ | FINANCE\_INSTITUTIONS\_V | 158 |
+ | FINANCE\_PRODUCTS\_V | 214 |
+ | RISK\_SIGNALS\_V | 528 |
+ | SERVICE\_CAPACITY\_V | 360 |
+ | SERVICE\_CENTERS\_V | 547 |
+ | SERVICE\_ROUTES\_V | 329 |
+ | SIGNAL\_SOURCES\_V | 481 |
+
+
+2. Treat these views as the approved data boundary.
+ These views expose finance language for institutions, products, signals, transactions, service centers, capacity, and routes. They are the objects a governed copilot should prefer because they already encode business meaning and hide lower-level implementation details.
+
+ This matters in the broader workshop because the same foundation that supports dashboards and agents also constrains AI answers to approved database evidence.
+
+## Task 2: Ground a natural-language question in SQL
+
+1. For the question "Which product categories have the highest current risk exposure?", run visible SQL.
+
+ ```sql
+
+ SELECT fp.product_category,
+ COUNT(DISTINCT rs.signal_id) AS signal_count,
+ ROUND(AVG(rs.criticality_score), 1) AS avg_criticality,
+ SUM(rs.exposure_count) AS exposure_count
+ FROM risk_signals_v rs
+ JOIN post_product_mentions ppm ON ppm.post_id = rs.signal_id
+ JOIN finance_products_v fp ON fp.financial_product_id = ppm.product_id
+ GROUP BY fp.product_category
+ ORDER BY exposure_count DESC
+ FETCH FIRST 10 ROWS ONLY;
+
+ ```
+
+ Expected output: Exposure by Product Category
+
+ | Product Category | Signal Count | Avg Criticality | Exposure Count |
+ | --- | --- | --- | --- |
+ | Compliance Services | 174 | 42.1 | 127777803 |
+ | Payments | 214 | 41.1 | 113565293 |
+ | Risk Analytics | 198 | 41.2 | 93531273 |
+ | Consumer Lending | 171 | 42.6 | 88437900 |
+ | Capital Markets | 158 | 40.5 | 64735955 |
+ | Wealth Management | 117 | 41.9 | 60648625 |
+ | Investments | 170 | 41 | 59359773 |
+ | Commercial Lending | 180 | 41.3 | 52379514 |
+ | Specialty Finance | 54 | 42.9 | 51785604 |
+ | Cards and Payments | 132 | 41.6 | 49978774 |
+
+
+2. Use the result to draft a governed answer.
+ A governed answer should cite the rows and avoid claiming access to objects outside the approved set. For example, the answer can say which product categories have the highest exposure, how many signals support the ranking, and what average criticality was observed.
+
+ The returned table is relevant because it gives a business user an answer and gives reviewers the SQL evidence behind that answer. The copilot pattern is trustworthy only when both are present.
+
+
+## Acknowledgements
+
+* **Author** - Pat Shepherd, Senior Principal Database Product Manager
+* **Contributor** - Linda Foinding, Principal Database Product Manager
+* **Last Updated By/Date** - Oracle Database Product Management, June 2026
diff --git a/livestack-workshop-finance/governed-data-copilot/images/governed-copilot.svg b/livestack-workshop-finance/governed-data-copilot/images/governed-copilot.svg
new file mode 100644
index 000000000..2b7aee2e9
--- /dev/null
+++ b/livestack-workshop-finance/governed-data-copilot/images/governed-copilot.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/livestack-workshop-finance/governed-data-copilot/images/governed-data-copilot-runbook.png b/livestack-workshop-finance/governed-data-copilot/images/governed-data-copilot-runbook.png
new file mode 100644
index 000000000..33122cfd1
Binary files /dev/null and b/livestack-workshop-finance/governed-data-copilot/images/governed-data-copilot-runbook.png differ
diff --git a/livestack-workshop-finance/governed-data-copilot/images/governed-data-copilot.png b/livestack-workshop-finance/governed-data-copilot/images/governed-data-copilot.png
new file mode 100644
index 000000000..33122cfd1
Binary files /dev/null and b/livestack-workshop-finance/governed-data-copilot/images/governed-data-copilot.png differ
diff --git a/livestack-workshop-finance/introduction/images/seer-bank-welcome-runbook.png b/livestack-workshop-finance/introduction/images/seer-bank-welcome-runbook.png
new file mode 100644
index 000000000..468eb0ce1
Binary files /dev/null and b/livestack-workshop-finance/introduction/images/seer-bank-welcome-runbook.png differ
diff --git a/livestack-workshop-finance/introduction/images/seer-bank-welcome.png b/livestack-workshop-finance/introduction/images/seer-bank-welcome.png
new file mode 100644
index 000000000..468eb0ce1
Binary files /dev/null and b/livestack-workshop-finance/introduction/images/seer-bank-welcome.png differ
diff --git a/livestack-workshop-finance/introduction/images/seer-bank-welcome.svg b/livestack-workshop-finance/introduction/images/seer-bank-welcome.svg
new file mode 100644
index 000000000..88a450323
--- /dev/null
+++ b/livestack-workshop-finance/introduction/images/seer-bank-welcome.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/livestack-workshop-finance/introduction/introduction.md b/livestack-workshop-finance/introduction/introduction.md
new file mode 100644
index 000000000..6649167a8
--- /dev/null
+++ b/livestack-workshop-finance/introduction/introduction.md
@@ -0,0 +1,40 @@
+# Build Financial Intelligence with Oracle Database 26ai
+
+## Introduction
+
+Financial institutions are under pressure to spot emerging risk, investigate fraud, meet regulatory obligations, protect customer trust, and keep service operations moving. That work becomes harder when evidence is fragmented across core banking systems, transaction platforms, fraud tools, compliance workflows, service applications, analytics environments, and AI services. Each copy or pipeline adds latency, reconciliation work, security exposure, and room for a business decision to drift away from governed facts.
+
+In this workshop, Seer Bank uses Oracle Database 26ai as a converged financial-intelligence foundation. Relational transactions, JSON documents, vector search, property graph relationships, spatial service coverage, in-database machine learning, governed SQL answers, PL/SQL tools, and audit records all operate against connected finance data. The goal is not to show separate features in isolation; it is to show why keeping these capabilities together changes the operating model.
+
+The journey follows one decision flow: risk signals emerge, products and institutions are tied to exposure, fraud networks reveal connected evidence, service and transaction workflows show operational impact, predictive models estimate pressure, governed data access answers business questions, and AI-assisted actions are recorded for review. Each lab starts from a business question, then proves how Oracle Database stores, queries, scores, or audits the evidence behind the answer.
+
+
+
+### Objectives
+
+- Query the current Seer Bank finance data foundation.
+- Use SQL, JSON Relational Duality, AI Vector Search, Property Graph, Oracle Spatial, OML, and PL/SQL in one workflow.
+- Explain why a converged Oracle Database foundation is critical for risk, operations, analytics, governed AI, and auditability.
+- Connect the application pages to repeatable database evidence.
+
+Estimated Workshop Time: **95 minutes**
+
+### Operating Story
+
+| Step | Finance focus |
+| --- | --- |
+| Business Problem | Seer Bank needs faster risk, fraud, compliance, service, and AI-assisted decisions without spreading evidence across disconnected systems. |
+| Technical Challenge | Application, data, and AI teams otherwise stitch together separate stores, services, indexes, pipelines, and governance controls for each data type. |
+| Persona Focus | Database developers, application developers, risk analysts, operations leaders, and AI engineers share one evidence path. |
+| What You Will Prove | One Oracle Database 26ai foundation can support the finance decision loop from awareness to action. |
+| Database Capability | Relational SQL, JSON, vectors, graphs, spatial, OML, semantic views, PL/SQL tools, and audit records work together under one governed data model. |
+| Outcome | Risk, operations, and engineering teams can observe, investigate, decide, act, and review from database-backed evidence instead of reconciling disconnected outputs. |
+
+Persona focus: You act as the technical team supporting finance business users who need timely, explainable decisions without fragmented integration work. Your job is to prove that the business story and the technical architecture are the same story: trusted finance decisions depend on connected, governed data.
+
+
+## Acknowledgements
+
+* **Author** - Pat Shepherd, Senior Principal Database Product Manager
+* **Contributor** - Linda Foinding, Principal Database Product Manager
+* **Last Updated By/Date** - Oracle Database Product Management, June 2026
diff --git a/livestack-workshop-finance/predictive-risk-oml/images/finance-oml-scoring-flow.svg b/livestack-workshop-finance/predictive-risk-oml/images/finance-oml-scoring-flow.svg
new file mode 100644
index 000000000..683b44954
--- /dev/null
+++ b/livestack-workshop-finance/predictive-risk-oml/images/finance-oml-scoring-flow.svg
@@ -0,0 +1,72 @@
+
diff --git a/livestack-workshop-finance/predictive-risk-oml/images/oml-models.svg b/livestack-workshop-finance/predictive-risk-oml/images/oml-models.svg
new file mode 100644
index 000000000..6be9c7837
--- /dev/null
+++ b/livestack-workshop-finance/predictive-risk-oml/images/oml-models.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/livestack-workshop-finance/predictive-risk-oml/images/predictive-risk-oml-runbook.png b/livestack-workshop-finance/predictive-risk-oml/images/predictive-risk-oml-runbook.png
new file mode 100644
index 000000000..990d1ca88
Binary files /dev/null and b/livestack-workshop-finance/predictive-risk-oml/images/predictive-risk-oml-runbook.png differ
diff --git a/livestack-workshop-finance/predictive-risk-oml/images/predictive-risk-oml.png b/livestack-workshop-finance/predictive-risk-oml/images/predictive-risk-oml.png
new file mode 100644
index 000000000..990d1ca88
Binary files /dev/null and b/livestack-workshop-finance/predictive-risk-oml/images/predictive-risk-oml.png differ
diff --git a/livestack-workshop-finance/predictive-risk-oml/predictive-risk-oml.md b/livestack-workshop-finance/predictive-risk-oml/predictive-risk-oml.md
new file mode 100644
index 000000000..6ba568bf2
--- /dev/null
+++ b/livestack-workshop-finance/predictive-risk-oml/predictive-risk-oml.md
@@ -0,0 +1,131 @@
+# Predictive Risk, Capacity, and Revenue with OML
+
+## Introduction
+
+This lab scores persisted Oracle Machine Learning models created by the finance stack. The models run inside the database, so predictions stay close to risk signals, customers, products, and transactions.
+
+Prediction adds forward-looking evidence to the operating flow. Instead of only describing current risk and service pressure, the database can score demand surge, customer segments, product clusters, and revenue expectations where the governed data already lives.
+
+
+
+
+
+### Objectives
+
+- Inventory the four OML models.
+- Score classification, clustering, and regression models.
+
+Estimated Time: **12 minutes**
+
+### Operating Story
+
+| Step | Finance focus |
+| --- | --- |
+| Business Problem | Finance teams need prediction without exporting sensitive operating data. |
+| Technical Challenge | Data science and application teams need deployed models that can be scored from SQL without copying governed finance records elsewhere. |
+| Persona Focus | Risk and revenue leaders use predictions; database developers and ML engineers prove the models score inside the database. |
+| What You Will Prove | Persisted OML models can be inventoried and scored directly in SQL. |
+| Database Capability | DBMS\_DATA\_MINING, PREDICTION, PREDICTION\_PROBABILITY, CLUSTER\_ID, and CLUSTER\_PROBABILITY support in-database ML. |
+| Outcome | Risk, segmentation, revenue, and product grouping outputs are explainable from SQL. |
+
+Persona focus: You bridge the ML engineer and finance decision-maker by showing how deployed models produce reviewable scores where the data already lives.
+
+## Task 1: Inventory persisted OML models
+
+1. Run this model inventory query.
+
+ ```sql
+
+ SELECT model_name,
+ mining_function,
+ algorithm
+ FROM user_mining_models
+ ORDER BY model_name;
+
+ ```
+
+ Expected output: OML Model Inventory
+
+ | Model Name | Mining Function | Algorithm |
+ | --- | --- | --- |
+ | CUSTOMER\_SEGMENT\_MODEL | CLUSTERING | KMEANS |
+ | DEMAND\_SURGE\_MODEL | CLASSIFICATION | RANDOM\_FOREST |
+ | PRODUCT\_CLUSTER\_MODEL | CLUSTERING | KMEANS |
+ | REVENUE\_PREDICT\_MODEL | REGRESSION | GENERALIZED\_LINEAR\_MODEL |
+
+
+2. Confirm the model list.
+ Expected models are CUSTOMER\_SEGMENT\_MODEL, DEMAND\_SURGE\_MODEL, PRODUCT\_CLUSTER\_MODEL, and REVENUE\_PREDICT\_MODEL. The list proves that the database contains deployed models for several finance decisions, not just one isolated prediction.
+
+ This inventory is important because a prediction is only operationally useful when teams can verify which model exists, what mining function it performs, and whether it can be scored from SQL.
+
+## Task 2: Score demand risk and revenue in SQL
+
+1. Run the demand surge classification query.
+
+ ```sql
+
+ SELECT product_id,
+ surge_label AS training_label,
+ PREDICTION(DEMAND_SURGE_MODEL USING *) AS predicted_surge,
+ ROUND(PREDICTION_PROBABILITY(DEMAND_SURGE_MODEL USING *), 4) AS confidence
+ FROM oml_demand_training_v
+ FETCH FIRST 10 ROWS ONLY;
+
+ ```
+
+ Expected output: Surge Prediction Results
+
+ | Product Id | Training Label | Predicted Surge | Confidence |
+ | --- | --- | --- | --- |
+ | 45 | SURGE | SURGE | 0.5211 |
+ | 52 | SURGE | SURGE | 0.6106 |
+ | 68 | SURGE | SURGE | 0.6009 |
+ | 34 | SURGE | STABLE | 0.6206 |
+ | 2 | SURGE | STABLE | 0.6156 |
+ | 57 | SURGE | SURGE | 0.5205 |
+ | 69 | SURGE | SURGE | 0.5809 |
+ | 58 | SURGE | STABLE | 0.5125 |
+ | 19 | SURGE | SURGE | 0.6009 |
+ | 16 | SURGE | SURGE | 0.59 |
+
+
+2. Run revenue regression.
+
+ ```sql
+
+ SELECT order_id,
+ target_revenue,
+ ROUND(PREDICTION(REVENUE_PREDICT_MODEL USING *), 2) AS predicted_revenue
+ FROM oml_revenue_training_v
+ FETCH FIRST 10 ROWS ONLY;
+
+ ```
+
+ Expected output: Revenue Prediction Results
+
+ | Order Id | Target Revenue | Predicted Revenue |
+ | --- | --- | --- |
+ | 534 | 10035 | 8122.69 |
+ | 578 | 5280 | 7385.46 |
+ | 579 | 1050 | 802.92 |
+ | 6 | 5830 | 5460.79 |
+ | 14 | 5400 | 6105.85 |
+ | 27 | 2900 | 3772.87 |
+ | 50 | 2815 | 4198.3 |
+ | 124 | 10390 | 8707.78 |
+ | 158 | 2900 | 4522.79 |
+ | 173 | 5390 | 7872.1 |
+
+
+3. Compare actual target revenue to predicted revenue.
+ The demand query returns predicted surge labels with confidence, which helps product and operations teams decide where to watch capacity or risk pressure. The revenue query compares known target revenue to predicted revenue, which helps reviewers understand whether the model is directionally useful for planning.
+
+ Both queries score persisted models without leaving Oracle Database. That keeps sensitive finance records close to the models and gives technical teams SQL evidence for each prediction.
+
+
+## Acknowledgements
+
+* **Author** - Pat Shepherd, Senior Principal Database Product Manager
+* **Contributor** - Linda Foinding, Principal Database Product Manager
+* **Last Updated By/Date** - Oracle Database Product Management, June 2026
diff --git a/livestack-workshop-finance/readme.md b/livestack-workshop-finance/readme.md
new file mode 100644
index 000000000..68778230e
--- /dev/null
+++ b/livestack-workshop-finance/readme.md
@@ -0,0 +1,26 @@
+# Finance LiveStack Workshop Output
+
+## Introduction
+
+This folder contains the generated Finance LiveStack LiveLab grounded in the current finance stack and validated against the `LLUSER` Autonomous Database build.
+
+### Objectives
+
+- Keep the generated workshop files together for local review.
+- Preserve the SQL handoff loader used to rebuild the finance schema.
+- Provide the manifest files needed for LiveLabs packaging.
+
+Estimated Time: **1 minute**
+
+## Task 1: Review the output files
+
+1. Open `index.html` from the local Python server to review the generated workshop landing page.
+2. Open `workshops/sandbox/manifest.json` or `workshops/tenancy/manifest.json` when you need the LiveLabs manifest.
+3. Use `finance-handoff-loader.sql` and `admin-prepare-lluser.sql` when you need to rebuild the database from the current finance stack.
+
+## Acknowledgements
+
+* **Author** - Pat Shepherd, Senior Principal Database Product Manager
+* **Contributor** - Linda Foinding, Principal Database Product Manager
+* **Last Updated By/Date** - Oracle Database Product Management, June 2026
+
diff --git a/livestack-workshop-finance/risk-operations-dashboard/images/dashboard-evidence.svg b/livestack-workshop-finance/risk-operations-dashboard/images/dashboard-evidence.svg
new file mode 100644
index 000000000..324137687
--- /dev/null
+++ b/livestack-workshop-finance/risk-operations-dashboard/images/dashboard-evidence.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/livestack-workshop-finance/risk-operations-dashboard/images/risk-operations-dashboard-runbook.png b/livestack-workshop-finance/risk-operations-dashboard/images/risk-operations-dashboard-runbook.png
new file mode 100644
index 000000000..6e9f930c6
Binary files /dev/null and b/livestack-workshop-finance/risk-operations-dashboard/images/risk-operations-dashboard-runbook.png differ
diff --git a/livestack-workshop-finance/risk-operations-dashboard/images/risk-operations-dashboard.png b/livestack-workshop-finance/risk-operations-dashboard/images/risk-operations-dashboard.png
new file mode 100644
index 000000000..6e9f930c6
Binary files /dev/null and b/livestack-workshop-finance/risk-operations-dashboard/images/risk-operations-dashboard.png differ
diff --git a/livestack-workshop-finance/risk-operations-dashboard/risk-operations-dashboard.md b/livestack-workshop-finance/risk-operations-dashboard/risk-operations-dashboard.md
new file mode 100644
index 000000000..a6b6aec3e
--- /dev/null
+++ b/livestack-workshop-finance/risk-operations-dashboard/risk-operations-dashboard.md
@@ -0,0 +1,106 @@
+# Risk and Operations Dashboard
+
+## Introduction
+
+This lab recreates the evidence behind the application dashboard. You query critical risk signals, client exposure, transaction value, service pressure, and agent action history directly from the database.
+
+The dashboard is the workshop's first decision surface. It turns the foundation from Lab 1 into operating measures that risk leaders can use to decide which signals, products, and client exposures need review first.
+
+
+
+### Objectives
+
+- Calculate risk and exposure KPIs.
+- Identify products with high signal exposure.
+
+Estimated Time: **10 minutes**
+
+### Operating Story
+
+| Step | Finance focus |
+| --- | --- |
+| Business Problem | Risk teams need a shared view of exposure, transaction pressure, and service capacity. |
+| Technical Challenge | App and data teams need one explainable query path instead of separate pipelines for signals, products, transactions, and service data. |
+| Persona Focus | Risk operations leaders read the dashboard; database and application developers prove where the dashboard evidence comes from. |
+| What You Will Prove | Dashboard metrics are database-backed and can be explained with SQL. |
+| Database Capability | Converged SQL aggregates finance views, transaction data, service records, and audit tables. |
+| Outcome | Operators can move from a dashboard KPI to trusted detail without changing systems. |
+
+Persona focus: You support the risk operations leader by showing that one database query path can explain the dashboard instead of hiding work across integration layers.
+
+## Task 1: Calculate risk signal KPIs
+
+1. Run the dashboard aggregate query.
+
+ ```sql
+
+ SELECT COUNT(*) AS total_signals,
+ ROUND(AVG(criticality_score), 1) AS avg_criticality,
+ SUM(CASE WHEN criticality_score >= 80 THEN 1 ELSE 0 END) AS high_risk_signals,
+ SUM(exposure_count) AS total_exposure,
+ SUM(cases_opened_count) AS cases_opened
+ FROM risk_signals_v;
+
+ ```
+
+ Expected output: Dashboard KPI Summary
+
+ | Total Signals | Avg Criticality | High Risk Signals | Total Exposure | Cases Opened |
+ | --- | --- | --- | --- | --- |
+ | 5000 | 41.2 | 9 | 1602966769 | 5657933 |
+
+
+2. Interpret the result.
+ A risk signal is a monitored event that may require review. In this workshop, signals can come from product mentions, customer activity, transactions, service pressure, or other finance operations data. The total signal count shows how much activity the dashboard is watching, while average criticality shows the overall severity of that activity.
+
+ The high-risk count is the number of signals with a criticality score of 80 or higher. A higher count means more issues may need immediate analyst review, case triage, or automated follow-up from the operations agent. It does not mean every item is confirmed fraud or a confirmed incident; it means the dashboard has found more items that cross the bank's review threshold.
+
+## Task 2: Find top product exposure
+
+1. Run this product exposure query.
+
+ ```sql
+
+ SELECT fp.financial_product_name,
+ fi.institution_name,
+ fp.product_category,
+ COUNT(DISTINCT sp.post_id) AS signal_count,
+ ROUND(AVG(sp.virality_score), 1) AS avg_criticality,
+ SUM(sp.views_count) AS exposure_count
+ FROM post_product_mentions ppm
+ JOIN social_posts sp ON sp.post_id = ppm.post_id
+ JOIN finance_products_v fp ON fp.financial_product_id = ppm.product_id
+ JOIN finance_institutions_v fi ON fi.institution_id = fp.institution_id
+ GROUP BY fp.financial_product_name, fi.institution_name, fp.product_category
+ ORDER BY avg_criticality DESC, exposure_count DESC
+ FETCH FIRST 10 ROWS ONLY;
+
+ ```
+
+ Expected output: Top Product Exposure
+
+ | Financial Product Name | Institution Name | Product Category | Signal Count | Avg Criticality | Exposure Count |
+ | --- | --- | --- | --- | --- | --- |
+ | Carbon Credit Custody | IPA Direct Finance | Carbon Markets | 51 | 46 | 30212024 |
+ | Auto Loan Digital Offer | NorthBridge Investments | Consumer Lending | 48 | 45.9 | 66064101 |
+ | KYC Refresh Workflow | NorthBridge Investments | Compliance Services | 41 | 45.6 | 37993643 |
+ | Managed ETF Portfolio | Horizon Capital | Wealth Management | 29 | 45.3 | 52445042 |
+ | Loan Portfolio Review | LedgerGrade Connect | Risk Analytics | 45 | 45.1 | 42518770 |
+ | 529 Education Savings Plan | Harvest Commercial Bank | Investments | 41 | 45 | 20763811 |
+ | Small Business Term Loan | Meridian Trust Bank | Commercial Lending | 40 | 44.6 | 15504074 |
+ | Corporate Card Program | Horizon Capital | Cards and Payments | 37 | 44 | 4680777 |
+ | Mortgage Pre-Approval | NorthBridge Investments | Mortgage Lending | 46 | 43.9 | 23334598 |
+ | Digital Wallet Account | SecureLedger Compliance | Payments | 48 | 43.8 | 37616607 |
+
+
+2. Use the top rows to explain dashboard priority.
+ Each row shows a financial product associated with monitored risk signals. `Signal Count` is the number of distinct posts or events tied to the product. `Avg Criticality` shows how severe those signals are on average. `Exposure Count` estimates how many views or interactions those signals reached.
+
+ A product with many signals, high average criticality, and high exposure should move to the top of the dashboard review queue. That combination means the issue is showing up repeatedly, scoring as more severe, and reaching more people. For a financial institution, that can raise client, regulatory, reputational, or operational risk.
+
+
+## Acknowledgements
+
+* **Author** - Pat Shepherd, Senior Principal Database Product Manager
+* **Contributor** - Linda Foinding, Principal Database Product Manager
+* **Last Updated By/Date** - Oracle Database Product Management, June 2026
diff --git a/livestack-workshop-finance/risk-signal-vector-search/images/vector-product-search-runbook.png b/livestack-workshop-finance/risk-signal-vector-search/images/vector-product-search-runbook.png
new file mode 100644
index 000000000..8dbe7af37
Binary files /dev/null and b/livestack-workshop-finance/risk-signal-vector-search/images/vector-product-search-runbook.png differ
diff --git a/livestack-workshop-finance/risk-signal-vector-search/images/vector-product-search.png b/livestack-workshop-finance/risk-signal-vector-search/images/vector-product-search.png
new file mode 100644
index 000000000..8dbe7af37
Binary files /dev/null and b/livestack-workshop-finance/risk-signal-vector-search/images/vector-product-search.png differ
diff --git a/livestack-workshop-finance/risk-signal-vector-search/images/vector-search.svg b/livestack-workshop-finance/risk-signal-vector-search/images/vector-search.svg
new file mode 100644
index 000000000..7c489221d
--- /dev/null
+++ b/livestack-workshop-finance/risk-signal-vector-search/images/vector-search.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/livestack-workshop-finance/risk-signal-vector-search/risk-signal-vector-search.md b/livestack-workshop-finance/risk-signal-vector-search/risk-signal-vector-search.md
new file mode 100644
index 000000000..02934bc38
--- /dev/null
+++ b/livestack-workshop-finance/risk-signal-vector-search/risk-signal-vector-search.md
@@ -0,0 +1,112 @@
+# Risk Signal Intelligence with AI Vector Search
+
+## Introduction
+
+This lab uses current finance embeddings to search by meaning instead of exact keywords. You compare natural-language risk phrases to product and signal embeddings using ADMIN.ALL\_MINILM\_L12\_V2.
+
+Risk analysts often know the intent of a question before they know the exact product name, signal phrase, or table value. Vector search helps them find relevant mortgage, AML, fraud, and exposure evidence even when the source text uses different wording.
+
+
+
+### Objectives
+
+- Run semantic product search.
+- Run semantic risk signal search.
+
+Estimated Time: **12 minutes**
+
+### Operating Story
+
+| Step | Finance focus |
+| --- | --- |
+| Business Problem | Risk analysts cannot rely only on keyword matching when signals use different words for similar exposure. |
+| Technical Challenge | AI and data teams need semantic search without exporting governed finance text to an external embedding pipeline. |
+| Persona Focus | Risk analysts ask by intent; AI engineers and database developers keep embedding and search work inside the database. |
+| What You Will Prove | Vector search ranks finance products and risk signals by semantic similarity. |
+| Database Capability | VECTOR\_EMBEDDING, vector columns, and VECTOR\_DISTANCE run inside Oracle AI Database. |
+| Outcome | Analysts can find mortgage, AML, fraud, and exposure signals even when wording varies. |
+
+Persona focus: You support the risk analyst with semantic search while keeping source text, embeddings, and similarity scoring in the governed database boundary.
+
+## Task 1: Search products by meaning
+
+1. Search for products related to mortgage pre-approval risk.
+
+ ```sql
+
+ SELECT p.product_name,
+ p.category,
+ ROUND(1 - VECTOR_DISTANCE(
+ pe.embedding,
+ VECTOR_EMBEDDING(ADMIN.ALL_MINILM_L12_V2 USING 'mortgage pre-approval risk' AS DATA),
+ COSINE), 4) AS similarity
+ FROM product_embeddings pe
+ JOIN products p ON p.product_id = pe.product_id
+ ORDER BY VECTOR_DISTANCE(
+ pe.embedding,
+ VECTOR_EMBEDDING(ADMIN.ALL_MINILM_L12_V2 USING 'mortgage pre-approval risk' AS DATA),
+ COSINE)
+ FETCH FIRST 5 ROWS ONLY;
+
+ ```
+
+ Expected output: Mortgage Product Matches
+
+ | Product Name | Category | Similarity |
+ | --- | --- | --- |
+ | Mortgage Pre-Approval | Mortgage Lending | 0.6875 |
+ | Loan Modification Review | Loan Servicing | 0.4409 |
+ | Loan Portfolio Review | Risk Analytics | 0.4267 |
+ | Risk Tolerance Assessment | Advisory | 0.4198 |
+ | Adjustable Rate Mortgage | Mortgage Lending | 0.4161 |
+
+
+2. Review the ranked products.
+ The expected top result is `Mortgage Pre-Approval`, followed by related lending and risk analytics products. The ranking matters because it proves the search is not a simple keyword lookup; it also finds products that are semantically close to the analyst's risk intent.
+
+ In the broader workflow, these ranked products can become the next filter for dashboard review, product exposure analysis, or an operations agent action.
+
+## Task 2: Search risk signals by meaning
+
+1. Search risk signals for fraud and AML exposure language.
+
+ ```sql
+
+ SELECT sp.post_id AS signal_id,
+ SUBSTR(sp.post_text, 1, 120) AS signal_excerpt,
+ ROUND(1 - VECTOR_DISTANCE(
+ se.embedding,
+ VECTOR_EMBEDDING(ADMIN.ALL_MINILM_L12_V2 USING 'fraud signals aml exposure' AS DATA),
+ COSINE), 4) AS similarity
+ FROM signal_embeddings se
+ JOIN social_posts sp ON sp.post_id = se.post_id
+ ORDER BY VECTOR_DISTANCE(
+ se.embedding,
+ VECTOR_EMBEDDING(ADMIN.ALL_MINILM_L12_V2 USING 'fraud signals aml exposure' AS DATA),
+ COSINE)
+ FETCH FIRST 5 ROWS ONLY;
+
+ ```
+
+ Expected output: AML Signal Matches
+
+ | Signal Id | Signal Excerpt | Similarity |
+ | --- | --- | --- |
+ | 2290 | AML screening update affects Liquidity Investment Sweep; FraudGuard Operations suspicious ACH and sanctions case review | 0.6478 |
+ | 170 | AML screening update affects Deposit Attrition Alert; Catalyst Insurance Group suspicious ACH and sanctions case review | 0.6137 |
+ | 1330 | AML screening update affects Deposit Attrition Alert; Catalyst Insurance Group suspicious ACH and sanctions case review | 0.6137 |
+ | 1610 | AML screening update affects Deposit Attrition Alert; Catalyst Insurance Group suspicious ACH and sanctions case review | 0.6137 |
+ | 3770 | AML screening update affects High-Yield Savings Account; Meridian Trust Bank suspicious ACH and sanctions case review vo | 0.6117 |
+
+
+2. Compare the excerpts and scores.
+ The returned excerpts contain AML, fraud, sanctions, and suspicious activity language even though the search phrase is short. The similarity score gives analysts a ranked review queue instead of an unordered pile of signal text.
+
+ This supports the workshop story by connecting dashboard risk signals to semantic investigation. The source text, embeddings, query phrase, and similarity scoring all remain inside Oracle Database.
+
+
+## Acknowledgements
+
+* **Author** - Pat Shepherd, Senior Principal Database Product Manager
+* **Contributor** - Linda Foinding, Principal Database Product Manager
+* **Last Updated By/Date** - Oracle Database Product Management, June 2026
diff --git a/livestack-workshop-finance/service-sla-spatial/images/service-sla-spatial-runbook.png b/livestack-workshop-finance/service-sla-spatial/images/service-sla-spatial-runbook.png
new file mode 100644
index 000000000..db0fda33a
Binary files /dev/null and b/livestack-workshop-finance/service-sla-spatial/images/service-sla-spatial-runbook.png differ
diff --git a/livestack-workshop-finance/service-sla-spatial/images/service-sla-spatial.png b/livestack-workshop-finance/service-sla-spatial/images/service-sla-spatial.png
new file mode 100644
index 000000000..db0fda33a
Binary files /dev/null and b/livestack-workshop-finance/service-sla-spatial/images/service-sla-spatial.png differ
diff --git a/livestack-workshop-finance/service-sla-spatial/images/spatial-coverage.svg b/livestack-workshop-finance/service-sla-spatial/images/spatial-coverage.svg
new file mode 100644
index 000000000..828a19172
--- /dev/null
+++ b/livestack-workshop-finance/service-sla-spatial/images/spatial-coverage.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/livestack-workshop-finance/service-sla-spatial/images/spatial-service-coverage-flow.svg b/livestack-workshop-finance/service-sla-spatial/images/spatial-service-coverage-flow.svg
new file mode 100644
index 000000000..d7f7c2e42
--- /dev/null
+++ b/livestack-workshop-finance/service-sla-spatial/images/spatial-service-coverage-flow.svg
@@ -0,0 +1,67 @@
+
diff --git a/livestack-workshop-finance/service-sla-spatial/service-sla-spatial.md b/livestack-workshop-finance/service-sla-spatial/service-sla-spatial.md
new file mode 100644
index 000000000..da1e39a61
--- /dev/null
+++ b/livestack-workshop-finance/service-sla-spatial/service-sla-spatial.md
@@ -0,0 +1,112 @@
+# Client Service and SLA Coverage with Oracle Spatial
+
+## Introduction
+
+This lab uses Oracle Spatial to reason about service centers, SLA zones, and demand regions. You calculate distance between service centers and the New York Metro demand region, then inspect service pressure.
+
+Risk and fraud decisions often create service work: client outreach, case routing, product review, and document handling. Spatial analysis helps operations leaders see whether service capacity is near the demand region that needs support.
+
+
+
+
+
+### Objectives
+
+- Find service centers nearest to New York Metro.
+- Inspect SLA zone coverage.
+
+Estimated Time: **10 minutes**
+
+### Operating Story
+
+| Step | Finance focus |
+| --- | --- |
+| Business Problem | Service leaders need to know whether capacity is close enough to high-demand regions. |
+| Technical Challenge | Operations teams need location-aware decisions without moving geography, service centers, and SLA zones into separate mapping systems. |
+| Persona Focus | Service operations leaders evaluate coverage; database developers prove distance and SLA evidence with spatial SQL. |
+| What You Will Prove | Spatial data can quantify distance and regional service pressure in SQL. |
+| Database Capability | SDO\_GEOMETRY, SDO\_GEOM.SDO\_DISTANCE, regions, and SLA zones support coverage analysis. |
+| Outcome | Operations teams can prioritize service capacity based on geography and demand. |
+
+Persona focus: You support a service operations leader by turning location data into queryable coverage evidence for capacity and SLA decisions.
+
+## Task 1: Calculate service center distance to New York Metro
+
+1. Run this spatial distance query.
+
+ ```sql
+
+ SELECT sc.service_center_name,
+ sc.city,
+ sc.state_province,
+ ROUND(SDO_GEOM.SDO_DISTANCE(fc.location, dr.boundary, 0.005, 'unit=KM'), 2) AS boundary_distance_km,
+ dr.region_name,
+ dr.demand_index
+ FROM service_centers_v sc
+ JOIN fulfillment_centers fc ON fc.center_id = sc.service_center_id
+ CROSS JOIN demand_regions dr
+ WHERE dr.region_name = 'New York Metro'
+ ORDER BY SDO_GEOM.SDO_DISTANCE(fc.location, dr.boundary, 0.005, 'unit=KM')
+ FETCH FIRST 10 ROWS ONLY;
+
+ ```
+
+ Expected output: New York Service Coverage
+
+ | Service Center Name | City | State Province | Boundary Distance Km | Region Name | Demand Index |
+ | --- | --- | --- | --- | --- | --- |
+ | Edison Wealth Service Center | Edison | New Jersey | 9.48 | New York Metro | 91.0 |
+ | Middletown Mid-Atlantic Branch Hub | Middletown | Delaware | 160.48 | New York Metro | 91.0 |
+ | Aberdeen East Coast Banking Center | Aberdeen | Maryland | 187.21 | New York Metro | 91.0 |
+ | Fall River Northeast Service Hub | Fall River | Massachusetts | 218.48 | New York Metro | 91.0 |
+ | Etna Midwest Specialty Finance Desk | Etna | Ohio | 713.52 | New York Metro | 91.0 |
+ | Romulus Great Lakes Mortgage Hub | Romulus | Michigan | 767.96 | New York Metro | 91.0 |
+ | Concord Southeast Micro Branch | Concord | North Carolina | 781.6 | New York Metro | 91.0 |
+ | Plainfield Heartland Banking Hub | Plainfield | Indiana | 1031.93 | New York Metro | 91.0 |
+ | Lebanon Central Banking Center | Lebanon | Tennessee | 1144.17 | New York Metro | 91.0 |
+ | Joliet Midwest Risk Desk | Joliet | Illinois | 1152.2 | New York Metro | 91.0 |
+
+
+2. Review the nearest service centers.
+ Expected nearest service center: Edison Wealth Service Center. New York Metro has demand index 91.
+
+ The distance column tells operations which service centers can respond fastest to a high-demand region. The demand index explains why the region matters: a high-demand area may need more capacity, closer routing, or stricter monitoring when risk signals increase.
+
+## Task 2: Summarize SLA zone coverage
+
+1. Run this SLA zone summary.
+
+ ```sql
+
+ SELECT zone_type,
+ COUNT(*) AS zones,
+ MIN(max_delivery_hrs) AS min_delivery_hrs,
+ MAX(max_delivery_hrs) AS max_delivery_hrs,
+ ROUND(AVG(max_delivery_hrs), 1) AS avg_delivery_hrs
+ FROM fulfillment_zones
+ GROUP BY zone_type
+ ORDER BY avg_delivery_hrs;
+
+ ```
+
+ Expected output: SLA Zone Counts
+
+ | Zone Type | Zones | Min Delivery Hrs | Max Delivery Hrs | Avg Delivery Hrs |
+ | --- | --- | --- | --- | --- |
+ | express | 30 | 8 | 8 | 8 |
+ | overnight | 30 | 16 | 16 | 16 |
+ | standard | 30 | 24 | 24 | 24 |
+ | economy | 30 | 72 | 72 | 72 |
+
+
+2. Compare the service levels.
+ The result shows how zone type maps to delivery-hour commitments. Express and overnight zones represent faster response promises, while standard and economy zones represent longer service windows.
+
+ This matters because risk operations are not finished when a signal is detected. The bank also needs to know whether the service network can meet the response time implied by the case priority.
+
+
+## Acknowledgements
+
+* **Author** - Pat Shepherd, Senior Principal Database Product Manager
+* **Contributor** - Linda Foinding, Principal Database Product Manager
+* **Last Updated By/Date** - Oracle Database Product Management, June 2026
diff --git a/livestack-workshop-finance/transaction-case-duality/images/json-duality.svg b/livestack-workshop-finance/transaction-case-duality/images/json-duality.svg
new file mode 100644
index 000000000..6fdb7065b
--- /dev/null
+++ b/livestack-workshop-finance/transaction-case-duality/images/json-duality.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/livestack-workshop-finance/transaction-case-duality/images/transaction-json-duality-runbook.png b/livestack-workshop-finance/transaction-case-duality/images/transaction-json-duality-runbook.png
new file mode 100644
index 000000000..34a647499
Binary files /dev/null and b/livestack-workshop-finance/transaction-case-duality/images/transaction-json-duality-runbook.png differ
diff --git a/livestack-workshop-finance/transaction-case-duality/images/transaction-json-duality.png b/livestack-workshop-finance/transaction-case-duality/images/transaction-json-duality.png
new file mode 100644
index 000000000..34a647499
Binary files /dev/null and b/livestack-workshop-finance/transaction-case-duality/images/transaction-json-duality.png differ
diff --git a/livestack-workshop-finance/transaction-case-duality/transaction-case-duality.md b/livestack-workshop-finance/transaction-case-duality/transaction-case-duality.md
new file mode 100644
index 000000000..b935fc51b
--- /dev/null
+++ b/livestack-workshop-finance/transaction-case-duality/transaction-case-duality.md
@@ -0,0 +1,99 @@
+# Transaction and Case Documents with JSON Relational Duality
+
+## Introduction
+
+This lab uses JSON Relational Duality to inspect transaction-shaped documents over relational tables. The application can consume document-style payloads while the database keeps relational integrity and SQL access.
+
+Transaction and case operations need both application-friendly documents and governed relational evidence. This lab shows how one transaction can be exposed as JSON for an application while remaining queryable with SQL for analysts and database developers.
+
+
+
+### Objectives
+
+- Read transaction documents from a duality view.
+- Use SQL/JSON to project document fields.
+
+Estimated Time: **10 minutes**
+
+### Operating Story
+
+| Step | Finance focus |
+| --- | --- |
+| Business Problem | Application teams want document-shaped transaction data, while risk teams need relational controls. |
+| Technical Challenge | Developers need API-friendly JSON without copying transaction records into a separate document store. |
+| Persona Focus | Application developers serve document payloads while database developers preserve relational governance and SQL access. |
+| What You Will Prove | JSON Relational Duality exposes transaction documents without duplicating data. |
+| Database Capability | Duality views and SQL/JSON functions expose JSON and relational access together. |
+| Outcome | Transaction operations can serve application and analytics needs from one source. |
+
+Persona focus: You are the application/database developer showing how Seer Bank can expose transaction documents while keeping governed relational evidence intact.
+
+## Task 1: Inspect document-shaped transactions
+
+1. Run this query against the transaction duality view.
+
+ ```sql
+
+ SELECT JSON_SERIALIZE(data PRETTY) AS transaction_document
+ FROM orders_dv
+ FETCH FIRST 1 ROW ONLY;
+
+ ```
+
+ Expected output: Transaction Document Excerpt
+
+ | Transaction Document |
+ | --- |
+ | { "\_id" : 519, "\_metadata" : { "etag" : "A373EE416A88F30340355B478ADC0179", "asof" : "00002AB7EFDA711D" }, "customerId" : 205, "status" : "cancelle... |
+
+
+2. Expand the document in SQL Worksheet.
+ The \_id value is stored in the JSON document while source data remains relational. Fields such as `customerId`, `status`, totals, timestamps, and line items give the application a document-shaped payload without copying the transaction to a separate document database.
+
+ This is relevant to the workshop story because risk and operations teams can inspect the same transaction from two angles: API-ready JSON for the application and governed relational rows for analysis.
+
+## Task 2: Project JSON fields with SQL
+
+1. Run this SQL/JSON projection query.
+
+ ```sql
+
+ SELECT JSON_VALUE(od.data, '$._id' RETURNING NUMBER) AS transaction_id,
+ JSON_VALUE(od.data, '$.status') AS transaction_status,
+ c.email AS client_email
+ FROM orders_dv od
+ JOIN customers c
+ ON c.customer_id = JSON_VALUE(od.data, '$.customerId' RETURNING NUMBER)
+ WHERE JSON_VALUE(od.data, '$._id' RETURNING NUMBER) IS NOT NULL
+ ORDER BY transaction_id
+ FETCH FIRST 10 ROWS ONLY;
+
+ ```
+
+ Expected output: JSON Field Projection
+
+ The exact email values may differ by load, but `Transaction Status` and `Client Email` should not be blank.
+
+ | Transaction Id | Transaction Status | Client Email |
+ | --- | --- | --- |
+ | 1 | confirmed | client@example.com |
+ | 2 | processing | client@example.com |
+ | 3 | routed | client@example.com |
+ | 4 | completed | client@example.com |
+ | 5 | completed | client@example.com |
+ | 6 | completed | client@example.com |
+ | 7 | cancelled | client@example.com |
+ | 8 | pending | client@example.com |
+ | 9 | confirmed | client@example.com |
+ | 10 | processing | client@example.com |
+
+
+2. Review the columns returned from the JSON document.
+ `Transaction Id` and `Transaction Status` are projected from the JSON document. The document stores the client reference as `customerId`, so the query joins back to `CUSTOMERS` to return `Client Email`. This shows how the application can use document-shaped transaction data while analysts can still join to governed relational tables.
+
+
+## Acknowledgements
+
+* **Author** - Pat Shepherd, Senior Principal Database Product Manager
+* **Contributor** - Linda Foinding, Principal Database Product Manager
+* **Last Updated By/Date** - Oracle Database Product Management, June 2026
diff --git a/livestack-workshop-finance/workshops/desktop/index.html b/livestack-workshop-finance/workshops/desktop/index.html
new file mode 100644
index 000000000..307dce355
--- /dev/null
+++ b/livestack-workshop-finance/workshops/desktop/index.html
@@ -0,0 +1,72 @@
+
+
+
+
+
+
+
+ Oracle LiveLabs
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Oracle LiveLabs
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/livestack-workshop-finance/workshops/desktop/manifest.json b/livestack-workshop-finance/workshops/desktop/manifest.json
new file mode 100644
index 000000000..ba5fc5a58
--- /dev/null
+++ b/livestack-workshop-finance/workshops/desktop/manifest.json
@@ -0,0 +1,76 @@
+{
+ "workshoptitle": "Build Financial Intelligence with Oracle Database 26ai",
+ "help": "livelabs-help-db_us@oracle.com",
+ "tutorials": [
+ {
+ "title": "Introduction",
+ "description": "The Seer Bank finance intelligence story and workshop goals.",
+ "filename": "../../introduction/introduction.md"
+ },
+ {
+ "title": "Getting Started",
+ "description": "Launch the environment and open Database Actions SQL Worksheet.",
+ "filename": "../../getting-started/getting-started.md"
+ },
+ {
+ "title": "Lab 1: Finance Data Foundation",
+ "description": "Inspect the finance schema foundation and current object families.",
+ "filename": "../../finance-data-foundation/finance-data-foundation.md"
+ },
+ {
+ "title": "Lab 2: Risk and Operations Dashboard",
+ "description": "Query dashboard KPIs, signal exposure, and product risk evidence.",
+ "filename": "../../risk-operations-dashboard/risk-operations-dashboard.md"
+ },
+ {
+ "title": "Lab 3: Transaction and Case Documents",
+ "description": "Use JSON Relational Duality and SQL/JSON for transaction documents.",
+ "filename": "../../transaction-case-duality/transaction-case-duality.md"
+ },
+ {
+ "title": "Lab 4: Risk Signal Intelligence",
+ "description": "Run AI Vector Search over product and signal embeddings.",
+ "filename": "../../risk-signal-vector-search/risk-signal-vector-search.md"
+ },
+ {
+ "title": "Lab 5: Financial Crime Network",
+ "description": "Use Property Graph and SQL/PGQ to analyze fraud reach.",
+ "filename": "../../financial-crime-network/financial-crime-network.md"
+ },
+ {
+ "title": "Lab 6: Client Service and SLA Coverage",
+ "description": "Use Oracle Spatial for service center and SLA region analysis.",
+ "filename": "../../service-sla-spatial/service-sla-spatial.md"
+ },
+ {
+ "title": "Lab 7: Predictive Risk, Capacity, and Revenue",
+ "description": "Inspect and score OML models inside Oracle Database.",
+ "filename": "../../predictive-risk-oml/predictive-risk-oml.md"
+ },
+ {
+ "title": "Lab 8: Governed Data Copilot",
+ "description": "Ground trusted answers in approved finance views and visible SQL.",
+ "filename": "../../governed-data-copilot/governed-data-copilot.md"
+ },
+ {
+ "title": "Lab 9: AI Operations Agent Console",
+ "description": "Call trusted PL/SQL tools and inspect action audit history.",
+ "filename": "../../ai-operations-agent-console/ai-operations-agent-console.md"
+ },
+ {
+ "title": "Lab 10: Conclusion",
+ "description": "Connect the finance decision path into one operating pattern.",
+ "filename": "../../conclusion-business-outcomes/conclusion-business-outcomes.md"
+ },
+ {
+ "title": "Lab 11: Final Quiz",
+ "description": "Check your understanding with scored questions.",
+ "filename": "../../final-quiz/final-quiz.md"
+ },
+ {
+ "title": "Need Help?",
+ "description": "Solutions to common problems and directions for receiving Live Help.",
+ "filename": "https://oracle-livelabs.github.io/common/labs/need-help/need-help-freetier.md"
+ }
+ ]
+}
diff --git a/livestack-workshop-finance/workshops/sandbox/index.html b/livestack-workshop-finance/workshops/sandbox/index.html
new file mode 100644
index 000000000..307dce355
--- /dev/null
+++ b/livestack-workshop-finance/workshops/sandbox/index.html
@@ -0,0 +1,72 @@
+
+
+
+
+
+
+
+ Oracle LiveLabs
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Oracle LiveLabs
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/livestack-workshop-finance/workshops/sandbox/manifest.json b/livestack-workshop-finance/workshops/sandbox/manifest.json
new file mode 100644
index 000000000..ba5fc5a58
--- /dev/null
+++ b/livestack-workshop-finance/workshops/sandbox/manifest.json
@@ -0,0 +1,76 @@
+{
+ "workshoptitle": "Build Financial Intelligence with Oracle Database 26ai",
+ "help": "livelabs-help-db_us@oracle.com",
+ "tutorials": [
+ {
+ "title": "Introduction",
+ "description": "The Seer Bank finance intelligence story and workshop goals.",
+ "filename": "../../introduction/introduction.md"
+ },
+ {
+ "title": "Getting Started",
+ "description": "Launch the environment and open Database Actions SQL Worksheet.",
+ "filename": "../../getting-started/getting-started.md"
+ },
+ {
+ "title": "Lab 1: Finance Data Foundation",
+ "description": "Inspect the finance schema foundation and current object families.",
+ "filename": "../../finance-data-foundation/finance-data-foundation.md"
+ },
+ {
+ "title": "Lab 2: Risk and Operations Dashboard",
+ "description": "Query dashboard KPIs, signal exposure, and product risk evidence.",
+ "filename": "../../risk-operations-dashboard/risk-operations-dashboard.md"
+ },
+ {
+ "title": "Lab 3: Transaction and Case Documents",
+ "description": "Use JSON Relational Duality and SQL/JSON for transaction documents.",
+ "filename": "../../transaction-case-duality/transaction-case-duality.md"
+ },
+ {
+ "title": "Lab 4: Risk Signal Intelligence",
+ "description": "Run AI Vector Search over product and signal embeddings.",
+ "filename": "../../risk-signal-vector-search/risk-signal-vector-search.md"
+ },
+ {
+ "title": "Lab 5: Financial Crime Network",
+ "description": "Use Property Graph and SQL/PGQ to analyze fraud reach.",
+ "filename": "../../financial-crime-network/financial-crime-network.md"
+ },
+ {
+ "title": "Lab 6: Client Service and SLA Coverage",
+ "description": "Use Oracle Spatial for service center and SLA region analysis.",
+ "filename": "../../service-sla-spatial/service-sla-spatial.md"
+ },
+ {
+ "title": "Lab 7: Predictive Risk, Capacity, and Revenue",
+ "description": "Inspect and score OML models inside Oracle Database.",
+ "filename": "../../predictive-risk-oml/predictive-risk-oml.md"
+ },
+ {
+ "title": "Lab 8: Governed Data Copilot",
+ "description": "Ground trusted answers in approved finance views and visible SQL.",
+ "filename": "../../governed-data-copilot/governed-data-copilot.md"
+ },
+ {
+ "title": "Lab 9: AI Operations Agent Console",
+ "description": "Call trusted PL/SQL tools and inspect action audit history.",
+ "filename": "../../ai-operations-agent-console/ai-operations-agent-console.md"
+ },
+ {
+ "title": "Lab 10: Conclusion",
+ "description": "Connect the finance decision path into one operating pattern.",
+ "filename": "../../conclusion-business-outcomes/conclusion-business-outcomes.md"
+ },
+ {
+ "title": "Lab 11: Final Quiz",
+ "description": "Check your understanding with scored questions.",
+ "filename": "../../final-quiz/final-quiz.md"
+ },
+ {
+ "title": "Need Help?",
+ "description": "Solutions to common problems and directions for receiving Live Help.",
+ "filename": "https://oracle-livelabs.github.io/common/labs/need-help/need-help-freetier.md"
+ }
+ ]
+}
diff --git a/livestack-workshop-finance/workshops/tenancy/index.html b/livestack-workshop-finance/workshops/tenancy/index.html
new file mode 100644
index 000000000..307dce355
--- /dev/null
+++ b/livestack-workshop-finance/workshops/tenancy/index.html
@@ -0,0 +1,72 @@
+
+
+
+
+
+
+
+ Oracle LiveLabs
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Oracle LiveLabs
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/livestack-workshop-finance/workshops/tenancy/manifest.json b/livestack-workshop-finance/workshops/tenancy/manifest.json
new file mode 100644
index 000000000..ba5fc5a58
--- /dev/null
+++ b/livestack-workshop-finance/workshops/tenancy/manifest.json
@@ -0,0 +1,76 @@
+{
+ "workshoptitle": "Build Financial Intelligence with Oracle Database 26ai",
+ "help": "livelabs-help-db_us@oracle.com",
+ "tutorials": [
+ {
+ "title": "Introduction",
+ "description": "The Seer Bank finance intelligence story and workshop goals.",
+ "filename": "../../introduction/introduction.md"
+ },
+ {
+ "title": "Getting Started",
+ "description": "Launch the environment and open Database Actions SQL Worksheet.",
+ "filename": "../../getting-started/getting-started.md"
+ },
+ {
+ "title": "Lab 1: Finance Data Foundation",
+ "description": "Inspect the finance schema foundation and current object families.",
+ "filename": "../../finance-data-foundation/finance-data-foundation.md"
+ },
+ {
+ "title": "Lab 2: Risk and Operations Dashboard",
+ "description": "Query dashboard KPIs, signal exposure, and product risk evidence.",
+ "filename": "../../risk-operations-dashboard/risk-operations-dashboard.md"
+ },
+ {
+ "title": "Lab 3: Transaction and Case Documents",
+ "description": "Use JSON Relational Duality and SQL/JSON for transaction documents.",
+ "filename": "../../transaction-case-duality/transaction-case-duality.md"
+ },
+ {
+ "title": "Lab 4: Risk Signal Intelligence",
+ "description": "Run AI Vector Search over product and signal embeddings.",
+ "filename": "../../risk-signal-vector-search/risk-signal-vector-search.md"
+ },
+ {
+ "title": "Lab 5: Financial Crime Network",
+ "description": "Use Property Graph and SQL/PGQ to analyze fraud reach.",
+ "filename": "../../financial-crime-network/financial-crime-network.md"
+ },
+ {
+ "title": "Lab 6: Client Service and SLA Coverage",
+ "description": "Use Oracle Spatial for service center and SLA region analysis.",
+ "filename": "../../service-sla-spatial/service-sla-spatial.md"
+ },
+ {
+ "title": "Lab 7: Predictive Risk, Capacity, and Revenue",
+ "description": "Inspect and score OML models inside Oracle Database.",
+ "filename": "../../predictive-risk-oml/predictive-risk-oml.md"
+ },
+ {
+ "title": "Lab 8: Governed Data Copilot",
+ "description": "Ground trusted answers in approved finance views and visible SQL.",
+ "filename": "../../governed-data-copilot/governed-data-copilot.md"
+ },
+ {
+ "title": "Lab 9: AI Operations Agent Console",
+ "description": "Call trusted PL/SQL tools and inspect action audit history.",
+ "filename": "../../ai-operations-agent-console/ai-operations-agent-console.md"
+ },
+ {
+ "title": "Lab 10: Conclusion",
+ "description": "Connect the finance decision path into one operating pattern.",
+ "filename": "../../conclusion-business-outcomes/conclusion-business-outcomes.md"
+ },
+ {
+ "title": "Lab 11: Final Quiz",
+ "description": "Check your understanding with scored questions.",
+ "filename": "../../final-quiz/final-quiz.md"
+ },
+ {
+ "title": "Need Help?",
+ "description": "Solutions to common problems and directions for receiving Live Help.",
+ "filename": "https://oracle-livelabs.github.io/common/labs/need-help/need-help-freetier.md"
+ }
+ ]
+}