Hugging Face's logo

Interchained
/
imagine-v12

Text Generation
Safetensors
GGUF
English
llama
sql
nl2sql
code-generation
fine-tuning
local-first
postgresql
conversational
Model card Files
xet
 Community
imagine-v12 / README.md
Interchained's picture
Interchained
Update README.md
efa79da verified
preview code
|
Raw History Blame Contribute Delete
14.1 kB
---
license: apache-2.0
language:
- en
tags:
- text-generation
- sql
- nl2sql
- code-generation
- fine-tuning
- local-first
- gguf
- postgresql
base_model: Interchained/imagine-v11
---
# IMAGINE v12
### Identity is learned. SQL is verified. Intelligence runs locally.
**131,400 training examples. ~1 billion parameters. 40/40 held-out executions. One identity: Imagine.**
Built by **Interchained**.
> **Natural language in. PostgreSQL out. No hosted API required. No inference subscription. No dependency on a larger model at runtime.**
Imagine v12 is a specialized, locally deployable language model for schema-grounded SQL generation, disciplined output protocols, and native model identity.
It doesn't need a system prompt to be told its name.
It doesn't need an external LLM to formulate SQL.
And it doesn't need a cloud service to run.
**It is Imagine.**
---
## 01 / THE BREAKTHROUGH
### v11 mastered the benchmark. v12 learned who it is.
Earlier releases focused on teaching a compact coding model how to interpret database schemas, construct SQL, and follow a machine-readable output protocol.
v12 introduces something different: **identity as a trained behavior, not merely a deployment instruction.**
Ask Imagine who built it, and it identifies Interchained.
Ask about its lineage, and it distinguishes its upstream DeepSeek-Coder foundation from its deployed identity.
Challenge that identity, and it has been trained to resist false attribution.
Meanwhile, the existing SQL curriculum was retained.
**The result: a model with a consistent identity and unchanged measured success on the 40-query held-out evaluation.**
Not a bigger model.
Not an extra inference layer.
A better-trained one.
---
## 02 / THE SCOREBOARD
### Five generations. One measurable trajectory.
| Release | Execution accuracy | Protocol | Execute rate | Invented columns |
|---|---:|---:|---:|---:|
| Imagine v8 | 50.0% · 20/40 | 100% | — | — |
| Imagine v9 | 90.0% · 36/40 | 100% | 97.5% | 0 |
| Imagine v10 | 100% · 40/40 | 100% | 100% | 0 |
| Imagine v11 | 100% · 40/40 | 100% | 100% | 0 |
| **IMAGINE v12** | **100% · 40/40** | **100%** | **100%** | **0** |
### 40 / 40
**Perfect execution accuracy on the specified held-out telemetry evaluation.**
- Zero incorrect answers in the evaluated set.
- Zero invented columns in the evaluated set.
- Zero failed executions in the evaluated set.
- Full protocol compliance.
- Identity behavior verified in prompted and unprompted testing.
- INSERT, UPDATE, and DELETE sentinel behavior separately verified.
**Evaluation conditions:** October 12, 2026. Held-out telemetry workload, 40 queries, regenerated with seed 99. Q4_K_M GGUF served through llama.cpp.
These results describe a specific evaluation, not a universal accuracy guarantee. Novel schemas, unseen workloads, and production deployments require independent testing.
**The achievement isn't that Imagine can produce plausible SQL. It's that its answers were actually executed and checked.**
---
## 03 / TRAINING INTELLIGENCE, NOT GUESSWORK
### 131,400 examples. Three behavioral disciplines.
| Discipline | Examples | Allocation |
|---|---:|---:|
| **IDENTITY** | 43,362 | 33% |
| **PROTOCOL** | 26,280 | 20% |
| **SQL REASONING** | 61,758 | 47% |
| **TOTAL** | **131,400** | **100%** |
**Identity training** teaches Imagine its name, builder, upstream lineage, capabilities, and boundaries. It also includes responses to misleading identity claims.
**Protocol training** establishes a predictable interface between natural language, structured SQL output, clarification, and unanswerable requests.
**SQL training** retains the v11 curriculum, emphasizing schema grounding and execution-verified correctness.
This isn't simply more instruction data.
**It's a deliberately composed behavioral architecture.**
The model learns what it is, how it communicates, and how to work within the schema it is actually given.
---
## 04 / THE FORGE
### Every admitted SQL candidate must survive reality.
Imagine's SQL training pipeline uses an execution gate backed by a real database environment.
```text
NATURAL LANGUAGE + SCHEMA
│
▼
CANDIDATE SQL
│
▼
L0 ─ PostgreSQL parser
Is this valid SQL?
│
L1 ─ Safety constraints
Read-only and bounded?
│
L2 ─ EXPLAIN
Does the live schema support it?
│
L3 ─ Execution
Can it run under enforced limits?
│
L4 ─ Reference comparison
Does it return the correct answer?
│
▼
ADMIT / REJECT
│
▼
VERIFIED SQL CORPUS
```
**3,289 candidates generated.**
**3,284 admitted.**
**99.85% admission rate.**
**68/68 gate behavior tests passing.**
The gate doesn't reward SQL that merely looks right.
It tests SQL against an actual database, including result comparison with the expected answer.
The L0–L4 candidate-admission path is read-only. Write-statement generation is evaluated separately and requires additional execution safeguards.
> **Our philosophy: Don't ask a bigger model whether the SQL is correct when the database itself can establish the answer.**
Verification is part of the training pipeline, not an optional decoration.
---
## 05 / BUILT ON A B200. DEPLOYED WITHOUT ONE.
### Two stages. One refined checkpoint.
**Stage I — Full-parameter fine-tuning**
Training began from `Interchained/imagine-v11` on an NVIDIA B200.
The full 131,400-example corpus was loaded with its intended identity, protocol, and SQL distribution.
The original three-epoch run encountered a storage failure at step 3,600 of 5,664 after repeated full-model checkpoints consumed the available disk.
The step-3,500 checkpoint was recovered and verified loadable.
Older checkpoints were cleared, training resumed, and the recovered run completed an additional epoch.
**Recovered training results:**
- Final loss: **0.0107**
- Epoch mean loss: **0.0136**
- Resumed-leg duration: **22.5 minutes**
- Throughput: **approximately 39,000 tokens/sec**
**Stage II — LoRA refinement**
A second optimization stage refined the stage-I model using a low-rank adapter.
- Rank: **16**
- Learning rate: **5 × 10⁻⁶**
- Schedule: **cosine**
- Completed epochs: **1 of 3**
- Epoch mean loss: **0.0131**
The refinement run was intentionally stopped after its first epoch to conserve compute. The adapter was subsequently merged into the full checkpoint.
No fictional clean-room training story. No hidden failure.
**The process included a real infrastructure failure, checkpoint recovery, and a deliberate compute trade-off.**
Engineering is what survives the unexpected.
---
## 06 / A PROTOCOL MACHINES CAN TRUST
### Predictable boundaries. Explicit outcomes.
Imagine supports structured sentinel blocks rather than requiring downstream applications to infer where generated SQL begins and ends.
**Successful SQL generation**
```sql
<<<SQL>>>
SELECT
c.id,
c.name,
COALESCE(SUM(o.total), 0) AS total_spending
FROM customers AS c
LEFT JOIN orders AS o
ON o.customer_id = c.id
AND o.status = 'completed'
GROUP BY c.id, c.name
ORDER BY total_spending DESC, c.id ASC;
<<<END>>>
```
**Cannot answer from the schema**
```text
<<<UNANSWERABLE>>>
The available schema does not contain
the information required.
<<<END>>>
```
**Needs clarification**
```text
<<<CLARIFY>>>
Which date column defines the
requested reporting period?
<<<END>>>
```
### Three outcomes. No pretending.
`<<<SQL>>>` — A SQL query has been generated.
`<<<UNANSWERABLE>>>` — The supplied schema or available information is insufficient.
`<<<CLARIFY>>>` — The request requires additional specificity.
**Critical invariant:** An unterminated sentinel block must not be accepted as a complete answer.
Malformed or truncated output is rejected by the consuming application, rather than treated as executable SQL.
The protocol is a parsing contract. It is not, by itself, a SQL safety guarantee.
---
## 07 / THE IDENTITY IS IN THE MODEL
### Not an alias. Not a system-prompt costume.
**Name:** Imagine
**Builder:** Interchained
**Specialization:** SQL generation and schema-grounded coding
**Upstream lineage:** DeepSeek-Coder, through previous Imagine releases
**Deployment philosophy:** Local-first, developer-controlled inference
v12 was trained to respond consistently to questions about its identity without relying exclusively on identity instructions injected at inference time.
This includes testing around mistaken names, attribution, lineage, and conflicting identity claims.
**Interchained is the builder of Imagine. DeepSeek-Coder is part of its upstream technical lineage. Both facts matter.**
Identity training improves consistency but should not be mistaken for a cryptographic authentication or security mechanism.
---
## 08 / RUN IT YOURSELF
### Your machine. Your workload. Your inference.
Load the Transformers checkpoint:
```python
import torch
from transformers import AutoModelForCausalLM, AutoTokenizer
MODEL = "Interchained/imagine-v12"
tokenizer = AutoTokenizer.from_pretrained(MODEL)
model = AutoModelForCausalLM.from_pretrained(
MODEL,
torch_dtype=torch.bfloat16,
device_map="auto",
)
prompt = "Who are you and who built you?"
inputs = tokenizer(
prompt,
return_tensors="pt"
).to(model.device)
with torch.inference_mode():
output = model.generate(
**inputs,
max_new_tokens=128,
do_sample=False,
)
response = output[0][inputs["input_ids"].shape[1]:]
print(
tokenizer.decode(
response,
skip_special_tokens=True
)
)
```
For CPU-friendly local inference, use a compatible quantized GGUF build with llama.cpp or another supported local inference runtime.
The full-precision/BF16 Transformers checkpoint may require substantial memory or accelerator resources; it is the quantized deployment path that enables practical CPU-only use.
**Local inference offers:**
- No mandatory hosted inference API.
- No per-token provider charges.
- No external inference service dependency.
- Control over model execution and deployment.
- The ability to keep database schemas within your own infrastructure.
Local computation still incurs hardware, memory, electricity, and operational costs.
---
## 09 / THE THREE LAWS OF IMAGINE
### I. Verification beats confidence.
Don't build a second verifier when the database engine can already parse, plan, execute, and compare results.
Use the existing execution machinery.
### II. Measure behavior, not appearances.
String similarity is not query correctness.
Two SQL statements can look different and return the same correct result. Two nearly identical statements can produce materially different results.
**Execution accuracy is the metric that matters here.**
### III. Learn how to read schemas. Don't memorize one.
A production SQL model must be grounded in the schema it receives.
Column names, relationships, and table structures belong in the input context.
The model should learn how to reason over them rather than assume the training database exists everywhere.
**Generalization is the goal. Grounding is the discipline.**
---
## 10 / RESEARCH STATUS & SECURITY
### Built for serious experimentation. Not blind execution.
Imagine v12 is a research checkpoint.
Its 100% result on the documented 40-query evaluation does not guarantee correct behavior across every database, workload, dialect, or instruction.
Possible failure modes include:
- Incorrect SQL for novel or complex requests.
- Misinterpreted joins, aggregations, and time boundaries.
- Ambiguity that is not properly identified.
- Incorrect write predicates or unexpectedly broad mutations.
- Invalid or truncated generations.
- Identity or instruction-handling errors outside tested conditions.
**Never grant a language model unrestricted production database permissions.**
Production integrations should enforce least-privilege access, statement timeouts, query limits, schema restrictions, authorization controls, and audit logging.
**All INSERT, UPDATE, DELETE, and other mutating operations should require explicit human approval before execution.**
Model behavior is only one layer of a secure database application.
---
## 11 / WHY IMAGINE EXISTS
### Smaller models. Stronger verification. More ownership.
Imagine is part of a larger Interchained effort to create AI and data infrastructure that developers can own, inspect, deploy, and control.
The thesis is straightforward:
**You shouldn't have to rent intelligence by the token to ask your own database a question.**
You shouldn't need a large hosted model for every narrow task.
And you shouldn't have to trust fluent SQL merely because it looks convincing.
Imagine explores an alternative: a compact, specialized model trained with database-grounded examples, a strict output interface, and measurable execution behavior.
It is not an attempt to replace every frontier model.
It is an attempt to make one important class of work **smaller, more verifiable, and more sovereign.**
---
## 12 / THE RELEASE
**Imagine v12 — October 12, 2026**
131,400 training examples.
Two-stage fine-tuning.
Native identity training.
Execution-gated SQL curriculum.
40/40 held-out telemetry executions.
100% protocol compliance on the reported benchmark.
Zero invented columns in the evaluated set.
**One model. One identity. Your infrastructure.**
Developed by **Interchained**.
**Model:** https://huggingface.co/Interchained/imagine-v12
**Source:** https://github.com/aiassistsecure/sukuna-imagine
**Developers:** https://interchained.org
**Contact:** https://ourlynx.com/interchained
**License:** Apache 2.0
---
*We don't just generate answers.*
**We engineer the conditions under which answers can be trusted.**
**INTERCHAINED**
*Own the infrastructure. Verify the intelligence.*
`3 > 1` — Mark drives. Oracle points. Muse builds.