A quick cut of the questions we hear from security, platform, and app teams when they first look at AIGQLUnify. Think of this as the “pre-RFI” sheet: enough detail to see if we fit your architecture, without an eighty-page PDF.
AIGQLUnify uses an explicit mapping layer between the REST responses and the GraphQL contract. You can rename fields
(cust_id → customerId), reshape nested objects, and normalize pagination into a single, clean pattern
without touching the backend. The “ugly” JSON stays at the edge; consumers see a stable graph.
In the reference docker-compose, a full CP → DP → PDP → DSAR flow for typical queries stays in the low-milliseconds per hop. PDP evaluation runs in-process with cached policies, and tracing/metrics use asynchronous exporters so spans are batched off the hot path. For high-throughput workloads you scale DPs horizontally and pin PDP close to them to keep tail latency predictable.
All three—on purpose. The Control Plane ingests OpenAPI, manages tenants, workspaces, and policies. The Data Plane is the GraphQL runtime that calls your REST services and enforces PDP decisions. Deployed together, they behave like a governed gateway with federation-ready SDL output.
Yes. CP and DP are built to run as separate services. Many teams host CP in a more controlled “platform” VPC and deploy DPs closer to apps or regions, while still keeping a single source of truth for SDL, policy, and DSAR.
Yes. AIGQLUnify can emit Apollo-compatible subgraphs from your OpenAPI specs. You can start with a single, unified graph, then split into subgraphs later without re-implementing your joins or policies.
AIGQLUnify usually sits behind your edge gateway. The edge handles TLS termination and coarse routing; AIGQLUnify handles fine-grained joins, PDP/PEP, DSAR, and telemetry on the inside.
No. AIGQLUnify plugs into your existing IdPs (OIDC/SAML) and reads claims/roles/scopes from the tokens you already issue. You express ABAC rules in the PDP; the DP enforces them at field level.
Policies can mark fields as mask, drop, or allow. At runtime, the DP
applies these decisions per resolver and stamps the outcome into OTEL spans
(apigql.pdp.allow, apigql.pdp.mask, etc.).
DSAR flows live in the Control Plane: create, track, fulfill. Each request has an immutable audit
trail and, for exports, a downloadable artifact (for example, export.zip) you can return to the subject.
Yes. Every DP call includes planId, sdlEtag, and policyEtag in traces, so you can
reconstruct exactly which SDL and policy version produced a response.
Always downstream of PDP/PEP. AIGQLUnify first enforces policy (including masking and DSAR obligations), then hands the sanitized response to AI helpers for summarization, clustering, or explanation.
No, unless your policies explicitly allow it. AI helpers see the same shaped data your clients see, and we stamp which redactions were applied into the trace for audit.
AIGQLUnify emits OpenTelemetry traces with spans for GraphQL operations, REST calls, PDP decisions,
and DSAR actions. You can search Jaeger by tags like apigql.pdp.allow or apigql.dsar.action.
You configure OTLP/OTEL exporters to point at your preferred backends (Jaeger, Tempo, Honeycomb, etc.). AIGQLUnify doesn’t dictate your observability stack; it just makes sure the right signals are emitted.
No. The control plane emits standard artifacts — GraphQL SDL, resolver stubs, and policy bundles. You can export these and run them on your own Apollo routers or custom graph runtimes if you ever decide to move off the platform. AIGQLUnify is designed as an opinionated accelerator, not a proprietary protocol.
Yes. Many customers begin with a single regulated use case (for example, “orders with PII”) and then grow into more tenants and workspaces as they get comfortable with PDP and DSAR flows.
Backends don’t need to change. You register their OpenAPI specs, wire auth and PDP, and route a slice of traffic through AIGQLUnify. From there you can gradually expand coverage while your existing gateway and services stay put.
Yes. CP/DP can be deployed into your cloud accounts, on-prem clusters, or a mix (for example, CP in cloud, DPs close to on-prem systems) so data stays where it belongs.
Point us at two or three heterogeneous REST services (different auth, different data), and we’ll federate them into a single graph with PDP, DSAR, and OTEL wiring. That usually reveals the value in a few hours.