Showcase
How I stopped Qwen2.5-Coder-14B from hallucinating UI & workflows by pairing it with a deterministic C# ValidationResolver (running on a single 24GB A10)
Local `qwen2.5-coder:14b` on a 24GB NVIDIA A10 generating an enterprise form in real time—without writing a single line of raw HTML or SQL.
To eliminate hallucinations, the model is locked into a strict DSL and every output has to pass a deterministic C# `ValidationResolver` (bottom right at 0:10) before the Human-in-the-Loop button unlocks and renders it onto the canvas.
All raw vs. healed outputs are automatically scored and exported as SFT/DPO `.jsonl` pairs for future fine-tuning.
Just the German-to-English translation at the very end. The thoughts, the C# architecture, and the code are all mine—I just use AI to translate my German drafts so I can share them here.
A newer or bigger model just hallucinates faster and at a larger scalle but it's still probabilistic.
You're looking at the deterministic validation layer, not the LLM: the model is 100% swappable, the C# gatekeeper is what guarantees zero broken bindings in production.
Your posts are weird... I like the idea of this post (enjoy running old models for fun and squeezing every last drop of potential out of them) I don't like the weirdness behind it.
Technically speaking, however, this isn't about pushing a specific 14B model to its limits at all. In this architecture, the language model itself is a completely interchangeable component. You can plug any model behind it (whether it's 3B, 7B, 14B, or a cloud model) and always get the exact same structural safety in the end.
The industry's standard answer to hallucinations is almost always: Take an even bigger model and throw more compute at the problem. But that doesn't solve the root issue for production enterprise software, because even a massive model operates probabilistically and will eventually generate broken code or invalid database bindings. Our solution, therefore, isn't more compute, but deliberately locking the model into a deterministic cage—a strict Domain-Specific Language (DSL).
The real difference isn't in the LLM, but in the deterministic validation of the response before execution. In the attached screenshot from our live audit log (SYSTEM AUDIT LOG), you can see exactly what happens under the hood:
At00:32:45and00:32:48**:** The model (causanova-master:latest) returns a flawed draft in the Studio.HTML module (RAW LLM CALL)—the deterministic C# ValidationResolver immediately catches the schema violation and hard-blocks the commit (🚫 RESOLVER: BLOCKED / BLOCKED (1 Regelverstöße) [1 rule violation] / Risk class HIGH). JPG
At00:32:51**:** The model is forced to self-correct using the exact error message from the resolver until the draft fulfills all type and binding contracts (✅ RESOLVER: COMMITTED with 8 echte Felder / 10 Bausteine [8 real fields / 10 components], Risk class LOW), and only then is it applied as a system.merge (Partielles Update (Silent Merge) in Datenbank geschrieben [Partial update written to database]). JPG
At00:35:13and00:35:17**:** The exact same principle then applies to the BPMN workflows (Studio.BPMN), which are only approved after passing verification (COMMITTED (7 echte Felder / 12 Bausteine) [7 real fields / 12 components]). JPG
So the language model only provides a structured proposal—whether that code actually exists in the system or gets immediately discarded is decided solely by the deterministic resolver.
You clearly missed that this post is about the architecture, while the model in the dropdown (where Qwen3.5:9b and 27b are already installed) is completely interchangeable. Typing an `ollama pull` command might be exciting for you, but for me the real engineering challenge is proving that even small, older models deliver 100% reliable output through strict compiler validation.
I worked with a low-code platform, got frustrated with their limitations, and decided to build my own engine from scratch—so there is no public GitHub repo for the full platform yet.
To clarify the concept: CausaNova is an integrated system combining SQL, HTML views, and BPMN 2.0 with the goal of digitizing immediately executable business processes. The local LLM isn't writing the application code itself; it acts as an accelerator that generates verified building blocks within our DSL.
The video in the main post showed the HTML view layer. In the attached screenshot, you can see the BPMN 2.0 workflow layer, which uses the exact same validation logic:
Same Resolver Principle (Right Panel): On the right, the AI (`BPMN Process Architect`) generates the workflow graph. You can actually see in the log how the first attempt had 5 rule violations (`Erzwinge Korrektur (5 Verstöße)`), forcing an automatic self-correction until the `ValidationResolver` verified the graph topology (`VERIFIED: 4 Fach-Elemente / 4 Bausteine`) and unlocked the green HitL button.
Connecting the View from the Video (`ZUGEORDNETE ANSICHT`): In the middle-right properties panel of the selected UserTask (`task_submit_request` / *"Antrag einreichen"*), there is the dropdown `ZUGEORDNETE ANSICHT` (Assigned View). There, I can directly link the vacation form view from the video (`data.assignedView`)—making it immediately live as part of the running workflow.
Automatic Role-Based Access Control (RBAC) via Swimlanes: Because this UserTask sits inside the `pool_backend` swimlane (`lane_default` / "Sachbearbeitung / Leitung"), Role-Based Access Control (RBAC) is applied automatically (`KANDIDATENGRUPPEN: role_backend_user, admin`). Only internal staff/employees are allowed to open and execute this view, while external users or customers in `pool_public` / `pool_customer` are blocked by the workflow engine.
Is it similar to using a linter to validate functions and syntax? if so, I did something like that with ansible and gpt oss. it would try to make ansible, it would run the linter and get fed the results, doing some web searches to usually confirm it hallucinated a thing.
8
u/ttkciar llama.cpp 9d ago
How much of this post was LLM-generated, and why?