Home → Documentation → Architecture → Request Pipeline
The target Foundgine pipeline separates compiled application knowledge from dynamic runtime intent.
C# domain
↓
semantic descriptors
The descriptors identify what the application can expose.
An external agent or application produces an intent such as:
Find Ada's last five transactions.
Foundgine does not need to own the LLM that produced the intent.
Ada
↓
Customer #1
↓
Account #10
↓
Transactions
Resolution should record why each identity was selected.
Before an action or protected query proceeds:
Intent
↓
Resolved targets
↓
Policy evaluation
A denial is a valid execution result.
The planner converts the resolved intent into explicit execution structures:
QueryIntent
↓
QueryPlan
↓
ProviderPlan
For mutations:
ActionIntent
↓
MutationPlan
Mutating plans should be renderable before execution:
Target
Action
Inputs
Policy result
Expected effects
Verification strategy
Providers execute the approved plan.
The provider boundary is represented by Foundgine.Execution.Contracts.
After a mutation, Foundgine should re-read or otherwise validate the affected state.
Verification is part of the product contract, not merely a test concern.
The result should contain an evidence chain sufficient to answer:
Who/what was selected?
Why?
What policy was applied?
What plan ran?
What actually happened?
How was it verified?
The external AI system can turn the evidence into a natural-language response.
Foundgine does not need to generate the prose itself.
The Banking sample currently proves:
Metadata
→ Dynamic Planner
→ QueryPlan
→ ProviderPlan
→ SQL
→ real SQLite
→ Result
Steps involving natural-language intent, policy, actions, preview, verification and evidence are roadmap work.
The AI decides what it wants; Foundgine decides what the application permits and how that intent can execute.