Skip to main content
Sometimes the governed REST API genuinely can’t answer, and SQL could. If — and only if — SQL is enabled on the connection, chat stops and asks first:
“The governed API can’t answer <X>. OK to query the database directly? (Bypasses per-user data security; I’ll label anything it finds.)”
Say yes and the answer is labelled “via SQL (user-approved)” — or “via SQL (standing consent)” if you’ve granted standing consent on that connection. On a Production connection it always re-asks.
The ask exists because REST answers respect each user’s Oracle data security and SQL does not. It keeps a human in the loop the moment ORCA is about to step outside your security posture, and the label keeps that visible in the answer forever. Consent removes the question, never the visibility.
Why did ORCA ask permission before answering? Because it needed to fall back to direct SQL, which bypasses Oracle’s per-user data security. ORCA always asks first and labels the result “via SQL”. If it never asked, it answered entirely through the governed REST API — within your own Oracle security.

​
How ORCA earns autonomy

Each task earns autonomy as it proves accurate, and auto-downgrades if error rates spike or you override it. It’s a safety-first ratchet that runs under the hood per (entity, field) — there’s no dashboard to watch; you feel it as ORCA asking fewer questions each cycle.
LevelBehaviour
L0 · ManualYou decide everything.
L1 · GuidedORCA proposes, you confirm.
L2 · SupervisedORCA applies, you spot-check.
L3 · AutonomousORCA applies with no model call.
L4 · Lights-OutFully autonomous, no overrides.