Backends and installation

The core R workflow needs no Python runtime. Capability inspection is offline and does not install anything. A capability probe is not model qualification.

hm_backend_capabilities()
#> $os
#> [1] "Linux"
#> 
#> $arch
#> [1] "x86_64"
#> 
#> $r_version
#> [1] "4.6.2"
#> 
#> $python
#> [1] "/usr/bin/python3"
#> 
#> $gpu_qualification
#> [1] "not_established"
#> 
#> $privileged_actions
#> [1] FALSE

The automatic metadata resolver currently admits Linux x86_64 with an explicit existing Python 3.11 or 3.12 and exactly uv 0.11.26. reference_cpu resolves NumPy 2.2.6, Torch 2.13.0 and setuptools 84.1.0. Resolution is an explicit network operation and is therefore omitted from offline builds. This setup route is not a blanket platform/model support claim.

The earlier Torch 2.6.0 generated profile is retired following the publisher’s checkpoint advisory. Automatic vllm_linux_cuda resolution is blocked pending a reviewed replacement for its vulnerable 0.11.0 profile; see the publisher’s video-processing advisory. Existing files are preserved, but those generated profiles cannot be installed or started again. Resolve a new CPU profile and review its artifacts/terms, or use a separately reviewed current custom manifest. Exact upstream/model/Linux qualification remains separate from these version and admission repairs.

# Opt in only with explicit executables and a new persistent external directory.
resolution <- hm_resolve_backend("reference_cpu",
  model_id = "reference:cnn1d",
  python = Sys.getenv("HYPERMODR_PYTHON"), uv = Sys.getenv("HYPERMODR_UV"),
  directory = Sys.getenv("HYPERMODR_RESOLUTION_DIR")
)
resolution$hard_gates

Inspect every artifact’s full license/notice text and exact identity before setting its reviewed flag. hm_admit_backend(resolution, reviewed_terms) creates an installation plan only after that review. Pip configuration files and inherited pip options do not redirect installation outside the owned environment. hm_backend_plan() also accepts an explicitly pinned custom profile. hm_install_backend(plan, accept_terms = TRUE) performs the separately requested installation into an external cache; hm_start_backend(), hm_backend_status() and hm_stop_backend() own the process lifecycle. hm_worker_request() uses bounded numeric interchange, never arbitrary Python deserialization.

A separately reviewed custom vLLM setup requires exact NVIDIA driver/device ABI admission and an exact local checkpoint manifest. hm_resolve_checkpoint() resolves a public immutable 40-character revision without downloading weights and rejects custom remote code; review checkpoint terms separately. Use hm_vllm_chat() only for a compatible served language/vision model, with explicit consent and disclosure for remote transmission. Native HSI architectures do not run through stock vLLM. hm_render_hsi() records the information lost in three-channel views; hm_prompt() binds prompt origins. Generated text remains auxiliary.

Install receipts, artifact hashes, exact versions and hm_check_backend() smoke/parity evidence must travel with a support claim. Offline misses, corrupt artifacts and unsupported platforms fail explicitly. Repeat installs verify integrity; interrupted staging and ownership locks are not silently stolen. No Windows, macOS, GPU or named upstream model qualification follows from this article. No installation is triggered by loading the package or opening the app.