WMS ID: 12080 NEW Version of LiveStack Workshop - Finance

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.
+
+![AI Operations Agent Console](images/agent-console.png " ")
+
+### 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
+    <copy>
+    SELECT detect_trending_products(48, 50) AS risk_signal_summary
+    FROM dual;
+    </copy>
+    ```
+
+    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
+    <copy>
+    SELECT log_agent_decision(
+             'RISK_SIGNAL_TEAM',
+             'ESCALATE',
+             'RISK_SIGNAL',
+             'Workshop validation escalation based on critical signal exposure'
+           ) AS result
+    FROM dual;
+    </copy>
+    ```
+
+    Expected output: Agent Decision Result
+
+    | Result |
+    | --- |
+    | Decision logged: ESCALATE by RISK\_SIGNAL\_TEAM |
+
+
+2. Inspect the latest audit rows.
+
+    ```sql
+    <copy>
+    SELECT agent_name,
+           action_type,
+           entity_type,
+           execution_status,
+           executed_at
+    FROM agent_actions
+    ORDER BY action_id DESC
+    FETCH FIRST 5 ROWS ONLY;
+    </copy>
+    ```
+
+    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

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

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.
+
+    ![Finance LiveStack badge](images/livestack-finance-badge.png " ")
+
+## 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