Configuration

Hologram has no TOML config system. Configuration is done in code (backend selection, Witt level) and at build time via Cargo features. The content-addressed buffer pool is self-sizing — it bounds to the computation’s working set (the last two execution walks) with no configured cap.

Cargo Features

Every library crate is no_std + alloc by default and exposes a std feature for host builds.

Feature	Crate(s)	Default	Effect
std	all libs	✓	Standard library: file I/O, runtime SIMD detection, thread-local scratch, tracing
cpu	hologram-backend	✓	The native CPU kernel backend (CpuBackend)
parallel	hologram-backend, hologram-exec	—	Multi-core execution: a matmul dispatch fans its cache-oblivious recursion across an in-tree worker pool (host-only; the single-thread path is byte-identical)
wgpu	hologram-backend	—	The wgpu GPU backend (implies std)
metal	hologram-backend	—	The Apple Metal GPU backend (implies std, macOS)
tiered-exec	hologram-exec	—	PM_7 memory-affinity tier classification + observability
model-formats	hologram-archive	—	GGUF / ONNX UOR-ADDR realizations for model addressing
frontend-python	hologram-compiler, hologram-cli	—	Python AST source frontend for restricted Hologram builder functions (implies std)
frontend-rust	hologram-compiler, hologram-cli	—	Rust AST source frontend for restricted Hologram builder functions (implies std)
frontend-typescript	hologram-compiler, hologram-cli	—	TypeScript AST source frontend for restricted Hologram builder functions (implies std)
wasm	hologram-ffi	—	WebAssembly build of the C-ABI FFI (browser demo)

Enable features in Cargo.toml:

[dependencies]
hologram-backend = { git = "https://github.com/Hologram-Technologies/hologram", features = ["parallel"] }

Enable source frontend features on hologram-compiler when a build needs to parse host-language files:

[dependencies]
hologram-compiler = {
  git = "https://github.com/Hologram-Technologies/hologram",
  features = ["frontend-python", "frontend-typescript", "frontend-rust"],
}

For CLI development runs, enable the matching hologram-cli feature:

cargo run -p hologram-cli --features frontend-python -- compile \
  --source graph.py --graph encoder --output model.holo

no_std Targets

Every library crate is no_std + alloc by default. For no_std targets (wasm / embedded) disable default features on the library crates:

[dependencies]
hologram-backend = { ..., default-features = false }

Memory tiers (PM_7)

The tiered-exec feature enables PM_7 memory-affinity classification: at session load, every value is assigned a memory tier as a pure function of its quantum level (Witt bit-width) — CpuL1 (≤8-bit, 256-byte LUT), CpuL2 (9–16-bit, 128 KB LUT), CpuMain (17–24-bit), Device (≥25-bit, incl. f32). The classification is load-time only and adds zero per-execute overhead; InferenceSession::tier_report() exposes the per-value tiers for observability. The Q0/Q1 LUT acceleration (the 256-entry and [u16; 65536] tables) is the concrete realization of the CpuL1/CpuL2 tiers and is always on, independent of the feature. Device routing to a discrete accelerator is a future extension.

Compile-time configuration

Compilation is configured through the Compiler constructor — the target backend and the Witt level (the UOR-ADDR addressing granularity):

use hologram_compiler::{BackendKind, Compiler};
use prism::vocabulary::WittLevel;

let compiled = Compiler::new(graph, BackendKind::Cpu, WittLevel::new(32))
    .compile()
    .unwrap();
// compiled.archive: Vec<u8>

BackendKind selects the target backend (e.g. Cpu). WittLevel::new(32) is the conventional default.

External tensor roots

File-backed const_ref tensors are resolved and hash-checked at compile time. By default, relative paths resolve from the compiler process’ current directory and absolute paths are allowed. Set HOLOGRAM_EXTERNAL_TENSOR_ROOT to require every resolved external tensor path, relative or absolute, to canonicalize under that root:

HOLOGRAM_EXTERNAL_TENSOR_ROOT="$PWD/weights" hologram compile \
  --source graph.txt --output model.holo

Runtime sessions never reopen const_ref source paths; the validated bytes are already part of the compiled archive.

Runtime / session configuration

Execution is synchronous. A session is loaded from an archive against a backend, and the backend is parameterized by the buffer pool (BufferArena):

use hologram_backend::CpuBackend;
use hologram_exec::{BufferArena, InferenceSession, InputBuffer};

let mut session =
    InferenceSession::load(&archive, CpuBackend::<BufferArena>::new()).unwrap();
let outputs = session.execute(&inputs).unwrap();

BufferArena is the content-addressed buffer pool that backs intermediate values and pinned constants. Selecting a different Backend (CPU SIMD, or the optional wgpu / metal GPU backends) is how you change where kernels run.

WASM Build

# Build the no_std library stack for the browser
just wasm

# Or build the C-ABI FFI for the browser demo
cargo build -p hologram-ffi --target wasm32-unknown-unknown --features wasm

C Bindings

hologram-ffi exposes a C ABI. A session is referenced by an integer handle into a process-local table; functions return negative error codes on failure:

int len = hologram_compile_source(src, src_len, out, out_capacity);
int h   = hologram_session_load(archive, archive_len);
hologram_session_execute(h, /* … */);
hologram_session_close(h);

SDK bindings should read hologram_last_error_code() and hologram_last_error_message() after failures. Python and TypeScript map the stable FFI categories to typed errors such as ArchiveLoadError, ExternalTensorError, ExecutionError, AbiMismatchError, and InvalidArgumentError.