Follow one sentence all the way to a result.

Untrusted caller → Foundgine

Foundgine treats the agent exactly like an API client or a GraphQL client: an untrusted caller. Nothing about the sentence is trusted yet — not the words, not the implied filters, not the fact that it came from an internal tool.

{
  "caller": "ai-agent",
  "channel": "mcp",
  "actor": { "id": "agent-42", "tenantId": "tenant-7" },
  "message": "Show me overdue purchase orders from
              our top supplier in Texas, and how many
              days late each one is."
}

{
  "status": "received",
  "next": "capability discovery (advisory)"
}

Sentence → Structured intent

The agent calls foundgine_capabilities to see what it may ask for — that description is advisory, never a credential (see AI agents). It then emits structured intent. Two words in the sentence stay unresolved on purpose: "top supplier" and "overdue" are recorded as language, not as IDs or booleans, because the model does not get to decide what those mean.

{
  "capabilities": ["purchaseOrder.query", "supplier.query"]
}

{
  "operation": "query",
  "resource": "purchaseOrder",
  "select": ["id", "expectedDate", "receivedDate"],
  "where": { "status": "overdue" },
  "supplierRank": { "state": "TX", "rank": "top" }
}

Structured intent → Semantic Model (Foundgine.Semantics)

purchaseOrder, supplier and the Supplier relationship are looked up against the application-defined semantic model, not against database tables. "overdue" is resolved here too: the model defines it as a named predicate, not something the caller can redefine.

{
  "resource": "purchaseOrder",
  "relation": "supplier",
  "namedPredicate": "overdue"
}

{
  "resolvedModel": {
    "root": "PurchaseOrder",
    "relationship": "PurchaseOrder.Supplier",
    "predicate": "PurchaseOrder.IsOverdue",
    "fields": ["PurchaseOrder.Id",
               "PurchaseOrder.ExpectedDate",
               "PurchaseOrder.ReceivedDate"]
  }
}

Semantic Model → Semantic Operation Graph

Foundgine builds one graph for the whole request. Because "top supplier" cannot be resolved from the semantic model alone, the graph carries an explicit candidate node that must be settled by retrieval before the rest of the graph can be authorized or planned.

{
  "resolvedModel": { "root": "PurchaseOrder" },
  "supplierRank": { "state": "TX", "rank": "top" }
}

{
  "graph": {
    "candidateNode": "Supplier(state=TX, rank=top:1)",
    "scanNode": "PurchaseOrder(supplierId=$candidate)",
    "filterNode": "PurchaseOrder.IsOverdue"
  }
}

Candidate node → Ranked candidates + evidence

A Foundgine.Sql retrieval strategy (relational lookup, ranked by total order value) resolves the candidate node to a real supplier. This step only produces candidates and evidence. It cannot grant access to anything — the result still has to pass through resolution and authorization below.

{
  "strategy": "relational",
  "filter": { "state": "TX" },
  "orderBy": "totalOrderValue desc",
  "limit": 1
}

{
  "candidates": [
    { "id": "sup-118", "name": "Lonestar Components",
      "totalOrderValue": 482000 }
  ],
  "evidence": { "strategy": "relational", "rank": 1 }
}

Candidates + Semantic Operation Graph → Resolved, valid request

The candidate supplier is bound into the graph, and Foundgine validates that every field, relationship and predicate the request touches is real, typed and traversable. If "top supplier" had matched nothing, or matched ambiguously, resolution would stop here and tell the agent its own words were ambiguous — it would not guess (see Grounding decisions).

{
  "candidateSupplierId": "sup-118",
  "requestedFields": ["PurchaseOrder.Id",
                       "PurchaseOrder.ExpectedDate",
                       "PurchaseOrder.ReceivedDate"]
}

{
  "valid": true,
  "boundSupplierId": "sup-118",
  "dependencies": ["PurchaseOrder", "Supplier"]
}

Resolved request → Authorized request + evidence

This is where "is this caller allowed to do this" gets answered — once, centrally, regardless of which tool or transport the agent used. Here it constrains the request to the caller's tenant and strips a field the requester's role cannot see.

