Secure and audit-ready,
by design
QueryWell is built for the people who have to answer to auditors and regulators. Studio results stay on the device, secrets stay in the OS keychain, every run and export leaves a tamper-evident trail — and the page below says exactly where each kind of data goes.
No QueryWell reporting cloud
Studio results, history and exports remain on the device. QueryWell has no hosted reporting warehouse or cloud sync, and Elaman does not receive your query output.
Secrets in the OS keychain
Credentials live in OS-native secret storage — never in plaintext and never in the app's local database. QueryWell currently runs BI Publisher reports using an approved username/password reporting account over HTTPS; OAuth sign-in does not currently enable report execution. A green connection test means a real, executable login — 401 and 403 fail loudly.
Read the Oracle Fusion API authentication guide for connection requirements and the roles of basic authentication and OAuth.
Reporting-only by default
Destructive operations are blocked in code, with no setting to re-enable them. Reports run as the reporting account you supply, so what BI Publisher returns is bounded by that account's Fusion roles and data-security policies — QueryWell adds no access of its own. It reaches Fusion through Oracle's supported reporting APIs only: no JDBC, SQL*Net or backend SQL to the pod. (The Data Loader's target is your own database, which you administer.)
Residency follows your destinations
There is no QueryWell warehouse and no vendor cloud copy. Where report data lives is a property of the destinations you configure — your device, your target database, your model provider — which is what makes rules such as Bank of Ghana CISD-2026 tractable. QueryWell does not certify compliance with any regulation; it keeps the data paths short enough for you to evidence them.
Masked audit logs
Every run and export is logged. Sensitive parameter names — token, key, IBAN, account and the like — are masked in the log automatically.
Tamper-evident exports
Every export is SHA-256 hashed and recorded in the export log — evidence you can hand straight to auditors and examiners.
Security & governance at a glance
- Reporting-only by default — destructive operations blocked
- Runs as the reporting account you supply — bounded by that account's Fusion roles and data-security policies
- OS-native secret storage; no secrets in the local database
- Sensitive parameters (token, key, IBAN, account…) masked in logs
- Content Security Policy enforced in production builds
- No product telemetry or cloud sync; update checks send limited version, platform, licence and random-install identifiers
- Reaches Fusion through Oracle's supported reporting APIs only — no JDBC / SQL*Net / backend SQL to the pod; a username/password reporting account over HTTPS runs reports today
- Cryptographically signed updates; signed & notarised macOS build and verified-publisher Windows installer
Where your data goes — the three paths
QueryWell stores connection metadata, history, audit logs and saved queries in local SQLite on your device. Report data itself travels one of three paths, each of which you choose and can evidence:
- Studio — reports run over Oracle's supported BI Publisher surface; results, history and exports stay on the device. They are never copied to a vendor cloud or warehouse.
- Data Loader — mirrored tables are written to the Oracle Autonomous Database target you configured, under your access controls; governance policy and the audit ledger live in your pod's BI Catalog.
- AI Workbench — prompts, schema metadata and tool results go directly to the model provider you configure, on your own account. Elaman does not proxy or retain them.
Volume is governed, not refused. Sustained extracts don't run through the interactive worksheet — they run through the Data Loader, which paces itself against a pod request budget, writes only what the policy registry allows, and records every load in the audit ledger. Large data movement stays inside the same control boundary as everything else.
Data Loader — governed by design
When you mirror Fusion tables, the copy lands in your Oracle Autonomous Database — not ours. Every load is subject to a governance registry stored in your own BI Catalog, and written to an audit ledger you can export.
Data Loader governance controls
- Open or restricted modes — allow all targets, or only approved ones
- Per-table row caps and deny lists
- Single-copy-per-table enforcement to prevent stray duplicates
- A pod-stored audit ledger of every write, with per-user folders
- Local CSV export of the ledger for offline audit
- LOB/RAW/XMLTYPE columns excluded with explicit warnings
Reporting your auditors will trust
Own it outright, keep your data in-country, and hand over tamper-evident evidence on demand.