Skip to main content

Reporting & BI tool support

The goal is blunt: a customer's existing analysts keep their existing tools. A reporting or BI tool connects over a protocol it already speaks, and the read it performs passes through the same governed query plan as any other read, so adoption does not require retraining a BI team, and it does not open a second, unpoliced door to the data.

The policy is compiled into the query plan, not wrapped around the tool. The same row filters and column masks apply whether the caller is a BI tool or an agent running inside the cell. See governed reads and in-engine enforcement.

The surfaces a reporting tool connects over​

Figure: a reporting tool connects over a standard protocol; the query resolves through one governed plan and returns a filtered result carrying its classification and lineage. Ceiling: the Iceberg REST catalog is metadata-publishing (amber), it serves parsed metadata, not a live table load, so it is not a working bring-your-own-engine path.

Table equivalent

FromRelationshipToState (meaning)
Reporting / BI toolconnects overPostgreSQL wire (ODBC/JDBC)neutral
Reporting / BI toolconnects overGraphQLneutral
Reporting / BI toolconsumesDelta Sharing (server + client)verified (green)
Reporting / BI toolreads metadata fromIceberg REST catalog (metadata only)refusal / held (amber, dotted)
Any surfaceresolves throughOne governed query planverified (green)
Governed planreturnsFiltered result (classification + lineage carried)verified (green)

How to read the compatibility claims​

Each surface is a standard protocol the platform serves, so compatibility comes from the protocol rather than from a per-tool integration. A client that speaks the PostgreSQL wire, Arrow Flight SQL, Delta Sharing or GraphQL connects because those are what it already speaks.

  • PostgreSQL wire, the workhorse. A per-database credential resolves through a directory entity to real grants, so a Postgres client's login is a real identity with real permissions. Standard ODBC and JDBC drivers connect over this wire; there is no separate proprietary driver to install.
  • GraphQL and the other standard query surfaces give tools a second reach into the same governed engine.
  • Delta Sharing is a full protocol server and client, the strongest open-sharing path, with the security plane enforced on the served files. See open sharing.
  • Iceberg REST catalog, metadata publishing, not live load. It serves parsed catalog metadata and meters the call, but it does not perform a live table load. It publishes metadata for Iceberg-native tools; it is not a working bring-your-own-engine transport.
What "connects" does and does not mean here

One practical note for testing: a connector reporting healthy proves the handshake, not a live data transport, and the Iceberg REST catalog's success response is metadata rather than a table load. Validate either with a real query rather than a health check.

Native artifact generation and the governed outbound path​

Beyond a tool reading from the platform, the platform can generate native BI configuration, semantic models for tabular BI, dashboards, and best-practice analysis, and push it to a reporting tool. That outbound path is a governed chokepoint: a publish, refresh, or export is deny-by-default and fail-closed, must clear the net-potential-gain gate, and its egress is checked against the binding's destination before any byte leaves. It runs the same governance pipeline as any other outbound tool call. These surfaces appear under the catalog's Connections and Endpoints, not as a separate product.

Across the deployment matrix​

  • Single-cell: a tool connects to the cell over the wire; the read is governed on that cell.
  • Multi-cell: the same protocols reach any cell; federation gives a tool one view over a catalog that spans cells.
  • Sovereign / air-gapped: the protocol servers run on the cell with no vendor control plane in the path; a tool on the same isolated network connects normally.
  • Cloud-enabled: the same protocols reach cloud-hosted tools.