{
  "subject": { "id": "agent-42", "tenantId": "tenant-7",
               "role": "purchasing-viewer" },
  "requested": { "resource": "PurchaseOrder",
                 "fields": ["Id", "ExpectedDate",
                            "ReceivedDate",
                            "Supplier.NegotiatedCost"] }
}

{
  "decision": "allow",
  "deniedFields": ["Supplier.NegotiatedCost"],
  "constraints": [
    { "field": "PurchaseOrder.TenantId",
      "operator": "eq", "value": "tenant-7" }
  ]
}

Authorized graph → Provider-independent plan + AuthorizationBinding

Foundgine turns the authorized graph into a logical plan that still knows nothing about PostgreSQL. Critically, the plan carries an AuthorizationBinding — a fingerprint of the step 7 decision. Any later optimization can change the plan's shape, but it cannot change what was authorized.

{
  "scan": "PurchaseOrder",
  "join": { "to": "Supplier", "id": "sup-118" },
  "filters": ["PurchaseOrder.IsOverdue",
              "PurchaseOrder.TenantId = tenant-7"],
  "projection": ["Id", "ExpectedDate", "ReceivedDate"]
}

{
  "plan": { "scan": "PurchaseOrder",
            "supplierId": "sup-118",
            "projection": ["Id", "ExpectedDate",
                            "ReceivedDate"] },
  "authorizationBinding": {
    "fingerprint": "auth:9f21c...",
    "deniedFields": ["Supplier.NegotiatedCost"]
  }
}

Bound plan → ExecutionIR

Foundgine.Execution lowers the plan into ExecutionIR: an explicit, inspectable operator tree that still carries the authorization binding forward. This is the last representation before any provider-specific syntax appears.

{
  "plan": "PurchaseOrder scan + supplier=sup-118
           + tenant filter + IsOverdue",
  "authorizationBinding": "auth:9f21c..."
}

{
  "ir": {
    "op": "Scan", "entity": "PurchaseOrder",
    "filters": ["SupplierId = sup-118",
                "TenantId = tenant-7", "IsOverdue"],
    "project": ["Id", "ExpectedDate", "ReceivedDate"],
    "authorizationBinding": "auth:9f21c..."
  }
}

ExecutionIR → Provider plan + security proof

Foundgine.Sql compiles the ExecutionIR into a parameterized command. Before anything runs, the final execution gate checks that the compiled plan's fingerprint still matches the AuthorizationBinding from step 8 — if authority changed in between, execution fails closed instead of running a stale decision.

{
  "provider": "PostgreSQL",
  "ir": { "entity": "PurchaseOrder",
          "authorizationBinding": "auth:9f21c..." }
}

{
  "command": { "kind": "parameterized SQL",
    "parameters": { "supplier_0": "sup-118",
                     "tenant_0": "tenant-7" } },
  "securityProof": { "fingerprintMatches": true,
                      "gate": "passed" }
}

Provider plan → PostgreSQL → rows

The provider executes the parameterized command. The agent never held database credentials, never wrote SQL, and never saw a raw connection string — the only thing that crossed the boundary was the authorized, security-proofed command from step 10.

{
  "parameters": { "supplier_0": "sup-118",
                   "tenant_0": "tenant-7" }
}

{
  "rows": [
    { "id": "po-7734", "expectedDate": "2026-08-12",
      "receivedDate": null },
    { "id": "po-7791", "expectedDate": "2026-08-20",
      "receivedDate": null }
  ]
}

Rows → Caller, with evidence

The rows are shaped back into the answer (days-late computed from expectedDate), and returned together with execution evidence: what was authorized, which fields were denied, which provider ran it, and how many rows came back. The agent can now answer in plain language — but everything it says is traceable back to one authorization decision.

{
  "rows": 2, "authorization": "allow"
}

{
  "data": [
    { "id": "po-7734", "daysLate": 19 },
    { "id": "po-7791", "daysLate": 11 }
  ],
  "evidence": { "authorized": true,
    "supplier": "Lonestar Components (sup-118)",
    "deniedFields": ["Supplier.NegotiatedCost"],
    "provider": "PostgreSQL", "rowCount": 2 }
}