William A. Green
PlatformHow It WorksArchitectureGovernanceTechnologyBlog
Get Started →
Phase 04 — Governance Framework

Three risk tiers. Zero unreviewed production changes.

Every platform action is classified before execution. The traffic light system, Safe-Stop sequence, and Decision Tower approval UI ensure that no Oracle production fix runs without the right level of human oversight.

Risk Classification

The Traffic Light Framework

Risk classification happens automatically at the point of triage — before any diagnostic script runs. The classification determines what happens at the end of the workflow: autonomous execution, auto-execution with rollback, or a full human approval gate.

Oracle AI Risk Classification Framework — Tier 1 Low Risk (Auto-executes), Tier 2 Mid Risk (Auto + Rollback), Tier 3 High Risk (Approval Required)

The three-tier risk classification framework. Every Oracle action is classified before execution — the tier determines whether it runs autonomously, with a rollback window, or requires signed human approval.

🟢 Tier 1 — Low Risk

Fully Autonomous

Read-only diagnostic and reporting actions. No data is modified, no configuration is changed. The platform executes and delivers the augmented report directly to the user. No approval step.

SELECT tablespace_name, used_percent
FROM dba_tablespace_usage_metrics;

AP Invoice Hold report query
GL Period open/close status check
✓ Executes & reports automatically
🟡 Tier 2 — Mid Risk

Human-on-the-Loop

Non-destructive management actions with no permanent data changes. Auto-execute with immediate effect, but an Instant Rollback button remains active for a configurable window (default: 30 minutes).

Re-run failed Concurrent Program;
Purge old log files from spool;
Reset stuck workflow activity.
⚡ Auto-executes + rollback available
🔴 Tier 3 — High Risk

Human-in-the-Loop

Any action touching production data, system configuration, or DDL-level database changes. The platform serializes complete state and holds indefinitely — no timeout path exists that auto-executes without a signed human decision.

UPDATE stuck interface table;
ALTER SYSTEM extend tablespace;
Reverse posted GL journal entry.
🔒 Admin approval required — no exceptions
Safe-Stop Sequence

What happens when a High-Risk action is detected.

When the LLM analysis identifies a High-Risk fix as the recommended resolution path, the platform immediately activates the Safe-Stop sequence — a five-step process that ensures no action executes without a signed human decision.

1

Workflow Paused — State Serialized

n8n immediately pauses the workflow at the HITL node. The complete fix context — diagnostic evidence, LLM reasoning path, proposed SQL, and Oracle Support Note reference — is serialized to the Postgres workflow state store. The workflow can wait here indefinitely without losing context.

2

Decision Tower Notification Sent

n8n sends a structured notification to the designated approver via Slack or Teams. The notification contains three panels of evidence: the Problem (what is broken and how many records are affected), the AI Path (the diagnostic steps taken and root cause identified), and the Safety Check (the dry-run result of the proposed fix command).

3

Approval Decision Made

The approver reviews the three-panel evidence and selects one of three options: Approve (execute the fix as shown), Reject (close the incident, no action taken), or Edit SQL (modify the proposed SQL before approval). Edit SQL requires the approver to submit the amended command, which is then shown for final confirmation before execution.

4

JWT Token Validated

Upon approval, the signal carries a JWT authorization token. n8n validates this token before unpausing — preventing replay attacks where a captured approval signal is reused against a different fix request. The token is tied to the specific Request ID of this incident.

5

Fix Executes — Audit Record Written

n8n unpauses and executes the exact SQL shown in the approval notification — no substitution. Immediately after execution, a signed audit record is written to the Postgres store capturing the complete fix event: agent identity, approver identity, exact SQL, Request ID, LLM reasoning summary, and before/after state.

Approval Interface

The Decision Tower

The Decision Tower is the Slack or Teams message the approving DBA receives for every High-Risk fix request. Three panels of evidence. Three action buttons. Everything needed to make an informed decision without leaving the messaging tool.

Decision Tower Slack notification — Fix Approval Required REQ-2026-0147 with three evidence panels and Approve Fix, Reject, Edit SQL buttons

The actual Slack notification the approving DBA receives — ORA-01652 incident, EBS R12.2.10 AP module, with three evidence panels and three action buttons.

Oracle AI Platform — Fix Approval Required · REQ-2026-0147
Panel 1 — The Problem

ORA-01652 · AP Module

  • 50 invoices stuck in INCOMPLETE
  • TEMP tablespace at 99.8%
  • Active sort segments: 12
  • Largest active sort: 3.2GB
  • Environment: PROD-US-01 (EBS R12.2.10)
