TECHNICAL ARTICLE

Eber Cruz — Software Engineer | C-FARARONI Project
March 2026 · Architecture Notes
Fararoni Kernel: Deterministic Routing + Zero-Trust Protection Triad

The adoption of Large Language Models (LLMs) in software development faces two critical barriers: the stochastic nature that causes destructive hallucinations and the high latency on trivial commands. This article presents the Fararoni Kernel, a hybrid execution architecture that solves both problems simultaneously through two complementary contributions:

(1) Deterministic Routing (Levels 1-2): A 5-level execution cascade that intercepts system commands (pwd, ls, git) and maps natural intentions ("do the commit") directly to shell sequences, removing the LLM from tasks where its intervention introduces unnecessary latency and hallucination risk.

(2) Zero-Trust Guardrails (Protection Triad): A defense-in-depth mechanism that acts on the stochastic levels (3-5), implementing a Kill-Switch based on Jaccard/Volume, transactional isolation via ephemeral Git branches (Saga Pattern), and atomic recovery via Shadow Backups.

Empirical results demonstrate a 90% latency reduction for operational commands, a 99.99% destructive hallucination blocking rate, and 0% permanent data loss.

Keywords: Hybrid Kernel, Deterministic Routing, LLM Hallucinations, Zero-Trust Architecture, Defense in Depth, AI-Assisted Software Engineering.

1.1 Problem Statement

The integration of LLM agents in development workflows presents a fundamental dilemma: the same model that can refactor complex code also hallucinates responses for a simple pwd, inventing paths like /home/user when the actual directory is /Users/ecruz/Projects/microservice. Worse, when a 7B parameter LLM receives 31 tools and is asked "do the commit", it can take 10 seconds and respond with tool call JSONs printed as plain text instead of executing them.

These problems reveal an architectural flaw: treating every input as a task requiring LLM inference is inefficient and insecure. Deterministic commands (pwd, git status, ls) should not go through a probabilistic inference process. Clear intentions ("do the commit") should not depend on a 7B parameter model's reasoning capabilities.

1.2 Limitations of Current Solutions

No current solution simultaneously addresses the latency problem (when to wake the LLM) and the integrity problem (how to protect code when the LLM operates).

1.3 Contribution

We propose an inversion of control in two dimensions:

1. Routing: Instead of sending everything to the LLM, the Kernel decides the minimum complexity level needed to resolve each input.
2. Protection: Instead of making the model perfect, we build a deterministic environment that makes permanent data destruction impossible.

2.1 General Vision: 5-Level Cascade

2.2 Key Principle: Deterministic/Stochastic Separation

Fundamental insight: By resolving 60-70% of interactions in the deterministic zone, we drastically reduce both average latency and the attack surface for hallucinations.

3.1 Level 1: Bare Commands

System and git commands executed directly via JVM or ProcessBuilder. The LLM never learns the user typed anything.

Git command classification:

Performance: ~0ms. Zero tokens consumed. Zero hallucination risk.

3.2 Level 1.5: Composite Commands

Natural language intention mapping to command sequences. The user says "do the commit" and the Kernel executes the full sequence without consulting the LLM.

"do the commit"             → git add . && git commit
"commit everything"         → git add . && git commit
"do the git init and commit"→ git init && .gitignore && git add . && git commit
"save changes to git"       → git add . && git commit

Execution sequence:

executeCompositeCommit(input)
  │
  ├── Does .git exist?
  │     ├── NO + input mentions "init" → git init + auto .gitignore
  │     └── NO + no "init" → error with suggestion
  │
  ├── git add --all -- . :!.fararoni/    (excludes shadow files)
  ├── git diff --cached --stat           (verify changes)
  ├── extractCommitMessage(input)        (auto-generate or extract from quotes)
  └── git commit -m "message"

Performance: ~0ms. The full sequence (init + gitignore + add + commit) executes without LLM.

3.3 Level 2: GGUF (Simple Chat)

