Hello, hn
I failed many times when trying to write in my diary every day. So, I decided to tie the timing of my entries not to my own will, but to physical events that are bound to happen.
11 karma · joined December 28, 2025
## The Heart of Gatekeeper: "6-Axis Three-Dimensional Cross Structure (JCross 6-Axis IR)"
Gatekeeper is the "absolute gatekeeper" standing between the user's local environment and the external cloud LLM. Its core technology is the metamodel *"JCross IR (Intermediate Representation)"*, which reinterprets source code not merely as "text," but as a "spatial structure."
JCross IR decomposes source code into the following six dimensions (axes):
| Axis | Name | Role/Content | | :--- | :--- | :--- | | *X-axis* | *Control Flow* | Axis of time and sequence. if branches, loops, exceptions, etc. | | *Y-axis* | *Data Flow* | Axis of dependency and propagation. Variable assignment, argument passing, etc. | | *Z-axis* | *Type Constraints* | Boundary axis. Classes, type definitions, generics, etc. | | *W-axis* | *Memory & Lifecycle* | Lifespan axis. Scope lifespan, memory allocation/deallocation, etc. | | *V-axis* | *Scope & Hierarchy* | Inclusion axis. Modules, class nesting, etc. | | *U-axis* | *Semantics & Meaning* | * Most Important* Intent and concrete value axis. Specific variable names, function names, strings, etc. |
### Absolute Security through Physical Extraction of the "U-axis"
Simply encrypting variables uniformly prevents LLM from correctly interpreting even the logical structure of the code (loop scope and variable scope).
Therefore, Gatekeeper uses a rule-based parser to analyze the AST (Abstract Syntax Tree) and physically extracts only the "U-axis (semantics)" from this six-axis cross, isolating (masking) it in a local vault (JCrossIRVault). Only the "pure logic and structural framework" consisting of the remaining five axes (X, Y, Z, W, V) is sent to the external cloud LLM.
### Actual Transformation Image (Before / After)
Let's look at how the code is specifically hidden.
*[Before] Raw Source Code (as it is on the user's machine)* ```swift func calculateTax(price: Double) -> Double { let taxRate = 1.21 return round(price * taxRate, 2) }
[After] Masked JCross IR (as it is sent to Cloud LLM) When sent to LLM, business logic and sensitive information (U axis) are replaced with unique hash tokens, but the *topology (X/Y/Z/V/W axes)* where "function arguments are multiplied and returned as a value" is completely maintained.
func FUNC_0xA1B2(VAR_0x3C4: TYPE_DOUBLE) -> TYPE_DOUBLE { let VAR_0x9D5 = CONST_0xF1 return CALL_0xE5A(VAR_0x3C4 * VAR_0x9D5, CONST_0x02) } LLM looks at this symbolized structure puzzle, understands it at the structure level, and returns a patch. Finally, Verantyx restores the original complete code by reinjecting the U axis from the local Vault. Overall Flow: From Rule-Based Analysis to Inverse Transform This "extract" to "restore" pipeline is executed by robust rule-based processing, which does not tolerate inference errors. graph TD A[Raw Source Code] -->|1. AST Analysis| B[Rule-Based 6-Axis Parser] B -->|2. 6-Axis Decomposition| C{Gatekeeper Engine}
C -->|3. U-Axis Isolation| D[(Local Vault<br>JCrossIR Vault)] C -->|4. Extraction of Remaining 5 Axis| E[Masked IR<br>FUNC_0x...]
E -->|5. Submission| F((Cloud LLM<br>Claude / GPT-4))
F -->|6. Structural Inference| G[GraphPatch JSON<br>Structural Patch] G -->|7. Patch Application| H{Reverse Transpilation Engine<br>Reverse Transpilation}
D -->|8. U-Axis Reinjection| H H -->|9. Restoration Complete| I[Modified Source Code]
I’m a student developer building Verantyx, a native macOS IDE solving a core dilemma in AI coding: We need the reasoning power of frontier models like Claude 4.7 Opus, but cannot legally or ethically leak proprietary source code, hardcoded secrets, or core business logic to their APIs.
With the industry worried about losing "tacit knowledge" to AI, I built an architecture where the human retains ultimate control over semantics, while the AI is relegated strictly to structural logic patching.
To achieve this, I built the "Gatekeeper" architecture. Before code leaves your local Apple Silicon machine, a Rust core parses the AST and converts it into "JCross IR"—a custom intermediate topology. It deterministically masks high-value identifiers (e.g., calculateTax() becomes [Symbol_A]()) while preserving structural logic and control flow.
The Cloud LLM receives this obfuscated puzzle, writes a patch, and returns it. The local Rust vault then maps the IR patch back to your original source code.
The Tech Stack & Architecture
- Core (Rust): Handles the zero-copy memory vault, deterministic JCross IR generation, and AST parsing. The mapping dictionary is held strictly in local memory and never leaves the machine.
- Frontend (Swift): Native macOS UI. Achieves 0-latency state sync (a 1-frame toggle response) between "Raw Code View" and "AI's JCross IR View" without heavy disk I/O.
- The VS Code Bridge: To support LSPs without Electron's memory bloat, I built a background Node.js Extension Host communicating via JSON-RPC. Managing state synchronization between the Swift UI, the Rust Vault, and the Node.js host to prevent race conditions during reverse-compilation was an absolute nightmare.
The Gatekeeper Flow
1. Request: User prompts the Swift UI for a refactor.
2. Obfuscation: Rust converts the file to JCross IR, locking the mapping dictionary in local memory.
3. Transmission: Swift sends only the JCross IR to the Cloud LLM.
4. Reasoning: The LLM processes the obfuscated topology and returns an IR patch.
5. Restoration: Rust uses the local dictionary to reverse-compile the IR patch back into raw code.
6. Approval: Swift presents a Diff UI to the user for final approval.
Honest Trade-offs & Limitations
- Semantic Loss Penalty: Blinding the AI to domain-specific context (e.g., it doesn't know [Symbol_A] means "DB Connection String") occasionally leads to syntactically correct but logically flawed code.
- AST Topology Destruction: This is the most critical issue. When given complex instructions, frontier models sometimes hallucinate and destroy the AST topology of the obfuscated IR. When the structure is broken, the Rust vault cannot match it to the dictionary, causing reverse-compilation to fail and blocking the write.
- API Cost Overhead: Processing obfuscated IR requires deeper reasoning steps and more tokens.
- Lack of Quantitative Audits: As an independent project, enterprise-grade security audits to quantify the exact "leakage reduction rate" have not yet been performed.
I built this from scratch by vibe-coding alongside AI agents. I’d love to hear your thoughts on this approach to semantic leakage and AST obfuscation.
Body: Following up on my previous post (where I was at 18.1%), I’ve just reached 22.7% (227/1000) on the ARC-AGI-2 public evaluation set.
I want to address the skepticism regarding my development speed. As an undergraduate student in Japan, I have limited manual coding time. To overcome this, I’ve established a "Human-Architect / AI-Builder" research loop.
How the 24/7 loop works:
Human (Me): I analyze failed tasks to identify underlying geometric patterns and design new DSL primitives (e.g., the new gravity_solver and cross3d_geometry in v62).
AI Agent (OpenClaw/Claude Code): Based on my architectural design, the agent scaffolds the implementation, performs rigorous regression testing across all 1,000 tasks, and refines the code for performance.
This synergy allows for a high-frequency commit cycle that a single developer could never achieve alone, while ensuring the inference engine remains 100% symbolic and deterministic. At test-time, there are zero LLM calls; it's pure structural reasoning.
V62 Key Updates:
Gravity Solver: 4 distinct strategies for object sliding/gravity-based transformations.
Cross3D Geometry Engine: Improved handling of 3D-projected cross structures.
Score: 22.7% (monotonically increasing from 20.1% and 22.4% earlier this week).
I believe this hybrid development model—where human intuition drives logic and AI agents drive implementation—is the fastest path to 80%+ on the "Humanity's Last Exam".
I'm eager to hear your thoughts on this "System 2" approach and the role of AI agents in building symbolic AI.
GitHub: https://github.com/Ag3497120/verantyx-v6 Project Site: https://verantyx.ai
You’re right to be skeptical of the speed, and I realize I was incomplete in describing my process. I should have been more transparent: I am using Claude Code as a "pair-programmer" to implement and review the logic I design.
While the Verantyx engine itself remains a 100% static, symbolic solver at test-time (no LLM calls during inference), the rapid score jumps from 20.1% to 22.4% are indeed accelerated by an AI-assisted workflow.
My role is to identify the geometric pattern in the failed tasks and design the DSL primitive (the "what"). I then use Claude Code to scaffold the implementation, check for regressions across the 1,000 tasks, and refine the code (the "how").
This is why I can commit 30-80 lines of verified geometric logic in minutes rather than hours. The "thinking" and the "logic design" are human-led, but the "implementation" is AI-augmented.
My apologies if my previous comments made it sound like I was manually typing every single one of those 26K lines without help. In 2026, I believe this "Human-Architect / AI-Builder" model is the most effective way to tackle benchmarks like ARC.
I’d love to hear your thoughts on this hybrid approach to symbolic AI development.
You said the SotA is models generating code at test-time, and you're correct. Systems like o3 synthesize Python programs per-task, execute them, and check outputs. That's a legitimate program synthesis approach.
Here's where Verantyx differs structurally:
*The DSL is fixed before test-time.* When Verantyx encounters a new task, it doesn't generate arbitrary Python. It searches over a closed vocabulary of ~60 typed primitives (`apply_symmetrize_4fold`, `self_tile_uniform`, `midpoint_cross`, etc.) and composes them. The search space is finite and enumerable. An LLM generating code has access to the full expressiveness of Python—mine doesn't.
*Here's the concrete proof that this isn't prompt-engineering:*
While we've been having this discussion, the solver went from 20.1% to *22.2%* (222/1000 tasks). That's +21 tasks in under 48 hours. Each new task required identifying a specific geometric pattern in the failure set, designing a new primitive function, implementing it, verifying it produces zero regressions on all 1,000 tasks, and committing. The commit log tells this story:
- `v55`: `panel_compact` — compress grid panels along separator lines - `v56`: `invert_recolor` — swap foreground/background with learned color mapping - `v57`: `midpoint_cross` + `symmetrize_4fold` + `1x1_feature_rule` (+5 tasks) - `v58`: `binary_shape` lookup + `odd_one_out` extraction (+2) - `v59`: `self_tile_uniform` + `self_tile_min_color` + `color_count_upscale` (+4)
Each of these is a 30-80 line Python function with explicit geometric semantics. You can read any one of them in `arc/cross_universe_3d.py` and immediately understand what spatial transformation it encodes. An LLM prompt-tuning loop cannot produce this kind of monotonic, regression-free score progression on a combinatorial benchmark—you'd see random fluctuations and regressions, not a clean staircase.
*The uncomfortable reality for "just use an LLM" approaches:*
My remaining ~778 unsolved tasks each require a new primitive that encodes a geometric insight no existing primitive covers. Each one I add solves 1-3 tasks. This is the grind of actual program synthesis research—expanding a formal language one operator at a time. It's closer to compiler design than machine learning.
I'd genuinely welcome a technical critique of the architecture. The code is right there: [cross_universe_3d.py](https://github.com/Ag3497120/verantyx-v6/blob/main/arc/cross...) — 1,200 lines, zero imports from any ML library.
1. The Inference Engine is 100% Deterministic: The "solver" is a standalone Python program (26K lines + NumPy). At runtime, it has zero neural dependencies. It doesn't call an LLM, it doesn't load weights, and it doesn't "hallucinate." It performs a combinatorial search over a formal Domain Specific Language (DSL). You could run this on a legacy machine with no internet connection. This is fundamentally different from o1/o3 or Grok-Thinking, where the model is the solver at test-time.
2. The "Novel Human Input" is the DSL Design: Using an LLM to help write Python boilerplate is trivial. Using an LLM to design a 7-phase symbolic pipeline that solves ARC is currently impossible. My core contributions that an LLM could not "reason" out are:
The Cross DSL: The insight that ~57% of ARC transforms can be modeled by local 5-cell Von Neumann neighborhoods.
Iterative Residual Learning: A gradient-free strategy where the system synthesizes a transform, calculates the residual error on the grid, and iteratively synthesizes "correction" programs.
Pruning & Verification: Implementing a formal verification loop where every candidate solution is checked against the 3-5 training examples before being proposed.
3. Scaling through Logic, not Compute: While the industry spends millions on "Test-time Compute" (GPU-heavy CoT), Verantyx achieves 18.1% (and now 20% in v6) using Symbolic Synthesis on a single CPU. The 208 commits in the repo represent 208 iterations of staring at grid failures and manually expanding the primitive vocabulary to cover topological edge cases that LLMs consistently miss.
If using Copilot to speed up the implementation of a deterministic search algorithm invalidates the algorithm, then we’d have to invalidate most modern OS kernels or compilers written today. The "intelligence" isn't in the typing; it's in the program synthesis architecture that does what pure LLM inference cannot.
I'd encourage you to check the source—it's just pure, brute-force symbolic logic: https://github.com/Ag3497120/verantyx-v6
The system: • runs locally • uses small, explicit rule sets • falls back to LLMs only when structure is missing • marks all mined output as provisional
The long-term idea is that as the DB grows, dependence on large models shrinks.
This is not about outperforming GPT-4-class models. It’s about making reasoning transparent, testable, and cheap enough for individuals.
I've spent the last year building AXIS, a system that fundamentally reframes how we use language models in reasoning tasks.
The core insight: LLMs are unreliable as reasoners, but powerful as knowledge extractors. So why not separate these concerns?
[Current Problem]
Standard LLM reasoning suffers from "stochastic fog"—the probabilistic nature of token selection causes context drift and hallucinations. The model becomes a single point of failure.
[The AXIS Approach]
Instead of: LLM → Output
AXIS does: Input → [Phase 1: Mining] → Lattice Simulation → [Phase 2: Mining] → Verified Output
Key features:
1. Rejection Loop Every LLM output is intercepted by a Verifier (SymPy/NumPy). If it contradicts mathematical or physical constraints, it's rejected. The LLM is rebooted and asked again. This repeats until consistency.
2. Physical Context Purge After each trial: torch.mps.empty_cache() + gc.collect() This severs the "contextual drift" that fuels hallucinations. Each trial is statistically independent.
3. Deterministic Verification The final output is assembled, not generated. Raw verified data → hard-coded templates → no AI prose = 0% hallucination.
4. 5D Semantic Lattice (optional, but powerful) Each logical node occupies a 5D space: - s1: Physical Actuality (does data align with constants?) - s2: Logical Necessity (can it be derived from axioms?) - s3: Contextual Consistency (matches the context stack?) - s4: Ethics (passes safety guardrails?) - s5: Empirical History (aligns with past confirmations?)
[Results]
On the Complex Plane Coefficient Problem: - Standard GPT-4: Generates plausible but incorrect coefficients - AXIS + Gemma-2-2b: Rejects bad answers 4 times, converges to a=0, b=0, c=0 - Reproducibility: 100% (10 trials, identical output) - No GPU needed; runs on Mac
[What I'm Looking For]
1. Is the 5D Lattice approach sound? Is dimensionality orthogonal? 2. What's the computational overhead of repeated rejection? 3. Are there existing systems that do something similar? 4. What are the failure cases?
Code and minimal examples are in the repo. Happy to discuss.
HuggingFace:https://huggingface.co/kofdai/AXIS-Sovereign-Logic-Engine
Looking forward to feedback.