See the request move through Foundgine.
Every caller follows the same security-preserving lifecycle. The physical provider only appears after the semantic meaning and authorization decision are established.
The lifecycle
Think of Foundgine as a controlled sequence of boundaries rather than a collection of helpers:
Intent ↓ Semantic Operation Graph ↓ Validate + resource limits ↓ Authorize ↓ Authorized Graph + Evidence ↓ Semantic Plan + AuthorizationBinding ↓ Security-preserving rewrites ↓ ExecutionIR ↓ Provider Plan + Security Proof ↓ Final execution gate ↓ Execute → Result + Evidence
Retrieval can run alongside graph construction to discover candidates. It supplies evidence to resolution; it never grants authority.
What changes at each boundary
| Boundary | Responsibility | What it must not do |
|---|---|---|
| Caller → Intent | Express the requested operation. | Choose physical SQL or security context. |
| Semantic model → Graph | Give the request application meaning. | Depend on a particular provider. |
| Resolution → Authorization | Resolve the target, validate limits and decide authority. | Treat retrieval relevance as permission. |
| Plan → ExecutionIR | Carry the authorized semantics into executable structure. | Drop security provenance during optimization. |
| ExecutionIR → Provider | Compile/dispatch physical work and enforce conformance. | Redefine application authorization. |
Two useful mental models
For a read: intent becomes a semantic graph, is authorized, then becomes a provider-independent plan before SQL is produced.
For a mutation: the same boundary is stricter because dependency ordering, replay protection, approvals or execution-time revalidation may matter. See the high-assurance mutation evidence.
Where the detailed trace lives
The worked walkthrough shows the complete request with representative payloads. The Architecture page explains the layers and provenance binding. Security explains the invariants that every stage must preserve.