This is the execution roadmap for proving the Foundgine thesis. It intentionally prioritizes one complete vertical slice over broad feature coverage.
Goal: prove the existing lower half works.
Domain
→ Metadata
→ Dynamic Planner
→ QueryPlan
→ ProviderPlan
→ SQL
→ real database
→ Result
ExecutionRow.Status: active proof exists in samples/Foundgine.Samples.Banking.
Goal: turn metadata into a semantic application model.
Add descriptors for:
Entity
Identity
Field
Relationship
Search capability
Action
Policy
The semantic model must be protocol-neutral.
Given the Banking domain, Foundgine can enumerate:
Customer
├── identity: Id
├── fields: Name
├── relationship: Accounts
└── actions: <none initially>
Account
├── identity: Id
├── fields: Balance
└── relationship: Transactions
Transaction
├── identity: Id
└── fields: Amount
Important: start with hand-authored metadata if necessary. Do not block the product proof on a source generator.
Goal: map ambiguous human language to domain identities.
Examples:
"Ada Lovelace"
"account 10"
"her checking account"
"the last transaction"
into explicit domain references.
The resolver returns:
The resolver must never silently invent an identity.
Goal: prove natural-language-to-read-plan without building a generic AI framework.
Natural language
↓
Intent
↓
Resolve
↓
Semantic query
↓
Foundgine QueryPlan
↓
ProviderPlan
↓
Database
↓
Evidence
The LLM is an optional reasoning client. Foundgine owns the constrained semantic representation and execution.
Find Ada’s last five transactions.
Expected plan:
Resolve Customer
→ Resolve Account through Customer relationship
→ Query Transaction ordered by transaction identity/time
→ Limit 5
Goal: expose explicit business operations rather than arbitrary method invocation.
Example:
IssueRefund(amount)
SuspendAccount(reason)
ChangeTier(tier)
Each action gets a descriptor:
Name
Target entity
Inputs
Mutating?
Authorization requirements
Side effects
Verification requirements
An agent can select only actions exposed by the semantic model.
It cannot invent arbitrary C# method calls.
Goal: authorization becomes part of planning.
Intent
↓
Resolve
↓
Policy
↓
Plan
Example:
IssueRefund
requires:
Refund permission
Customer ownership
amount <= configured limit
Denied plans should be explicit and explainable.
Goal: mutations are inspectable before execution.
PLAN
↓
PREVIEW
↓
APPROVE
↓
EXECUTE
A preview should identify:
This is a core safety mechanism, not a UI feature.
Goal: every important execution can prove what happened.
Execute
↓
Re-read affected state
↓
Verify expected result
↓
Produce evidence
Evidence should capture enough information to explain:
What was resolved?
Why was it selected?
What policy was applied?
What plan ran?
What provider executed?
What changed?
How was the result verified?
Goal: expose the proven semantic API to external agents.
MCP is an adapter, not Foundgine’s core.
Claude / ChatGPT / Cursor
↓
MCP
↓
Foundgine Semantic API
↓
Foundgine Runtime
Start with a minimal tool surface:
discover
resolve
query / plan
preview
execute
verify / evidence
Do not create dozens of entity-specific MCP tools.
Only after the first vertical slice works:
Structured data
Domain actions
Semantic retrieval
External data
These are execution targets behind a common planning model.
Do not build all four at once.
Only after the semantic model and runtime are proven should Roslyn generation become a major focus.
The compiler should generate:
It should not generate a fixed planner for future natural-language requests.
Dynamic intent remains a runtime concern.
The first convincing Foundgine demo is one test that can execute:
"Find Ada's checking account."
↓
resolve Customer
↓
resolve Account
↓
policy check
↓
plan
↓
execute
↓
evidence
and:
"Refund Ada's last transaction."
↓
resolve Customer
↓
resolve Transaction
↓
authorize IssueRefund
↓
build mutation plan
↓
preview
↓
approve
↓
execute
↓
verify
↓
evidence
If these work against a real database and real domain action, the thesis has been proven.
Everything else is expansion.