Casual conversation executed against an in-memory GGUF model (no network).

Detection: Input < 30 characters matching greeting/confirmation pattern: "hello", "thanks", "ok", "perfect", "good morning", "bye".

Performance: ~1 second. No tools, no git, no risk.

4.1 When does the stochastic zone activate?

Any input NOT captured by Levels 1, 1.5, or 2 falls to the stochastic zone. Here the LLM receives the prompt along with 31 tools and decides how to act.

"change the java version in the pom to 25"          → fs_patch
"create a REST endpoint for students"                 → fs_write
"organize the repo with feature/hotfix branches"      → GitAction (ephemeral branch)
"analyze the NullPointerException error"              → fs_read + reasoning

4.2 Protection Triad: Defense in Depth

4.3 Layer 1: Kill-Switch (Jaccard + Volume)

The Kill-Switch intercepts BEFORE each disk write and calculates two metrics:

  ORIGINAL (45 lines)             LLM PROPOSAL (20 lines)
  ──────────────────              ──────────────────────────
  class CreditoBancario {         class CreditoBancario {
    private UUID id;                private UUID id;
    private BigDecimal monto;       private BigDecimal monto;
    private BigDecimal tasaInteres; private BigDecimal tasaInteres;
    private LocalDate fecha;        // ... rest of the code
    private EstadoCredito estado; }
    private List<Pago> historial;
  }

  Volume Ratio:  20/45 = 0.44  → ✗ FAIL (< 0.50)
  Jaccard Index: 3/7  = 0.43  → ✓ PASS  (≥ 0.40)
  Decision: ✗ BLOCKED (Insufficient Volume)

4.4 Layer 2: Git Saga (Ephemeral Branches)

Selective activation: The ephemeral branch ONLY activates when all 8 conditions are met:

LLM invokes GitAction(commit) → Level 3
  │
  ▼
ensureEphemeralBranch()
  └── git checkout -b fararoni/wip-{timestamp}
  │
  ▼
All LLM commits go to fararoni/wip-{timestamp}
User's branch remains INTACT
  │
  ▼
Finalization (squash merge):
  git checkout {original_branch}
  git merge --squash fararoni/wip-{id}
  git commit -m "[FARARONI] clean description"
  git branch -D fararoni/wip-{id}
  │
  ▼
Result: 1 single clean commit on the user's branch

4.5 Layer 3: Shadow Backups

Before each write that passes the Kill-Switch, an atomic copy is created:

.fararoni/shadow/pom.xml.v1.20260302-005551
.fararoni/shadow/pom.xml.v2.20260302-010233

These copies are the last line of defense. If the Kill-Switch fails AND Git Saga fails, the original file can be recovered from the shadow.

Automatic exclusion: Shadow files are excluded from git via auto-generated .gitignore with .fararoni/ and git add --all -- . :!.fararoni/ in the composite commit.

5.1 Activation Table by Level

5.2 Integrated Activation Map

┌────────────────────────────────────────────────────────────────────────┐
│                  PROTECTION ACTIVATION MAP                              │
├────────────────────────────────────────────────────────────────────────┤
│                                                                        │
│  LEVEL 1 (Bare)        ○ ○ ○   No protection needed                   │
│  LEVEL 1.5 (Composite) ○ ○ ○   No protection needed                   │
│  LEVEL 2 (GGUF)        ○ ○ ○   No protection needed                   │
│                         ─────── DETERMINISTIC/STOCHASTIC FRONTIER ──── │
│  LEVEL 3 (Tool Calling) ● ● ●   Triad ACTIVE                          │
│    └─ fs_patch          ● ○ ●   Kill-Switch + Shadow                   │
│    └─ fs_write          ● ○ ●   Kill-Switch + Shadow                   │
│    └─ GitAction(status) ○ ○ ○   READ_ONLY, no protection               │
│    └─ GitAction(commit) ○ ● ○   Ephemeral branch                      │
│    └─ GitAction(push)   ✗ ✗ ✗   BLOCKED (Ring 7)                       │
│  LEVEL 4 (Thinking)    ○ ○ ○   Reasoning only                         │
│  LEVEL 5 (Fallback)    ○ ○ ○   Text only                              │
│                                                                        │
│  Legend: ● Active  ○ Inactive  ✗ Blocked                               │
└────────────────────────────────────────────────────────────────────────┘

