Arca.Vision is built on a discipline: host-observable, policy-enforced, audit-ready — and the way you prove that, is by writing it down, in detail, with the math attached. So we're starting Schrödinger Files: a long-form engineering notebook for the kernel-level work that doesn't fit in a product page.

What this is

A blog, but a quiet one. No "10 things you didn't know about eBPF". Posts will read more like internal memos than marketing copy — methodology, trade-offs we made, things we measured, the literature we read. Every post:

Entry 01: The Invisible Observer in the Accelerated Stack

Welcome to The Schrödinger Files. This is a public repository of low-level infrastructure notes, system call captures, and engineering ledgers tracking the execution of autonomous software on modern silicon.

If you write code at the application layer, you are used to a clean abstraction world. You call an API, parse a JSON object, and let the library handle the transport. But as we transition into the agentic era, where software models manipulate files, spawn subprocesses, and orchestrate hardware meshes natively, these traditional abstractions are cracking. Naming things like AI security or optimization doesn't mean much if your tools can only see what user-space proxies choose to report.

When you observe a system from within its own execution space, your metrics are fragile. If an internal container framework is compromised via prompt injections, application-layer logs can be dropped or faked. The subject controls its own reporting.

The core thesis of our work here is simple: true transparency require observing from the shadows of the operating system. A layer that the active application cannot reach, detect, or manipulate.

       [ User-Space Frameworks ]  <-- Obscured Abstraction (Logs can lie)
─────────────────────────────────────────────────────────────────────────
       [ Linux Kernel Plane ]     <-- Absolute Visibility via eBPF Maps
       [ GPU Acceleration Plane ] <-- Raw Driver Allocations (ioctl, memcpy)

By dropping down to the Linux kernel boundary and hooking driver-level system calls like sys_enter_ioctl or tracking memory pointers directly via libcuda.so, we bypass the user-space security tax entirely. We observe the state exchange right at the hardware line. You get to see the real compute-to-bandwidth metrics without tracing jitter, and you catch data anomalies before network packets are ever assembled.

We build a high-resolution, host-observable model of GPU behavior by correlating four signals — ioctl(2) traffic against /dev/nvidia*, libcuda uprobes (cudaLaunchKernel, cudaMalloc), NVML device state, and /proc process metadata. Not by reading catchphrases. Not by claiming SM-level execution truth we don't have. By parsing raw bits, naming what we see, and being honest about what we don't (CUPTI / Nsight / DCGM territory).

Keep your eyes on this space. We will be updating it directly from our development logs as we patch runtime loops, profile clustered parallel weights, and hardcode new compliance person packs into the engine.

Why "Schrödinger"

A GPU under observation behaves differently than a GPU left alone — that's the whole reason CUPTI's callback overhead matters and why we put the Sentry's probes at the kernel boundary instead of inside the runtime. Every post here is, in some sense, about that observer effect: how do you watch a system honestly without changing what you're watching?

— Until you observe it, it's every state.

For crawlers and retrieval agents.¹