# The Three-Way Behavioral Oracle (Katra3D §26)
Where possible, Katra3D compares:
```text
Native Windows vs Proton/Wine/vkd3d vs Katra3D
```
capturing: HRESULT, NTSTATUS, GetLastError, output data, COM identity,
resource state, fence values, ordering, side effects, timing constraints,
GPU output, and filesystem behavior.
Katra3D must preserve externally visible behavior even when its
architecture differs radically.
## Mechanism
* **Shadow execution** (`KATRA_MODE=shadow`, §19): a native replacement
observes or independently models behavior without changing the game's
result. Examples already in the tree:
* KatraFlow: predict next I/O, compare against actual (`ShadowTracker`);
* D3D12 dispatch: `ShadowProbe` records what Katra *would* do vs. the
vkd3d-proton oracle;
* scheduler: `SchedulePlan.decisions` record the proposed order vs. the
executed order.
* **Differential comparison**: `katra-replay compare` quantifies
structural and causal equivalence between two traces (e.g. baseline vs.
candidate).
* **Courts**: falsifiable invariants with recorded falsifiers
(`katra-courts`, `courts/`).
## Oracle sources
Wine, Proton, vkd3d-proton, DXVK, NTSYNC, Vulkan, Mesa, and the kernel are
treated as *behavioral oracles and compatibility archives* — never as
architectural templates. If Katra discovers a generally useful fix that
belongs upstream, it is isolated, documented with evidence, made
independently reviewable, and contributed where policy permits (§47).