Interchained commited on
Commit
e35860d
·
verified ·
1 Parent(s): 99bf815

Replace with EPIC v10 model card

Browse files
Files changed (1) hide show
  1. README.md +162 -218
README.md CHANGED
@@ -1,16 +1,30 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
1
  <div align="center">
2
 
3
- # 🥷 sukuna-imagine
4
 
5
- ### A model small enough to run on your laptop. Strict enough to trust with your database.
6
 
7
  **Natural language in. Correct PostgreSQL out. ~1B parameters. No GPU. No API key. No metered inference.**
8
 
9
- [![gate](https://img.shields.io/badge/execution_gate-39%2F39_live_PostgreSQL-3ecf8e?style=flat-square)](tests/test_gate.py)
10
- [![verifier](https://img.shields.io/badge/verifier-PostgreSQL_16-336791?style=flat-square)](stealth/gate.py)
11
- [![parser](https://img.shields.io/badge/parser-libpg__query-336791?style=flat-square)](https://github.com/pganalyze/libpg_query)
12
- [![runtime](https://img.shields.io/badge/runtime-CPU_only-f5a524?style=flat-square)](#)
13
- [![licence](https://img.shields.io/badge/code-BUSL--1.1_→_Apache--2.0-8957e5?style=flat-square)](LICENSE)
 
14
 
15
  *Part of project `imagine` — Interchained*
16
 
@@ -18,117 +32,131 @@
18
 
19
  ---
20
 
21
- ## The uncomfortable question nobody asks about text-to-SQL
22
-
23
- > **How do you know the training data is right?**
24
 
25
- Almost everyone answers: *a big model wrote it, and big models are pretty good.*
26
 
27
- That is a vibe, not a verification. And it is why small text-to-SQL models
28
- confidently return a number that is simply **the wrong number** — syntactically
29
- perfect, schema-valid, executed without error, and answering a question nobody asked.
30
 
31
- We answer differently. **We run it.**
32
 
 
 
 
 
 
33
  ```
34
- ┌─────────────────────────────┐
35
- candidate SQL ───────► │ L0 real PostgreSQL parser │ not a regex
36
- ├─────────────────────────────┤
37
- │ L1 read-only + bounded │ no writes, no sleeps
38
- ├─────────────────────────────┤
39
- │ L2 EXPLAIN on live schema │ hallucinations die HERE
40
- ├─────────────────────────────┤
41
- │ L3 execute, timed, capped │ real rows
42
- ├─────────────────────────────┤
43
- │ L4 SAME ANSWER as ref? │ ◄── the one that matters
44
- └──────────────┬──────────────┘
45
- ▼
46
- admitted to corpus
47
  ```
48
 
49
- **Nothing enters the training set that a live database has not agreed with.**
50
 
51
  ---
52
 
53
- ## 🎯 The one-character problem
54
 
55
- This is the failure mode that makes text-to-SQL quietly dangerous, and the reason L4 exists:
56
 
57
- | candidate | reference | text diff | **answer** |
58
- |---|---|---|---|
59
- | `count(*)` | `count(id)` | big | ✅ **same** |
60
- | `JOIN ... WHERE total > 400` | `WHERE id IN (SELECT ...)` | huge | ✅ **same** |
61
- | `WHERE price >= 249` | `WHERE price > 249` | **one character** | ❌ **different** |
62
- | `WHERE status = 'Paid'` | `WHERE status = 'paid'` | **one letter** | ❌ **different** |
63
 
64
- Every string-similarity metric gets this exactly backwards. It rewards the queries that
65
- *look* alike and punishes the ones that *are* alike.
66
 
67
- **Execution doesn't care what your query looks like.**
68
 
69
- ---
 
 
 
 
70
 
71
- ## 💡 Why a 1B model can actually win here
72
 
73
- Because text-to-SQL is one of the rare tasks with a **perfect verifier** sitting right there,
74
- already installed, already correct: the database.
75
 
76
- You can't machine-check *"is this a good conversational answer?"*
77
- You absolutely can machine-check *"does this return the same rows?"*
78
 
79
- We have run this play before. [**nedb-cast-slm**](https://github.com/aiassistsecure/nedb-cast-slm)
80
- hit **92% exact-plan match at 3.3 million parameters** — trained on 2 vCPUs in 41 minutes —
81
- because the query parser was simultaneously the corpus generator, the grader, *and* the
82
- entry gate. No example got in unless it round-tripped.
83
 
84
- > Same play. Bigger grammar. A real database instead of a toy one.
85
 
86
- ---
 
 
 
 
87
 
88
- ## 🧨 The bug that became the feature
89
 
90
- Our previous model's headline failure was this: asked to query NEDB, it emitted
 
 
 
 
 
91
 
92
- ```sql
93
- SELECT COUNT(*) FROM orders WHERE status = 'paid';
94
- ```
95
 
96
- ...when the spec demanded our in-house query language. We logged it as a defect. We wrote
97
- tooling to prevent it. We nearly fine-tuned it away.
98
 
99
- Then NEDB v5 dropped the in-house language and vendored PostgreSQL's grammar instead —
100
- *"nobody wants to learn a new query language."*
 
 
 
 
 
101
 
102
- **The model had been right the whole time.** This repo is what happens when you stop
103
- correcting it and start training it.
104
 
105
  ---
106
 
107
- ## 📦 The output envelope
108
 
109
- The model wraps SQL in [**sentinel blocks**](https://github.com/Eth-Interchained/sentinel-blocks):
110
 
111
  ```
112
- <<<SQL>>>
113
- SELECT c.city, count(*)
114
- FROM orders o JOIN customers c ON c.id = o.customer_id
115
- WHERE o.status = 'paid'
116
- GROUP BY c.city;
117
- <<<END>>>
 
118
  ```
119
 
120
- SQL is *the* payload that justifies the technique — single quotes, double quotes, semicolons,
121
- newlines, dollar-quoting, all at once. Anything that **re-parses** the payload (JSON escaping,
122
- markdown fences, a regex hunting for `SELECT.*`) will eventually mangle a legitimate query.
123
 
124
- Sentinels are extracted **by delimiter and never interpreted.** Proven on the nastiest fixture
125
- we could write:
 
126
 
127
- ```sql
128
- SELECT 'a;b', "weird col" FROM t WHERE x = 'it''s' -- round-trips byte-exact
 
 
 
 
 
 
129
  ```
130
 
131
- **And it can refuse:**
132
 
133
  | block | meaning |
134
  |---|---|
@@ -136,177 +164,95 @@ SELECT 'a;b', "weird col" FROM t WHERE x = 'it''s' -- round-trips byte-exact
136
  | `<<<UNANSWERABLE>>>` | this schema cannot answer that |
137
  | `<<<CLARIFY>>>` | ambiguous — here's what's missing |
138
 
139
- Guessing is the enemy. A model that says *"there is no revenue column"* beats one that
140
- invents `SUM(revenue)` every single time.
141
-
142
- > ⚠️ **A truncated generation is not an answer.** An unterminated block — or two blocks —
143
- > extracts to **nothing**. Silently accepting half a query is how you execute half a query.
144
 
145
  ---
146
 
147
- ## 🔬 What's proven, right now
148
 
149
- > **New:** the execution backend is now NEDB, not standalone PostgreSQL.
150
- > `scripts/bootstrap_nedb.sh` starts the embedded engine's pgwire endpoint
151
- > and seeds the schema — no postgres install, no root, no socket paths.
152
- > The gate verifies against NEDB's time-traveling store, and the repo ships
153
- > with its data embedded.
154
 
155
- ```
156
- == sentinel envelope == 9/9 ✅
157
- == gate levels (live PostgreSQL 16) == 24/24 ✅
158
- == L4 result agreement == 6/6 ✅
159
- ─────
160
- 39/39
161
- ```
162
 
163
- Real errors from the real planner, not simulated:
 
 
 
 
 
164
 
165
- ```
166
- hallucinated table → ERROR: relation "invoices" does not exist
167
- hallucinated column → ERROR: column "customer_name" does not exist
168
- ambiguous reference → ERROR: column reference "id" is ambiguous
169
- the old DSL sneaking in → ParseError: syntax error at or near "FROM"
170
- SELECT 1; DROP TABLE ... → rejected: expected exactly 1 statement, got 2
171
- ```
172
 
173
- **Half the fixtures must REJECT. Half must ACCEPT. The accept half matters more** — a gate
174
- that quietly refuses *correct* SQL starves the corpus of exactly the examples worth learning
175
- from, and nothing downstream would ever tell you.
176
 
177
- That discipline is not theoretical. The previous model's harness produced **seven distinct
178
- false-positive classes**, each one flattering us until it was caught. Here it caught a broken
179
- fixture of mine on the very first run — the gate was right and my test was wrong.
180
 
181
- ---
 
182
 
183
- ## 🧬 Imagine v1: teacher → verifier → student
184
-
185
- The model that ships is **not** the teacher.
186
-
187
- ```text
188
- mistralai/Devstral-Small-2507 teacher; proposes harder SQL
189
- │
190
- ▼
191
- PostgreSQL L0-L4 gate truth authority
192
- │
193
- ▼
194
- verified SQL + Imagine identity
195
- │
196
- ▼
197
- deepseek-ai/deepseek-coder-1.3b-instruct canonical student base
198
- │
199
- ▼
200
- Imagine compact local model
201
  ```
202
 
203
- The canonical v1 student is **DeepSeek-Coder-1.3B-Instruct**. Devstral is an
204
- optional corpus teacher only: its SQL never enters training unless the live
205
- database agrees with the deterministic reference at L4.
206
-
207
- ### Build the v1 training corpus
208
-
209
- Template-only forging remains the zero-teacher baseline. To add Devstral
210
- proposals:
211
-
212
- ```bash
213
- python scripts/forge_teacher.py \
214
- --teacher mistralai/Devstral-Small-2507 \
215
- --out corpus/sql_train.jsonl \
216
- --rejects corpus/sql_rejects.jsonl
217
 
218
- python scripts/make_identity.py --out corpus/identity.jsonl
219
 
220
- python scripts/merge_corpus.py \
221
- --out corpus/imagine_train.jsonl \
222
- corpus/sql_train.jsonl corpus/identity.jsonl
223
- ```
224
 
225
- Identity is deliberately small. It teaches the name **Imagine**, Interchained
226
- provenance, local-first purpose, schema-grounding, read-only behavior, and the
227
- refuse/clarify contract. SQL capability still comes overwhelmingly from the
228
- execution-gated corpus.
229
 
230
- ### Train the student
231
 
232
- ```bash
233
- bash scripts/train_imagine.sh
234
- ```
235
-
236
- Override any component without editing the recipe:
237
 
238
- ```bash
239
- STUDENT=deepseek-ai/deepseek-coder-1.3b-instruct \
240
- CORPUS=corpus/imagine_train.jsonl \
241
- OUT=runs/imagine-deepseek13-v1 \
242
- bash scripts/train_imagine.sh
243
- ```
244
 
245
- The first checkpoint is still judged on the held-out schema with
246
- `stealth.evaluate`; training loss is not the product metric.
247
 
248
  ---
249
 
250
- ## 🗺️ Status
251
 
252
- | component | state |
253
- |---|---|
254
- | 🟢 Execution gate (L0–L4) | **built · 39/39 on live PostgreSQL 16** |
255
- | 🟢 Sentinel envelope | **built · fixture-proven** |
256
- | 🟢 Schema catalog | **5 schemas, adversarial by design** |
257
- | 🟢 Parallel corpus forge | **built · 2,027 candidates/sec on 2 cores · 19/19 poison fixtures** |
258
- | 🟢 Execution-accuracy eval | **built · 4/4 directions verified (oracle 100%, saboteur 0%)** |
259
- | 🟢 Training harness (A6000) | **built · bf16 · packed · FlashAttention-2 · full FT default** |
260
- | 🟢 Canonical student base | **DeepSeek-Coder-1.3B-Instruct** |\n| 🟢 Optional teacher path | **Devstral Small 2507 → L4 execution gate** |\n| 🟡 Imagine v1 training | identity + verified SQL corpus ready to build |
261
-
262
- ### One command
263
-
264
- ```bash
265
- BASE=<hf-id-or-path> ./scripts/run_a6000.sh
266
- ```
267
-
268
- Gate self-test → forge corpus → build held-out eval → **baseline the base model
269
- before training it** → train → re-evaluate. Step 3 is not optional: without a
270
- before-number, an after-number means nothing.
271
 
272
- ---
 
273
 
274
- ## ⚡ Run it yourself
 
275
 
276
- ```bash
277
- pip install psycopg2-binary pglast
278
- ./scripts/bootstrap_pg.sh # throwaway PostgreSQL, durability off
279
- python tests/test_gate.py # expect 39/39
280
- ```
281
 
282
- No API keys. No cloud. The verifier runs on your machine, because that is the entire point.
283
 
284
- ---
285
 
286
- ## 📐 Four rules, each one paid for
 
 
287
 
288
- **1 · Don't write a verifier — the engine already shipped one.**
289
- Real parser. Real planner. Real rows. Every hand-rolled SQL validator is a bug farm that
290
- disagrees with the database in ways you discover in production.
291
 
292
- **2 · Assert the property, not a proxy.**
293
- Every check self-tests in *both* directions before it is trusted. Seven harness lies taught
294
- us this, and all seven were the same mistake: measuring the easy thing instead of the true thing.
295
 
296
- **3 · Exhaust the free fix first.**
297
- On the previous model, two fine-tune runs moved the target metric by **zero**. One schema
298
- redesign moved it by **four**. Training is the last resort, not the first instinct.
299
 
300
- **4 · Schema goes in the prompt, not in the weights.**
301
- The model must learn *"read the schema you were handed"* — not memorise ours. The catalog is
302
- adversarial on purpose: the same concept under different names (`orders` / `appointments` /
303
- `routes`), the same name meaning different things (`total` is money in one schema and a
304
- package **count** in another), camelCase, quoted `"Mixed Case"`, reserved words like `order`
305
- that must be quoted, nullable columns so `count(col) != count(*)` is real, and a table with
306
- zero rows so "no results" is a trained-for answer.
307
 
308
- `telemetry` is **held out entirely.** The gap between trained-schema accuracy and held-out
309
- accuracy *is* the memorisation gap, and it is printed on every eval run.
 
 
 
 
310
 
311
  ---
312
 
@@ -314,8 +260,6 @@ accuracy *is* the memorisation gap, and it is printed on every eval run.
314
 
315
  **Built by [Interchained](https://github.com/Eth-Interchained)** · ownership at every layer, including the model
316
 
317
- Code **BUSL-1.1** → Apache-2.0 on 2030-09-19 · open source on a timer, not open source withheld
318
-
319
- `3 > 1`
320
 
321
  </div>
 
1
+ ---
2
+ license: apache-2.0
3
+ language:
4
+ - en
5
+ library_name: transformers
6
+ pipeline_tag: text-generation
7
+ tags:
8
+ - text-to-sql
9
+ - postgresql
10
+ - code-generation
11
+ base_model: Interchained/imagine-v9
12
+ ---
13
+
14
  <div align="center">
15
 
16
+ # 🧠 imagine-v10
17
 
18
+ ### 100% on held-out. Zero hallucinations. Analytical SQL that actually works.
19
 
20
  **Natural language in. Correct PostgreSQL out. ~1B parameters. No GPU. No API key. No metered inference.**
21
 
22
+ [![eval](https://img.shields.io/badge/heldout_eval-40%2F40_100%25-3ecf8e?style=flat-square)](#evaluation)
23
+ [![gate](https://img.shields.io/badge/execution_gate-68%2F68-3ecf8e?style=flat-square)](#execution-gate)
24
+ [![protocol](https://img.shields.io/badge/protocol_compliance-100%25-3ecf8e?style=flat-square)](#evaluation)
25
+ [![hallucinations](https://img.shields.io/badge/invented_columns-0-3ecf8e?style=flat-square)](#evaluation)
26
+ [![runtime](https://img.shields.io/badge/runtime-CPU_only-f5a524?style=flat-square)](#local-first)
27
+ [![licence](https://img.shields.io/badge/license-Apache--2.0-8957e5?style=flat-square)](#status)
28
 
29
  *Part of project `imagine` — Interchained*
30
 
 
32
 
33
  ---
34
 
35
+ ## The failure that built v10
 
 
36
 
37
+ v9 was asked for a LEFT JOIN analytical query:
38
 
39
+ ```sql
40
+ -- "List every customer, their total completed spending, sort by spending desc"
41
+ ```
42
 
43
+ It returned:
44
 
45
+ ```sql
46
+ SELECT c.id, c.name, COALESCE(o.total, 0) AS total_spending
47
+ FROM customers c
48
+ LEFT JOIN orders o ON c.id
49
+ -- ...truncated. Dead.
50
  ```
51
+
52
+ The correct answer:
53
+
54
+ ```sql
55
+ SELECT c.id, c.name, COALESCE(SUM(o.total), 0) AS total_spending
56
+ FROM customers c
57
+ LEFT JOIN orders o ON c.id = o.customer_id AND o.status = 'completed'
58
+ GROUP BY c.id, c.name
59
+ ORDER BY total_spending DESC, c.id ASC;
 
 
 
 
60
  ```
61
 
62
+ v9 couldn't do multi-clause analytical queries. **v10 can.**
63
 
64
  ---
65
 
66
+ ## 🎯 What v10 adds
67
 
68
+ Where v9 added write capability (`INSERT`/`UPDATE`/`DELETE`), v10 adds **complex analytical queries**:
69
 
70
+ - **LEFT JOIN + GROUP BY + COALESCE** — the exact v9 failure mode, now handled
71
+ - **HAVING filters** — post-aggregation conditions
72
+ - **Subquery comparisons** — nested analytical logic
73
+ - **Complex ORDER BY** — multi-column, expression-based sorting
74
+ - **Multi-table JOINs** — beyond simple two-table patterns
 
75
 
76
+ ---
 
77
 
78
+ ## 📊 The numbers
79
 
80
+ | Model | Held-out (telemetry) | Protocol | Execute rate | Invented cols |
81
+ |---|---|---|---|---|
82
+ | imagine-v8 | 50.0% (20/40) | 100% | — | — |
83
+ | imagine-v9 | 90.0% (36/40) | 100% | 97.5% | 0 |
84
+ | **imagine-v10** | **100.0% (40/40)** | **100%** | **100%** | **0** |
85
 
86
+ **Perfect score.** Zero wrong answers. Zero hallucinations. Zero refusals.
87
 
88
+ ---
 
89
 
90
+ ## 🧬 How v10 was built
 
91
 
92
+ Two-stage fine-tuning from `Interchained/imagine-v9`:
 
 
 
93
 
94
+ ### Stage 1 — Full fine-tune (smoke)
95
 
96
+ - **Corpus:** 3,216 admitted pairs (99.94% gate admit rate)
97
+ - **New:** Analytical query templates (LEFT JOIN aggregations, HAVING, subqueries)
98
+ - **Epochs:** 3, LR 1e-5, cosine schedule
99
+ - **Final loss:** 0.0052 (v9 was 0.0320 — **6x better**)
100
+ - **Time:** 4.1 min on H200, 26k tok/s
101
 
102
+ ### Stage 2 — LoRA refinement
103
 
104
+ - **Base:** v10-smoke checkpoint
105
+ - **Rank:** 16, LR 5e-6
106
+ - **Epochs:** 3
107
+ - **Final loss:** 0.0244
108
+ - **Time:** 5.4 min on H200
109
+ - Adapter folded into full checkpoint
110
 
111
+ ### The corpus
 
 
112
 
113
+ 3,218 candidates forged, 3,216 admitted:
 
114
 
115
+ | Schema | Templates | Writes | Total |
116
+ |---|---|---|---|
117
+ | shop | 356 | 388 | 744 |
118
+ | clinic | 545 | 290 | 835 |
119
+ | library | 481 | 257 | 738 |
120
+ | fleet | 297 | 226 | 523 |
121
+ | audit | 252 | 126 | 378 |
122
 
123
+ **Nothing enters training that a live database hasn't agreed with.**
 
124
 
125
  ---
126
 
127
+ ## 🔬 The execution gate
128
 
129
+ Every candidate goes through L0–L4:
130
 
131
  ```
132
+ candidate SQL ──► L0 real PostgreSQL parser not a regex
133
+ L1 read-only + bounded no writes, no sleeps
134
+ L2 EXPLAIN on live schema hallucinations die HERE
135
+ L3 execute, timed, capped real rows
136
+ L4 SAME ANSWER as ref? ◄── the one that matters
137
+ ▼
138
+ admitted to corpus
139
  ```
140
 
141
+ 68/68 gate tests passing. The gate is the truth authority — not a bigger model, not vibes.
142
+
143
+ ---
144
 
145
+ ## 📦 Output protocol
146
+
147
+ SQL wrapped in sentinel blocks:
148
 
149
+ ```
150
+ <<<SQL>>>
151
+ SELECT c.id, c.name, COALESCE(SUM(o.total), 0) AS total_spending
152
+ FROM customers c
153
+ LEFT JOIN orders o ON c.id = o.customer_id AND o.status = 'completed'
154
+ GROUP BY c.id, c.name
155
+ ORDER BY total_spending DESC, c.id ASC;
156
+ <<<END>>>
157
  ```
158
 
159
+ Can also refuse:
160
 
161
  | block | meaning |
162
  |---|---|
 
164
  | `<<<UNANSWERABLE>>>` | this schema cannot answer that |
165
  | `<<<CLARIFY>>>` | ambiguous — here's what's missing |
166
 
167
+ > ⚠️ **A truncated generation is not an answer.** An unterminated block extracts to **nothing**.
 
 
 
 
168
 
169
  ---
170
 
171
+ ## 💻 Loading v10
172
 
173
+ ```python
174
+ from transformers import AutoModelForCausalLM, AutoTokenizer
175
+ import torch
 
 
176
 
177
+ model_id = "Interchained/imagine-v10"
 
 
 
 
 
 
178
 
179
+ tokenizer = AutoTokenizer.from_pretrained(model_id)
180
+ model = AutoModelForCausalLM.from_pretrained(
181
+ model_id,
182
+ torch_dtype=torch.bfloat16,
183
+ device_map="auto",
184
+ )
185
 
186
+ # Ask for an analytical query
187
+ prompt = """Schema:
188
+ customers(id, name)
189
+ orders(id, customer_id, total, status)
 
 
 
190
 
191
+ List every customer ID, name, and total completed spending.
192
+ Include customers with no completed orders (show 0).
193
+ Sort by spending descending, then ID ascending."""
194
 
195
+ inputs = tokenizer(prompt, return_tensors="pt").to(model.device)
 
 
196
 
197
+ with torch.no_grad():
198
+ output = model.generate(inputs["input_ids"], max_new_tokens=256, do_sample=False)
199
 
200
+ print(tokenizer.decode(output[0], skip_special_tokens=True))
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
201
  ```
202
 
203
+ ---
 
 
 
 
 
 
 
 
 
 
 
 
 
204
 
205
+ ## 🎯 Identity
206
 
207
+ The deployed model identity is **Imagine**.
 
 
 
208
 
209
+ Built and fine-tuned by **Interchained**.
 
 
 
210
 
211
+ DeepSeek-Coder is part of the upstream lineage (via v8 → v9 → v10), but the deployed identity is Imagine.
212
 
213
+ ---
 
 
 
 
214
 
215
+ ## ⚡ Local-first
 
 
 
 
 
216
 
217
+ Runs on your hardware. No API key. No metered inference. No cloud dependency.
 
218
 
219
  ---
220
 
221
+ ## 📐 The rules
222
 
223
+ **1 · Don't write a verifier — the engine already shipped one.**
224
+ Real parser. Real planner. Real rows.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
225
 
226
+ **2 · Assert the property, not a proxy.**
227
+ Execution accuracy, not string similarity.
228
 
229
+ **3 · Schema goes in the prompt, not in the weights.**
230
+ The model learns *"read the schema you were handed"* — not memorise ours.
231
 
232
+ ---
 
 
 
 
233
 
234
+ ## ⚠️ Limitations
235
 
236
+ v10 is a research checkpoint. It may still:
237
 
238
+ - generate incorrect SQL on novel patterns
239
+ - misunderstand ambiguous requests
240
+ - produce writes with wrong `WHERE` clauses — **always review before executing**
241
 
242
+ Generated SQL should be reviewed before use in production. This applies doubly to writes.
 
 
243
 
244
+ ---
 
 
245
 
246
+ ## 🔒 Security
 
 
247
 
248
+ Do not rely on model behavior alone for database safety. Production systems should enforce:
 
 
 
 
 
 
249
 
250
+ - least-privilege database roles
251
+ - statement timeouts and row limits
252
+ - query validation and schema restrictions
253
+ - application-level authorization
254
+ - audit logging
255
+ - **human approval for all write statements**
256
 
257
  ---
258
 
 
260
 
261
  **Built by [Interchained](https://github.com/Eth-Interchained)** · ownership at every layer, including the model
262
 
263
+ `3 > 1` — Mark drives, oracle points, Muse builds
 
 
264
 
265
  </div>