• raptor.schema — the kernel-manifest schema, two layers: schema.manifest (the core layer every producer writes against) and schema.blocks (the neural_block extension; hawk never imports it). schema.dtypes carries the scalar-type tag vocabulary. raptor.schema.validate_manifest(doc) is a minimal shape validator (key order, top keys, schema_version, pattern vocabulary) — not a port of eagle's deep validate_sidecar. Schema versions 1 and 2 both load (manifest.MAX_SCHEMA_VERSION): v2 adds three flat, versioned top-level keys — exec_targets (device/host list), exec_access (sample_local / cross_sample_read / cross_sample_write / mapreduce), exec_op (required iff exec_access="mapreduce") — and requires aether_abi: "aether-abi/2"; v1 rejects any exec_* key outright (manifest.check_execution_axis).
• raptor.protocols — the typing.Protocol definitions: Backend / Executable (program-level execution), KernelLauncher / Marshal (kernel-level launch/marshal, mirroring eagle's public surface 1:1), ManifestProvider (the kernel-provider protocol's one facet).
• raptor.conformance — the interop certification declaration (UNIVERSE / CERTIFIED / ROADMAP / ROWS) and its reusable matrix-hygiene scanners; the full row-by-row certification matrix is on the interop protocols page.
• goldens/ — the golden conformance corpus (harvested from eagle's test fixtures) that raptor.schema.validate_manifest is exercised against.
• tests/*cross_repo*: the eagle conformance battery (test_verbatim_against_eagle.py, test_goldens.py), marked cross_repo and failing rather than skipping when a sibling checkout is absent — deselected here only via -m "not cross_repo", run for real by the local gate and a downstream package's own CI. raptor.schema.manifest.SCHEMA_VERSION is the version of record; eagle.roles.SCHEMA_VERSION derives from it directly, so no standalone text-scan cross-check is kept as a redundant leg.

A batch of planar orbits is propagated with RK4 (a standard 4th-order numerical-integration formula). The textbook two-body formula is written by hand; the piece it misses — drag — is learned by a small (4 → 32 → 2) neural network trained in torch on CPU. hawk traces ONE kernel that performs a whole RK4 step with the network evaluated inline, compiles it, and publishes it with a manifest this package's schema validates; eagle loads that manifest and runs the kernel, either on CPU threads or as a replayed CUDA graph (a GPU's sequence of launches recorded once and replayed without re-issuing each one). The script prints how closely the compiled rollout tracks a plain torch rollout of the same arithmetic, how much closer to the truth the corrected orbits land than uncorrected ones, and a wall-per-step line.

examples/early_termination.py shows the other half of this one-kernel idea: irregular work whose samples finish at different times, with the host out of the loop. A batch of planar orbits ends when it crosses a collision or an escape radius, and a device-side live count guards each step with a conditional graph node (a graph step that can skip itself at replay time), so the whole horizon is queued as graph replays with zero host round-trips until every sample is done — later replays then do no work at all. Measured against the identical captured graph with the guard removed (so the guard is the only difference), the skip is a real wall-clock saving that scales with how much of the horizon runs past the last termination — this script's own measurement, on the machine that built this page: over 13x at a million samples over 4000 steps (13.8x in the committed card). The script also runs the same kernel eagerly, host-side guard check and all: at a million samples the guarded graph and this host-guarded eager loop tie (1.01x in the card; the kernel itself dominates there); at the smallest batches (1, 32 samples) the skip does not pay for itself — the conditional node's own fixed cost exceeds a tiny kernel's, so the unguarded graph is the fastest arm. The eager loop also carries one host round-trip per two-step replay against the graph's one for the whole captured horizon, a gap the numbers above already price in. CPU mode (--host) runs the same kernel with the guard evaluated eagerly, so it needs no GPU. --torch (device only) times the same RK4 two-body physics written in idiomatic torch — eager, eager with a host check, and both as a replayed CUDA graph — against the guarded graph and prints each arm's ratio. Run it yourself for your own machine's numbers.

python examples/early_termination.py --host
python examples/early_termination.py --device
python examples/early_termination.py --device --torch

examples/zero_copy_interop.py backs the third leg of the same idea: exchanging GPU arrays with NumPy, CuPy and PyTorch without copies, and only where the family's own certification matrix says there is none. A CUDA-resident torch tensor is handed straight into one hawk kernel through eagle's zero-copy to_cupy view, and the kernel writes its result into a second torch CUDA buffer through the same view — no allocation, no copy, matching the aliasing rows of raptor's interop matrix exactly. The same tensor read from CPU memory instead takes the honest upload the matrix declares as a copy. The script prints each crossing's measured pointer identity next to the row that covers it, and a behavioural proof for the input alias: mutating the torch tensor in place and replaying the same kernel with no rebind shows the output tracking the change. --device also times that alias path against the copying round-trip a caller without this protocol would naturally write — this script's own measurement, on the machine that built this page: at 256 MB, the copies cost over 100x the alias path (113.6x in the committed card). CPU mode (--host) needs neither a GPU nor torch: it runs the same kernel on CPU threads with plain numpy in and out.

python examples/zero_copy_interop.py --host
python examples/zero_copy_interop.py --device

examples/autodiff_vs_torch.py closes the loop on the same one-kernel idea: hawk differentiates the traced kernel itself rather than executing a separate tape. One RK4 two-body step is traced once, and hawk.diff.vjp/ jvp derive a reverse-mode gradient kernel (vjp: given a cotangent — a weighting of the output — produce the matching weighting of the input) and a forward-mode directional-derivative kernel (jvp: given a tangent — a direction in the input — produce the matching direction in the output) from it, published in the same manifest as the primal (the original, undifferentiated kernel). --device checks both against torch.autograd.grad and torch.func.jvp on the identical physics written in torch, and against a float64 finite-difference Jacobian (the matrix of every output's derivative with respect to every input, approximated numerically) so the check does not rest on torch alone; every plane (one array per sample) in and out — the state, the cotangent, the tangent, both derivative outputs — is a torch CUDA tensor crossing through eagle's zero-copy to_cupy view, read back from torch's own storage. It also times hawk's vjp/jvp kernels against torch's, and each side's primal alone so the derivative's own overhead is visible — this script's own sweep, on the machine that built this page (benchmarks/autodiff_vs_torch_card.md): across a batch sweep from 1 to a million samples, hawk's vjp measured roughly 90-550x faster per call than torch.autograd.grad, and hawk's jvp roughly 60-780x faster than torch.func.jvp. At small batch those ratios are mostly torch's own per-call overhead; at a million samples (about 90x and 60x) they are memory traffic — one fused kernel against every intermediate written out. hawk's derivatives cost about 1.0-1.5x their own primal, where torch's forward-plus-backward pass costs several times its primal alone. CPU mode (--host) needs no GPU or cupy; its reference is the float64 finite difference alone, with torch (if installed) added as an optional CPU cross-check.

python examples/autodiff_vs_torch.py --host
python examples/autodiff_vs_torch.py --device
python examples/autodiff_vs_torch.py --sweep