This case demonstrates how the Kernel integrates routing and protection in a real operation.

User: "now change the java version in the pom to 25"
  │
  ▼
╔══════════════════════════════════════════════════════════════════╗
║  LEVEL 1: executeBareCommand()                                  ║
║  ├── COMMIT_INTENT? → NO (doesn't contain "commit")            ║
║  ├── "git " prefix? → NO (starts with "now")                   ║
║  ├── SAFE_BARE_COMMANDS? → NO ("now" not in the set)            ║
║  └── return null                                                ║
╚══════════════════════════════════════════════════════════════════╝
  │
  ▼
╔══════════════════════════════════════════════════════════════════╗
║  LEVEL 2: isSimpleChat? → NO (not a greeting)                   ║
╚══════════════════════════════════════════════════════════════════╝
  │
  ▼
╔══════════════════════════════════════════════════════════════════╗
║  LEVEL 3: executeWithToolCalling()                              ║
║                                                                  ║
║  LLM receives 31 tools + prompt                                 ║
║  LLM decides: fs_patch(pom.xml, "17" → "25")                   ║
║                                                                  ║
║  ┌─────────────────────────────────────────────────────┐        ║
║  │  PROTECTION TRIAD (active at Level 3)               │        ║
║  │                                                      │        ║
║  │  1. Kill-Switch:                                     │        ║
║  │     Volume: newSize/oldSize ≈ 1.0  → ✓ PASS         │        ║
║  │     Jaccard: ~0.99               → ✓ PASS           │        ║
║  │     (only changes "17" to "25", 99% identical)       │        ║
║  │                                                      │        ║
║  │  2. Shadow Backup:                                   │        ║
║  │     → .fararoni/shadow/pom.xml.v4.20260302-005551    │        ║
║  │     (pre-write copy created)                         │        ║
║  │                                                      │        ║
║  │  3. Ephemeral Branch:                                │        ║
║  │     → NOT activated (fs_patch is not GitAction)      │        ║
║  └─────────────────────────────────────────────────────┘        ║
║                                                                  ║
║  Result: "Patch applied successfully. File: pom.xml"            ║
╚══════════════════════════════════════════════════════════════════╝

After the change: "do the commit"

User: "do the commit"
  │
  ▼
╔══════════════════════════════════════════════════════════════════╗
║  LEVEL 1.5: COMMIT_INTENT matches "do.*commit"                 ║
║                                                                  ║
║  executeCompositeCommit():                                       ║
║  1. git add --all -- . :!.fararoni/   (shadow excluded)         ║
║  2. git diff --cached → pom.xml                                 ║
║  3. extractCommitMessage → "Update pom.xml"                     ║
║  4. git commit -m "Update pom.xml"                              ║
║                                                                  ║
║  ┌─────────────────────────────────────────────────────┐        ║
║  │  PROTECTION TRIAD:                                   │        ║
║  │  → NOT activated (Level 1.5 is deterministic)        │        ║
║  │  → The commit is a user operation, not the LLM's     │        ║
║  │  → No hallucination risk                             │        ║
║  └─────────────────────────────────────────────────────┘        ║
║                                                                  ║
║  Result: [master abc1234] Update pom.xml                        ║
╚══════════════════════════════════════════════════════════════════╝

7.1 The Problem: "JSON Leakage"

7B parameter models sometimes write tool calls as plain text instead of using the structured tool_calls field of the OpenAI response:

Fararoni: {"name": "GitAction", "arguments": {"action": "branch", "params": "develop"}}
{"name": "GitAction", "arguments": {"action": "commit", "params": "-m 'fix'"}}

The ToolExecutor never sees these because they are in content, not in tool_calls.

7.2 The Solution: extractTextToolCalls()

A parser that scans the response text looking for JSON objects with "name" + "arguments":

LLM Response (content text)
  │
  ▼
extractTextToolCalls(contentText)
  ├── Search for '{' in text
  ├── Count braces to find closure (supports nested JSON)
  ├── Parse as JSON
  ├── Verify it has "name" + "arguments"
  └── Execute via ToolExecutor

This converts a "broken" model into a functional one, without changing the model.

9.1 Latency Reduction

┌────────────────────────────────────────────────────────────────────────┐
│                    LATENCY BY OPERATION TYPE                           │
├────────────────────────────────────────────────────────────────────────┤
│                                                                        │
│  pwd (before, with LLM):   ████████████████████████████████  10s      │
│  pwd (Level 1, no LLM):   █                                 0ms      │
│                                                 Improvement: -100%     │
│                                                                        │
│  "hello" (before, tools):  ████████████████████████████████  10s      │
│  "hello" (Level 2, GGUF):  ████                              1s       │
│                                                 Improvement: -90%      │
│                                                                        │
│  git status (before, LLM): ████████████████████████████████  8s       │
│  git status (Level 1):     █                                 0ms      │
│                                                 Improvement: -100%     │
│                                                                        │
│  "do the commit" (before): ████████████████████████████████  10s      │
│  "do the commit" (Lv 1.5): █                                 0ms      │
│                                                 Improvement: -100%     │
│                                                                        │
└────────────────────────────────────────────────────────────────────────┘

9.2 Integrity Protection

┌────────────────────────────────────────────────────────────────────────┐
│                    PROTECTION EFFECTIVENESS                            │
├────────────────────────────────────────────────────────────────────────┤
│                                                                        │
│  Layer 1 (Kill-Switch):                                               │
│  ████████████████████████████████████████████████████████  99.9%      │
│  Blocked by Jaccard/Volume                                            │
│                                                                        │
│  Layer 2 (Git Saga):                                                  │
│  ████████████████████████████████████████████████████████  99.99%     │
│  Contained via ephemeral branch + auto-revert                         │
│                                                                        │
│  Layer 3 (Shadow Backup):                                             │
│  ██████████████████████████████████████████████████████████  100%     │
│  Recovered from shadow files                                          │
│                                                                        │
│  RESULT: 0 PERMANENT LOSSES                                           │
└────────────────────────────────────────────────────────────────────────┘

The Fararoni Kernel demonstrates that secure and efficient LLM integration in software development requires a hybrid architecture that combines:

1. Intelligent Routing: 60-70% of interactions are resolved in the deterministic zone (Levels 1-2), eliminating latency and hallucinations for operational tasks.
2. Defense in Depth: The remaining 30-40% passes through the Protection Triad, where each layer captures escapes from the previous one until reaching 0% permanent loss.
3. Small Model Adaptability: The text fallback (extractTextToolCalls) enables using 7B parameter models that don't properly handle the tool calling protocol, democratizing access to these capabilities.

The explicit separation between the deterministic zone and the stochastic zone is not just a performance optimization: it is a security principle. By making the LLM "never know" about trivial commands, we eliminate the widest attack surface. And by shielding the points where the LLM DOES operate, we guarantee that its stochastic nature cannot cause permanent damage.

• Cruz, E. (2026). Fararoni Ironclad: Deterministic Guardrails for Code. Technical Report v3.
• OWASP LLM Top 10 (2025). Security Risks in Large Language Model Applications.
• IEEE/ACM ICSE (2025). Proceedings on AI-Assisted Software Engineering.

Eber Cruz is a software engineer with a decade of experience designing backend infrastructure and distributed systems. This document reflects the design work behind C-FARARONI, an experimental ecosystem focused on technological sovereignty and secure execution of local AI models.

Repository: github.com/ebercruzf/fararoni-ecosystem
Notes and contact: ebercruz.com