Upload ARTICLE.md with huggingface_hub

ARTICLE.md

@@ -247,6 +247,47 @@ worksheet from memory of that same reading."*
 **The key word is "ONE".** We encode the state exactly once. Every question reuses that
 pooled state vector — that's the parallelism, and it's real, not a marketing trick.
 
+Here is the actual diagram of our build (rendered from the code):
+
+![architecture](ARCHITECTURE.png)
+
+### 4.1a The input and the output (concretely)
+
+So you can see exactly what goes in and what comes out, here is a real request we ran on
+our trained model (full transcript in the screenshot at the end of this section):
+
+**INPUT — one `state`, three typed `questions`:**
+```json
+{
+  "state": "I've been trying to connect my Stripe account for 3 days,
+            it keeps failing with a 403. I'm losing sales and my manager
+            is anxious. Please help ASAP.",
+  "questions": {
+    "is_urgent":  { "type": "noul",   "instructions": "The message conveys urgency or time-sensitivity." },
+    "department": { "type": "choice", "instructions": "Which team should handle this?",
+                    "options": ["billing", "technical", "sales"] },
+    "frustration":{"type": "score",   "instructions": "How frustrated does the customer appear? (0=civil, 1=angry)" }
+  }
+}
+```
+
+**OUTPUT — one typed, probabilistic answer per question (no text generation):**
+```json
+{
+  "is_urgent":   { "type": "noul",   "noul": 0.6742, "is_true": true },
+  "department":  { "type": "choice", "distribution": {"billing": 0.0, "technical": 1.0, "sales": 0.0},
+                   "argmax": "technical", "confidence": 1.0 },
+  "frustration": { "type": "score",  "score": 0.518 }
+}
+```
+
+Every field is either a probability (noul), a probability distribution + confidence
+(choice), or a bounded number (score). No tokens are generated anywhere.
+
+**Screenshot of the real run** (this is actual terminal output from our model):
+
+![serve screenshot](SCREENSHOT_serve.png)
+
 ### 4.2 Three heads for three question types
 
 | Type | Head | Math | Output |
@@ -360,6 +401,29 @@ but *honest* smartness a program can safely branch on.
 And the serving demo returns the exact Jev response shape from one state + three parallel
 questions (full transcript in `RESULTS.md`).
 
+**Does our architecture *actually* predict in parallel — or is it just a fine-tuned
+transformer faking it?** This is the honest question, so let's answer it with a
+measurement, not an adjective. We ran the full answer path on one state while increasing
+the number of questions, on CPU:
+
+| Questions asked | Full answer time (ms) |
+|---|---|
+| 1 | 27.3 |
+| 3 | 35.7 |
+| 6 | 46.3 |
+| 12 | 101.0 |
+
+If we were *re-reading the state for every question* (the naive fine-tuned-transformer
+approach), going from 1 → 12 questions would cost **~12×** the time. Instead it costs
+**~3.7×**. The state encoder runs exactly once; the growth comes only from the cheap
+question-batch pass. That is the parallel property Jev claims, made measurable in our
+build. (This is a CPU number — the *structure* is what matters, not the milliseconds.)
+
+How it differs from "a transformer fine-tuned to act like Jev": a normal fine-tuned LLM
+*generates* an answer token-by-token (slow, sequential, can drift off-schema). Ours has
+**no generation loop at all** — the encoder runs, heads fire, done. That's the structural
+difference, not just a speed trick.
+
 The value of this build is architectural — you can hold it all in your head, watch it
 train, and share one encoder across three question types. Full data + deeper encoder + GPU
 is the same code with bigger numbers.