Panel 2 — AI Reasoning Path

Diagnostic Steps Taken

  • Script SYS-03 executed at 14:23:01
  • Root cause: TEMP exhaustion (99.8%)
  • MOS Note 123456.1 retrieved
  • Historical match: 2 prior resolutions
  • Confidence: High
Panel 3 — Safety Check

Proposed Fix

ALTER DATABASE
TEMPFILE '/oracle/oradata/temp01.dbf'
RESIZE 10240M;

Dry run: No errors. Current size: 5120M. New size: 10240M.

Compliance

The SOX/ITGC Audit Record

Every platform action — autonomous or approved — generates a signed audit record in the Postgres store. The schema is designed to satisfy SOX Section 404 and ITGC Change Management controls for system-level modifications.

FieldValue (ORA-01652 Example)SOX / ITGC Purpose
request_idREQ-2026-0147Unique identifier linking the incident, diagnostic output, approval decision, and fix execution into a single auditable event.
executing_agentoracle-ai-platform/n8nIdentity of the automated agent that executed the fix — satisfies the requirement to attribute every system change to a named actor.
approving_adminjsmith@company.comIdentity of the human who approved the High-Risk fix — JWT-verified at execution time, not self-reported.
approval_timestamp2026-02-26T14:31:22ZExact time of the signed human decision — satisfies the requirement for a datable approval event in the change record.
sql_executedALTER DATABASE TEMPFILE ... RESIZE 10240MThe exact SQL command that ran — not a description, not a summary. Verbatim. The DBA approved exactly this.
llm_reasoning_summaryTEMP tablespace at 99.8%. 50 AP invoices blocked. Root cause confirmed via SYS-03. MOS Note 123456.1 applied.Documents the AI reasoning chain that led to the fix recommendation — enables post-incident review of the platform's decision path.
state_before{"tablespace":"TEMP","used_pct":99.8,"bytes_free":41943040}Captured system state immediately before execution — enables before/after comparison and supports rollback if needed.
state_after{"tablespace":"TEMP","used_pct":49.2,"bytes_free":5242880000}Captured system state immediately after execution — confirms the fix had the intended effect and documents the change boundary.
oracle_doc_referenceMOS Note 123456.1Cites the Oracle-validated knowledge source that supported the fix recommendation — links the internal decision to an authoritative external reference.
jwt_token_hashsha256:a3f9...Cryptographic proof that the approval signal was not replayed from a prior incident — satisfies integrity requirements for approval-gated change records.
Access Control

Separation of Duties

SOX and ITGC controls require that the person who requests a change cannot be the same person who approves and executes it. The platform enforces this architecturally.

Role: Submitter

End User / Functional Lead

Submits the incident via the support portal. Has no visibility into the diagnostic results, the LLM reasoning, or the proposed fix — only receives the resolution confirmation after the fix is applied and verified.

Role: Diagnostic Agent

Oracle AI Platform

Executes read-only diagnostic scripts via a restricted schema. Cannot write to the database through the diagnostic connection. Cannot approve its own fix recommendations. Cannot modify the proposed SQL before presenting it to the approver.

Role: Approver

Lead DBA / System Administrator

Reviews the Decision Tower evidence and approves or rejects the proposed fix. Cannot modify the diagnostic scripts, cannot influence the LLM reasoning output, and cannot execute fixes without the platform's approval workflow — no direct production database access outside the governed path.

Role: Auditor

Compliance / Internal Audit

Read-only access to the signed audit record store. Can query the complete history of every platform action, every approval decision, and every system state change — with the exact SQL executed and the JWT-verified approver identity for every High-Risk event.

Architectural enforcement: Separation of duties is not a policy document — it is implemented in the platform's access control layer. The diagnostic schema cannot write. The approval interface cannot execute without a JWT. The audit store is append-only. These constraints are architectural, not configurable by any single user.

Continue Exploring the Platform

Phase 01

System Architecture

The four-layer event-driven architecture that the governance framework operates within.
Phase 02

RAG Knowledge Base

How Oracle diagnostic outputs are chunked, embedded, and retrieved.
Phase 03

Oracle Support Integration

The Playwright browser agent and MOS knowledge retrieval workflow.
Start the Conversation → Read: SOX Compliance & AI Automation

Ready to talk about governed Oracle AI?

We're building this with Oracle teams who want full autonomous capability with zero compliance risk.

Get in Touch →