---
license: apache-2.0
language:
- en
library_name: transformers
pipeline_tag: text-generation
tags:
- text-to-sql
- postgresql
- code-generation
base_model: Interchained/imagine-v10
---
# ๐ง imagine-v11
### 100% on held-out. Predicate placement fixed. Analytical SQL, finally real.
**Natural language in. Correct PostgreSQL out. ~1B parameters. No GPU. No API key. No metered inference.**
[](#evaluation)
[](#execution-gate)
[](#evaluation)
[](#evaluation)
[](#local-first)
[](#status)
*Part of project `imagine` โ Interchained*
---
## The failure that built v11
v10 was asked, live:
> "Every customer with total spending on completed orders, include zeros."
It returned:
```sql
SELECT c.id, c.name, COALESCE(SUM(o.total), 0) AS total_spending
FROM customers c
LEFT JOIN orders o ON c.id = o.customer_id
WHERE o.status = 'completed' -- โ the bug. WHERE runs AFTER the join.
GROUP BY c.id, c.name
ORDER BY total_spending DESC;
```
The `WHERE` silently converts the outer join to an inner join. Every zero-spend customer โ the exact rows the question asked for โ vanishes. The predicate belongs in `ON`:
```sql
SELECT c.id, c.name, COALESCE(SUM(o.total), 0) AS total_spending
FROM customers c
LEFT JOIN orders o ON c.id = o.customer_id AND o.status = 'completed'
GROUP BY c.id, c.name
ORDER BY total_spending DESC, c.id ASC;
```
v10 knew the shape of the answer but not where the filter lives. **v11 does.**
---
## ๐ฏ What v11 adds
Where v10 added complex analytical queries, v11 adds **predicate placement** โ knowing *where* each clause belongs:
- **ON-clause predicates** โ filters on the nullable side of an outer join live in `ON`, never `WHERE`
- **Conditional aggregation** โ `SUM(CASE WHEN ...)` patterns for filtered totals
- **Anti-join patterns** โ `NOT EXISTS` / `LEFT JOIN ... IS NULL` for absence queries
- **Analytical templates, actually working** โ v10's analytical set silently generated zero candidates (a child-detection heuristic that never matched plural table names); v11 fixes the generator and ships 18 real analytical pairs
---
## ๐ The numbers
| Model | Held-out (telemetry) | Protocol | Execute rate | Invented cols |
|---|---|---|---|---|
| imagine-v8 | 50.0% (20/40) | 100% | โ | โ |
| imagine-v9 | 90.0% (36/40) | 100% | 97.5% | 0 |
| imagine-v10 | 100.0% (40/40) | 100% | 100% | 0 |
| **imagine-v11** | **100.0% (40/40)** | **100%** | **100%** | **0** |
**Perfect score, held.** Zero wrong answers. Zero hallucinations. Zero refusals.
---
## ๐งฌ How v11 was built
Two-stage fine-tuning from `Interchained/imagine-v10`, on an NVIDIA B200:
### Stage 1 โ Full fine-tune (smoke)
- **Corpus:** 3,284 admitted pairs (99.85% gate admit rate)
- **New:** Predicate-placement templates (ON-clause, conditional aggregation, anti-join) + working analytical templates
- **Epochs:** 3, LR 1e-5, cosine schedule
- **Final loss:** 0.0007 (v10 was 0.0052 โ **7x better**)
- **Time:** 3.3 min on B200, 33k tok/s
### Stage 2 โ LoRA refinement
- **Base:** v11-smoke checkpoint
- **Rank:** 16, LR 5e-6
- **Epochs:** 3
- **Final loss:** 0.0000
- **Time:** 4.2 min on B200
- Adapter folded into full checkpoint
### The corpus
3,289 candidates forged, 3,284 admitted:
| Schema | Templates | Analytical | Predicate | Writes | Total |
|---|---|---|---|---|---|
| shop | 356 | 3 | 9 | 396 | 764 |
| clinic | 545 | 6 | 36 | 280 | 867 |
| library | 481 | 6 | 0 | 262 | 749 |
| fleet | 297 | 3 | 0 | 231 | 531 |
| audit | 252 | 0 | 0 | 126 | 378 |
**Nothing enters training that a live database hasn't agreed with.**
---
## ๐ฌ The execution gate
Every candidate goes through L0โL4:
```
candidate SQL โโโบ L0 real PostgreSQL parser not a regex
L1 read-only + bounded no writes, no sleeps
L2 EXPLAIN on live schema hallucinations die HERE
L3 execute, timed, capped real rows
L4 SAME ANSWER as ref? โโโ the one that matters
โผ
admitted to corpus
```
68/68 gate tests passing. The gate is the truth authority โ not a bigger model, not vibes.
---
## ๐ฆ Output protocol
SQL wrapped in sentinel blocks:
```
<<>>
SELECT c.id, c.name, COALESCE(SUM(o.total), 0) AS total_spending
FROM customers c
LEFT JOIN orders o ON c.id = o.customer_id AND o.status = 'completed'
GROUP BY c.id, c.name
ORDER BY total_spending DESC, c.id ASC;
<<>>
```
Can also refuse:
| block | meaning |
|---|---|
| `<<>>` | here is your query |
| `<<>>` | this schema cannot answer that |
| `<<>>` | ambiguous โ here's what's missing |
> โ ๏ธ **A truncated generation is not an answer.** An unterminated block extracts to **nothing**.
---
## ๐ป Loading v11
```python
from transformers import AutoModelForCausalLM, AutoTokenizer
import torch
model_id = "Interchained/imagine-v11"
tokenizer = AutoTokenizer.from_pretrained(model_id)
model = AutoModelForCausalLM.from_pretrained(
model_id,
torch_dtype=torch.bfloat16,
device_map="auto",
)
# Ask for a predicate-placement query โ v10's failure mode
prompt = """Schema:
customers(id, name)
orders(id, customer_id, total, status)
List every customer ID, name, and total completed spending.
Include customers with no completed orders (show 0).
Sort by spending descending, then ID ascending."""
inputs = tokenizer(prompt, return_tensors="pt").to(model.device)
with torch.no_grad():
output = model.generate(inputs["input_ids"], max_new_tokens=256, do_sample=False)
print(tokenizer.decode(output[0], skip_special_tokens=True))
```
---
## ๐ฏ Identity
The deployed model identity is **Imagine**.
Built and fine-tuned by **Interchained**.
DeepSeek-Coder is part of the upstream lineage (via v8 โ v9 โ v10 โ v11), but the deployed identity is Imagine.
---
## โก Local-first
Runs on your hardware. No API key. No metered inference. No cloud dependency.
---
## ๐ The rules
**1 ยท Don't write a verifier โ the engine already shipped one.**
Real parser. Real planner. Real rows.
**2 ยท Assert the property, not a proxy.**
Execution accuracy, not string similarity.
**3 ยท Schema goes in the prompt, not in the weights.**
The model learns *"read the schema you were handed"* โ not memorise ours.
---
## โ ๏ธ Limitations
v11 is a research checkpoint. It may still:
- generate incorrect SQL on novel patterns
- misunderstand ambiguous requests
- produce writes with wrong `WHERE` clauses โ **always review before executing**
Generated SQL should be reviewed before use in production. This applies doubly to writes.
---
## ๐ Security
Do not rely on model behavior alone for database safety. Production systems should enforce:
- least-privilege database roles
- statement timeouts and row limits
- query validation and schema restrictions
- application-level authorization
- audit logging
- **human approval for all write statements**
---
**Built by [Interchained](https://github.com/aiassistsecure/sukuna-imagine)** ยท ownership at every layer, including the model
`3 > 1` โ Mark drives, oracle points, Muse builds