HB
KYNETRA FOUNDRY · WIKI
Edition 2026.1 · Internal Reference
Hyperbridge Digital · Model Foundry

KYNETRA FOUNDRY

Fifty owned primitives, frameworks, and architectures for training, creating, and fine-tuning frontier models — Hyperbridge's in-house counterpart to the open LoRA / QLoRA / RLHF ecosystem. Every name here is coined and owned; every mechanism underneath is real engineering.

Owned & operated by Hyperbridge Digital · The forge for sovereign models — train, create, fine-tune.

50
Components
10
Pillars
18
Architectures
22
Frameworks
100%
Hyperbridge-owned
Terminology Framework Architecture
No components match — try another term.
01

Adaptation & PEFT

Bend a frozen giant to your domain without retraining it — low-rank grafts, quantized adapters, and surgical weight edits that ship in megabytes, not gigabytes.

5 components
Framework 01 · Adaptation & PEFT
Rank: 4-64Trainable: ~0.1-1%Latency: +0ms (merged)

RankWeave

Inject a sovereign low-rank delta into frozen weights — train 0.2% of params, keep all the capability.

Grounded inLow-rank adaptation (LoRA): freezing base weights and learning two low-rank matrices whose product is added to each target weight matrix.

RankWeave is the Foundry's core low-rank adaptation recipe: it freezes every base-model weight and learns a slim, additive delta woven across the attention and MLP projections. It exists so a single backbone can be specialized to many domains at a fraction of the compute and storage of full fine-tuning.

How it works

For each targeted weight matrix W (typically the q/k/v/o and MLP up/down projections), RankWeave freezes W and learns the update as a low-rank product BA, where A is r×k and B is d×r with rank r far smaller than the matrix dimensions. The forward pass computes h = Wx + (alpha/r)·BAx, so only A and B receive gradients. A is initialized from a small random distribution and B is zeroed, making the initial delta exactly zero. Because r is tiny, trainable parameters drop by orders of magnitude and optimizer state shrinks proportionally. At inference the BA product can be folded back into W, adding zero latency.

Components
  • A/B factor matrices (down-project / up-project)
  • Rank r — the weave width
  • Alpha scaling (alpha/r effective gain)
  • Target-module selector (attn + MLP projections)
  • Adapter dropout for regularization
Use when

Reach for RankWeave when you need to specialize a frozen backbone to a domain or task cheaply and want a small, swappable delta rather than a full model copy. Ideal when many tasks must share one base in memory.

Framework 01 · Adaptation & PEFT
Bits: 4 (NF-style)VRAM: -65% vs bf16Base: frozen + quantized

NibbleGraft

Graft trainable adapters onto a 4-bit frozen base — fine-tune giant models on a single GPU.

Grounded inQLoRA: 4-bit NormalFloat (NF4) quantization of the frozen base with double quantization and paged optimizers, while training LoRA adapters in higher precision.

NibbleGraft fuses aggressive 4-bit quantization of the frozen backbone with full-precision low-rank adapters grafted on top. It exists to make fine-tuning of very large models feasible on commodity, single-GPU hardware without sacrificing adapter quality.

How it works

The base weights are quantized to a 4-bit NormalFloat representation — an information-theoretically motivated grid for zero-centered, normally distributed weights — and stored block-wise. A second 'double quantization' pass compresses the per-block quantization constants themselves, shaving additional bytes. During the forward and backward pass, 4-bit blocks are dequantized on the fly to a compute dtype (bf16), but gradients flow only into the higher-precision low-rank adapters; the base stays frozen and quantized. Paged optimizer states spill to CPU memory to absorb gradient-checkpointing spikes without OOM. The result: training-time memory dominated by adapters, not the backbone.

Components
  • 4-bit NormalFloat (NF-style) weight grid
  • Double quantization of scale constants
  • Block-wise quantization layout
  • Paged optimizer (CPU offload on spikes)
  • bf16 dequant compute path
Use when

Use NibbleGraft when the base model won't fit in GPU memory at 16-bit but you still need to fine-tune it — multi-billion-parameter backbones on a single 24-48GB card.

Architecture 01 · Adaptation & PEFT
Decomp: magnitude + directionRank: 4-32Accuracy: ~full-FT parity

MagnitudeForge

Decompose each weight into magnitude and direction — tune both, fine-tune like full training.

Grounded inDoRA (Weight-Decomposed Low-Rank Adaptation): splitting pretrained weights into a magnitude vector and a directional matrix, applying low-rank updates to direction while learning magnitude separately.

MagnitudeForge is a weight-decomposed adapter architecture that separates every pretrained weight column into a scalar magnitude and a unit direction, then adapts each part on its own track. It exists to close the accuracy gap between low-rank adapters and full fine-tuning by giving magnitude its own degrees of freedom.

How it works

Each pretrained weight matrix W is reparameterized as W = m · (V/||V||), where m is a per-column magnitude vector and V/||V|| is the column-normalized direction. MagnitudeForge freezes the directional base but adds a low-rank delta BA to the direction component before re-normalizing, and learns the magnitude vector m directly as a trainable parameter. Gradients thus update direction (via the rank-r factors) and magnitude (via m) independently, mirroring patterns observed in full fine-tuning where the two move differently. This decoupling improves stability at low ranks and typically beats plain low-rank weaving at equal parameter budgets, with the delta still mergeable into W at inference.

Components
  • Per-column magnitude vector m (trainable)
  • Column-normalized directional base (frozen)
  • Low-rank directional delta (BA)
  • Re-normalization step before scaling
  • Merge-back to W for zero-cost inference
Use when

Choose MagnitudeForge when low-rank weaving underperforms full fine-tuning on a hard task and you can afford a few extra magnitude params to recover accuracy, especially at very low rank.

Architecture 01 · Adaptation & PEFT
Weights: 0 editedParams: ~0.1-3%Scope: all layers

PrefixLattice

Steer a frozen model with learned virtual tokens prepended to every attention layer — no weights touched.

Grounded inPrefix-tuning / P-tuning v2: learning continuous key-value prefix vectors prepended at each transformer layer while the base model stays entirely frozen.

PrefixLattice is a deep prompt architecture that prepends a lattice of trainable continuous vectors to the key and value sequences at every attention layer of a frozen model. It exists to condition large models on a task using zero weight edits — only a compact set of virtual-token activations is learned.

How it works

For each transformer layer, PrefixLattice introduces a small set of learnable prefix vectors that are concatenated to the keys and values of self-attention, so every real token attends back to these virtual tokens. The base weights are 100% frozen; gradients flow only into the prefix table, which is often produced by a small reparameterization MLP during training for stability and then collapsed to raw vectors for inference. Because prefixes act at every layer (not just the embedding input), they exert deep, distributed control over the residual stream. Storage per task is just the prefix tensors, making it extremely light and trivially hot-swappable at serving time.

Components
  • Per-layer key/value prefix vectors
  • Prefix length (number of virtual tokens)
  • Reparameterization MLP (train-time stabilizer)
  • Frozen base attention stack
  • Per-task prefix table (swappable)
Use when

Use PrefixLattice when you must keep the base model byte-for-byte frozen (shared/serving constraints) and want deep, multi-layer task control with a tiny per-task footprint.

Terminology 01 · Adaptation & PEFT
Overhead: +0ms post-foldMerge: N adapters → 1Conflict: sign-aware

GraftFold

The math of folding trained adapters back into base weights — and weighted-merging many into one.

Grounded inAdapter merging: folding LoRA deltas into base weights (W' = W + BA) and weight-space merging of multiple adapters (e.g., linear/TIES-style sign-aware averaging) into a single checkpoint.

GraftFold is the Foundry's primitive for collapsing trained adapters back into base weights and for composing multiple adapters into one unified set. It exists to eliminate adapter-runtime overhead and to fuse several specializations into a single deployable model.

How it works

For a single adapter, GraftFold computes the effective delta (alpha/r)·BA and adds it directly to the frozen base: W' = W + (alpha/r)·BA, yielding a standard dense matrix with no extra inference-time ops or memory. For composition, multiple adapter deltas are merged in weight space — the simplest case is a scaled linear sum (sum of w_i·delta_i), while sign-aware schemes first trim low-magnitude entries, resolve per-parameter sign conflicts by majority, and average only the agreeing deltas to curb destructive interference. Merge weights tune the influence of each skill. The folded result is a single checkpoint that behaves as if the adapters were always part of the base.

Components
  • Single-adapter fold: W' = W + (alpha/r)·BA
  • Linear weighted merge of multiple deltas
  • Sign-aware trim + conflict resolution
  • Per-adapter merge weights
  • Output: one dense base checkpoint
Use when

Reach for GraftFold when you want to ship adapter gains with zero runtime overhead, or to combine several task adapters into one model without retraining from scratch.

02

Quantization & Compression

Drive weights and KV-cache to 4 bits and below without losing the plot. Post-training quant, pruning, and quantization-aware training.

5 components
Framework 02 · Quantization & Compression
Bits: 4 (NF-style)Block: 64Levels: 16

Nanocrush NF4

4-bit information-theoretic weight casting that holds accuracy where naive INT4 collapses.

Grounded in4-bit NormalFloat (NF4) quantization as used in QLoRA — an information-theoretically optimal datatype for normally-distributed weights, applied blockwise.

Nanocrush NF4 is Foundry's weight-casting datatype that maps frozen FP16/BF16 weights onto a 4-bit grid whose quantization levels are spaced to be optimal for zero-mean Gaussian-distributed weights. It exists so a model can be loaded and fine-tuned at a quarter of its native footprint with negligible quality loss versus full precision.

How it works

Weights are split into fixed-size blocks (typically 64 values). Within each block, the tensor is normalized by its absolute maximum so values fall in [-1, 1], then mapped to one of 16 quantile levels derived from the standard normal distribution's quantiles — so each 4-bit code carries roughly equal probability mass, minimizing expected error for Gaussian weights. The per-block absmax scale is stored alongside the codes. At compute time, weights are dequantized on the fly back to BF16 for the matmul; quantized weights stay frozen while only adapters train. NF4 is symmetric and zero-centered, so no zero-point is needed, unlike affine INT4.

Components
  • Blockwise absmax normalization (block size 64)
  • 16-level normal-quantile codebook
  • Per-block BF16 scale storage
  • On-the-fly dequant for matmul
  • Symmetric, zero-point-free mapping
Use when

Reach for Nanocrush NF4 when you must fit a large frozen base model on a single GPU for adapter fine-tuning and INT4 round-to-nearest is degrading accuracy too much.

Terminology 02 · Quantization & Compression
Overhead: 0.5→0.127 b/paramMeta-block: 256Scale bits: 8

Densecore Recompress

Quantize the quantization metadata itself to claw back the last fraction of a bit.

Grounded inDouble quantization (DQ) from QLoRA — quantizing the per-block quantization constants (scales) to shave additional memory beyond first-pass weight quantization.

Densecore Recompress is the second-order compression primitive that quantizes the per-block scale constants produced during weight quantization. It exists because, at small block sizes, the FP32 scales themselves become a non-trivial slice of the memory budget that can be compressed almost for free.

How it works

First-pass blockwise quantization emits one FP32 absmax scale per block; with 64-value blocks that costs about 0.5 bits per weight. Densecore Recompress treats those scales as a new tensor, groups them into larger meta-blocks (e.g. 256 scales), and quantizes them to 8-bit floats with a single FP32 meta-scale per meta-block. The first scale's mean is subtracted to center the distribution before the 8-bit cast, improving fidelity. This drops the scale overhead from roughly 0.5 to about 0.127 bits per parameter. At inference, scales are dequantized to FP32 first, then used to dequantize the underlying weights — a two-stage unpack adding minimal compute.

Components
  • First-pass per-block FP32 scales
  • Meta-blocking of scales (e.g. 256)
  • 8-bit float scale cast
  • Single FP32 meta-scale per meta-block
  • Two-stage unpack at inference
Use when

Use Densecore Recompress whenever you run small quantization blocks for accuracy and need to recover the scale overhead to fit a tighter VRAM envelope.

Framework 02 · Quantization & Compression
Bits: 3-4Method: PTQCalib: ~128-512 samples

Errorforge Calibrate

Post-training low-bit quant that compensates each weight against its neighbors' error.

Grounded inGPTQ-style second-order post-training quantization: layer-wise error-compensating quantization using an approximate inverse-Hessian (OBQ/OBS lineage), with AWQ-style activation-aware scaling as an option.

Errorforge Calibrate is the data-calibrated, training-free quantizer that compresses an already-trained model to 3–4 bits while compensating for quantization error within each layer. It exists to deliver near-FP16 accuracy at low bit-widths without any gradient updates, using only a small calibration set.

How it works

For each linear layer, a few hundred calibration samples produce input activations, from which the Hessian H = 2·XXᵀ of the layer's reconstruction loss is estimated. Weights are quantized column-by-column; after each column is rounded, the residual error is propagated to the not-yet-quantized columns using the inverse Hessian, so later weights absorb earlier rounding error and the layer output stays close to original. A dampening term stabilizes the Cholesky-based inverse. Optionally, salient weight channels — flagged by large activation magnitudes — are scaled up before quantization and rescaled after, protecting the channels that matter most to the output.

Components
  • Calibration-set activation capture
  • Approximate inverse-Hessian (XXᵀ)
  • Column-wise error propagation
  • Cholesky dampening for stability
  • Activation-aware salient-channel scaling
Use when

Reach for Errorforge Calibrate to ship a pretrained model at 3–4 bits for cheap inference when you can't or won't retrain and need accuracy well above naive round-to-nearest.

Architecture 02 · Quantization & Compression
Pattern: 2:4Speedup: ~2xIndex: 2 b/group

Latticeprune Sparsefold

Hardware-aligned 2:4 structured sparsity that physically halves the weight matrix.

Grounded inSemi-structured 2:4 (fine-grained N:M) pruning compatible with sparse-tensor-core acceleration, plus magnitude-based unstructured pruning as the fallback regime.

Latticeprune Sparsefold is the structural sparsity design that removes weights in a fixed 2-of-every-4 pattern so the survivors compress into a hardware-acceleratable sparse layout. It exists to turn pruning from a paper-only FLOP reduction into real wall-clock speedup on sparse-capable accelerators.

How it works

Within each contiguous group of four weights along the input dimension, the two smallest-magnitude values are zeroed, enforcing a strict 2:4 pattern. The kept weights are packed into a compressed array plus a 2-bit-per-group index map recording which lanes survived; sparse tensor cores read this layout to skip the pruned multiplies, giving up to ~2x matmul throughput. To recover accuracy the pruned mask is held fixed and the network is briefly fine-tuned so remaining weights re-adapt. For irregular budgets it degrades gracefully to global magnitude pruning, ranking all weights and removing a target percentile, trading hardware speedup for higher achievable sparsity.

Components
  • 2:4 group-wise magnitude masking
  • Compressed values + index map
  • Sparse-tensor-core packed layout
  • Mask-fixed recovery fine-tune
  • Unstructured magnitude fallback
Use when

Use Latticeprune Sparsefold when you target sparse-tensor-core hardware and want genuine inference speedup, not just nominal FLOP cuts, with accuracy recovered via a short retune.

Architecture 02 · Quantization & Compression
KV bits: 4-8Key: per-channelValue: per-token

Cachecrush Streamline

Per-channel low-bit KV-cache quant that lets context length scale past the memory wall.

Grounded inKV-cache quantization for long-context inference: per-channel (key) and per-token (value) low-bit quantization of the attention key/value cache, paged in fixed blocks.

Cachecrush Streamline is the inference-time architecture that stores the attention key/value cache in 4–8 bits instead of FP16, dramatically extending the context and batch sizes a given GPU can hold. It exists because at long sequence lengths the KV cache, not the weights, becomes the dominant memory consumer.

How it works

As tokens are generated, each layer's key and value tensors are quantized before being written to cache. Keys are quantized per-channel because their magnitude varies sharply across channels, while values are quantized per-token, matching their flatter per-token distribution; both use asymmetric affine quant with stored scale and zero-point per group. The cache is organized into fixed-size pages (blocks of tokens) so non-contiguous sequences pack without fragmentation and eviction is block-granular. During attention, the relevant K/V blocks are dequantized just-in-time into the scores and weighted-sum computation. A small sliding window of the most recent tokens can be kept in full precision to protect local fidelity.

Components
  • Per-channel key quantization
  • Per-token value quantization
  • Asymmetric scale + zero-point per group
  • Paged fixed-block cache layout
  • Full-precision recent-token window
Use when

Reach for Cachecrush Streamline when serving long-context or high-batch workloads where the KV cache, not model weights, is what blows your memory budget.

03

Corpus & Data Engineering

The model is the dataset. Curation, dedup, synthetic generation, tokenization, and curriculum — the upstream that decides everything downstream.

5 components
Framework 03 · Corpus & Data Engineering
Jaccard: ~0.8Sig: 128-256 permsRedundancy: -40%

Glyphsieve

Near-duplicate culling at corpus scale via fingerprint-band collision.

Grounded inDocument deduplication using MinHash + Locality-Sensitive Hashing (LSH) banding, as in the GPT-3/C4/FineWeb dedup pipelines.

Glyphsieve is the corpus deduplication engine that finds and removes near-duplicate documents without O(n^2) pairwise comparison. It exists because raw web corpora are 30-50% redundant, and training on duplicates wastes compute and memorizes boilerplate.

How it works

Each document is shingled into overlapping k-grams (typically 5-token windows), then reduced to a fixed-length MinHash signature of N permutation-minima that estimates Jaccard similarity in constant space. Signatures are split into b bands of r rows; documents colliding in any band become candidate pairs, tuning the S-curve so the probability of retrieval approximates 1-(1-s^r)^b. Candidates are union-find clustered and all-but-one member per cluster is dropped. A threshold near Jaccard 0.8 catches templated and reposted text while preserving distinct documents. The banding makes recall tunable independent of corpus size.

Components
  • k-gram shingling (5-token windows)
  • MinHash signature (128-256 permutations)
  • LSH banding (b bands x r rows)
  • Union-find cluster collapse
  • Jaccard threshold (~0.8) gate
Use when

Reach for Glyphsieve when assembling a pretraining corpus from web crawls, scraped forums, or merged datasets where exact-match dedup leaves heavy near-duplicate redundancy.

Framework 03 · Corpus & Data Engineering
Seed: ~175 tasksYield: 50k-500k pairsDedup: ROUGE-L < 0.7

Corpusmith

Self-instruct synthetic data forged from a seed of human exemplars.

Grounded inSynthetic instruction-data generation via Self-Instruct / Evol-Instruct: bootstrapping a teacher model from seed tasks with filtering.

Corpusmith is the synthetic data foundry that expands a small human seed set into a large, diverse instruction-tuning corpus using a strong teacher model. It exists to break the bottleneck of expensive human annotation for SFT data.

How it works

Starting from a seed pool of hand-written (instruction, output) pairs, a teacher LLM is few-shot prompted to generate new instructions, then to classify task type and produce inputs/outputs. Evolution operators deepen or broaden each instruction (add constraints, increase reasoning depth, mutate domain). Generated samples pass ROUGE/embedding-similarity dedup against existing pool to enforce diversity, plus heuristic and model-based quality filters that drop degenerate, unanswerable, or unsafe items. Surviving pairs feed back into the pool, so generation compounds. The result is a broad SFT set whose distribution is steered by seed composition and evolution operator mix.

Components
  • Human seed task pool
  • Teacher generation + evolution operators
  • Embedding/ROUGE diversity dedup
  • Quality + safety filter pass
  • Iterative pool feedback loop
Use when

Reach for Corpusmith when you need instruction-tuning volume and coverage fast and have only a few hundred curated exemplars to anchor it.

Architecture 03 · Corpus & Data Engineering
Vocab: 32k-128kBase: 256 bytesOOV: 0%

Latticescript

A byte-level merge lattice that learns the model's vocabulary from the corpus.

Grounded inSubword tokenizer construction via Byte-Pair Encoding (BPE), specifically byte-level BPE as used in GPT-2 and Llama tokenizers.

Latticescript is the tokenizer architecture that learns a compact subword vocabulary by greedily merging frequent symbol pairs over the training corpus. It exists to give the model a fixed, reversible vocabulary that balances sequence length against embedding-table size with no out-of-vocabulary failures.

How it works

Text is first decomposed to raw UTF-8 bytes, guaranteeing a 256-symbol base alphabet that covers any input losslessly. The trainer counts adjacent symbol-pair frequencies across the corpus and iteratively merges the single most frequent pair into a new token, recording an ordered merge table; this repeats until the vocabulary reaches the target size. At inference the same merge rules are replayed deterministically over byte sequences, so encoding is exact and decoding is a pure lookup. Vocabulary size trades compression (fewer tokens per document, cheaper context) against a larger embedding and softmax matrix. Pre-tokenization regex splits guard against merges spanning word and whitespace boundaries.

Components
  • UTF-8 byte base alphabet (256)
  • Pre-tokenization regex split
  • Greedy pair-frequency merges
  • Ordered merge table
  • Target vocab size (32k-128k)
Use when

Reach for Latticescript when training a new model family or adapting to a domain/language whose token distribution the stock tokenizer compresses poorly.

Terminology 03 · Corpus & Data Engineering
Domains: 5-20Temp: 0.3-1.0Upsample: <=4x

Strataweave

The per-source sampling weights that govern what the model actually sees.

Grounded inData mixture / domain reweighting laws for pretraining (e.g. DoReMi-style domain weight optimization and mixture sampling temperatures).

Strataweave is the term for the corpus's domain mixture weights: the sampling probability assigned to each data source during pretraining. It exists because a model's capabilities are shaped less by raw token counts than by the effective proportion each domain contributes per step.

How it works

The corpus is partitioned into domains (web, code, math, books, multilingual), each with a true token count. Rather than sampling proportionally, Strataweave assigns tuned weights, often via a temperature that flattens or sharpens the natural distribution so high-value scarce domains are upsampled and dominant low-value ones are downsampled. Weights can be optimized by training a small proxy model and minimizing worst-case excess loss across domains, yielding mixture coefficients transferred to the full run. Because total tokens are fixed, weights set effective epochs per domain, trading memorization risk on small upsampled sets against broad coverage. The chosen vector directly steers the capability profile of the finished model.

Components
  • Domain partition + token census
  • Sampling temperature control
  • Proxy-model weight optimization
  • Per-domain effective-epoch budget
  • Capability-targeted weight vector
Use when

Reach for Strataweave when balancing a pretraining or continued-pretraining run across heterogeneous sources and you need to deliberately bias toward target capabilities.

Framework 03 · Corpus & Data Engineering
Buckets: 4-10Pacing: linear/rootReplay: >=20%

Curriculord

Difficulty-ordered data scheduling from easy foundations to hard frontier.

Grounded inCurriculum learning: ordering training examples by difficulty/complexity to improve convergence and final quality.

Curriculord is the data-ordering framework that schedules training examples from easier to harder rather than presenting them in random order throughout the full run. It exists because a graduated presentation can speed convergence and improve final performance on complex distributions.

How it works

Each example is scored for difficulty using signals such as sequence length, model perplexity from a reference checkpoint, rarity, or task complexity. A pacing function defines what fraction of the difficulty range is unlocked at each training step, expanding a competence window as the model learns; early steps draw from the easy tail, later steps admit the hard frontier while still mixing in earlier material to prevent forgetting. Difficulty buckets are sampled according to the pacing schedule, and anti-forgetting replay keeps a baseline of prior buckets active. The schedule is decoupled from the optimizer so it composes with any mixture weighting underneath.

Components
  • Per-example difficulty scoring
  • Competence pacing function
  • Difficulty-bucket sampler
  • Anti-forgetting replay mix
  • Reference-perplexity signal
Use when

Reach for Curriculord when a corpus spans a wide complexity range (e.g. code or math from trivial to expert) and naive shuffling stalls early learning or destabilizes training.

04

Alignment & Preference

Teach taste, not just tokens. Reward models, direct preference optimization, and constitutional self-critique.

5 components
Framework 04 · Alignment & Preference
Human labels: ~0Phases: 2 (SL + RL)Judge: model-as-rater

CreedForge

Self-critique loops temper a model against your written charter, no human raters needed.

Grounded inRLAIF / Constitutional AI: AI-generated critique-and-revision plus an AI-labeled preference signal (model-as-judge) replacing human feedback against a written principle set.

CreedForge aligns a model to an explicit charter of principles by having the model critique and revise its own outputs, then learn from AI-generated preference labels. It exists to scale alignment past the bottleneck of human annotation while keeping behavior auditable against written rules.

How it works

Two phases. In the supervised phase, the base model samples a response, critiques it against a sampled charter principle, and revises; the revised pairs are distilled via SFT. In the preference phase, the model generates two candidates per prompt and a judge model picks the better one conditioned on a randomly sampled principle, yielding a synthetic preference dataset. A reward model is trained on those AI labels, then policy optimization (PPO-style or a direct-preference objective) tunes the policy. Principle sampling and chain-of-thought critiques make the signal interpretable, and because labels are model-generated, the pipeline scales without proportional human cost while staying grounded in the explicit creed.

Components
  • Charter: enumerated principle set sampled per example
  • Critique-revise SFT distillation pass
  • AI judge for pairwise preference labeling
  • Reward model trained on synthetic labels
  • Policy optimization stage (PPO or direct)
Use when

Reach for CreedForge when human preference labels are too costly or slow and you need behavior that traces back to an explicit, editable set of written principles.

Architecture 04 · Alignment & Preference
Head: 1 scalarLoss: Bradley-TerryInit: SFT backbone

Concordance Lattice

A frozen scalar critic over the policy that scores human-ranked pairs into a reward field.

Grounded inReward modeling for RLHF: a scalar reward head over a frozen/shared backbone trained with the Bradley-Terry pairwise logistic loss on human preference rankings.

Concordance Lattice is the reward-model architecture that converts human pairwise rankings into a continuous scalar reward signal over completions. It exists to give downstream policy optimization a learned, differentiable proxy for human preference.

How it works

A transformer backbone (often initialized from the SFT policy) gets a single linear scalar head replacing the LM head; the reward is read from the final token's hidden state. Training uses the Bradley-Terry model: for a chosen/rejected pair the loss is -log sigmoid(r_chosen - r_rejected), so the network learns relative scores rather than absolute labels. Rewards are typically mean-centered per batch to control scale, and the model is regularized to stay near init to avoid overfitting sparse human data. The result is a lattice of scalar scores across response space that PPO-style optimizers query as the reward, with a KL penalty to the reference keeping the policy from exploiting reward-model blind spots.

Components
  • Shared transformer backbone from SFT init
  • Scalar reward head on final-token hidden state
  • Bradley-Terry pairwise logistic loss
  • Per-batch reward normalization / centering
  • Reference KL anchor for downstream use
Use when

Use it whenever you run full RLHF and need a trained reward function to score arbitrary completions before policy optimization.

Framework 04 · Alignment & Preference
Reward model: noneLoss: implicit-rewardBeta: 0.1-0.5

PreferLoom

Skip the reward model — optimize the policy straight from preference pairs in closed form.

Grounded inDirect Preference Optimization (DPO-style): reparameterizing the RLHF objective so the optimal policy is its own implicit reward, trained directly on chosen/rejected pairs against a frozen reference.

PreferLoom fine-tunes a policy directly on preference pairs without ever training a separate reward model or running RL. It exists to deliver RLHF-quality alignment with the stability and simplicity of a supervised loss.

How it works

PreferLoom exploits the closed-form solution of the KL-constrained reward-maximization problem: the optimal policy relates to the reference by an exponential reward term, which can be inverted so the implicit reward equals beta times the log-ratio between policy and frozen reference. Substituting that into the Bradley-Terry preference likelihood yields a simple classification loss over chosen vs rejected completions: -log sigmoid(beta * [log pi/ref(chosen) - log pi/ref(rejected)]). A frozen reference copy supplies the denominators, and beta controls deviation from it, implicitly enforcing the KL constraint. No reward model, no sampling, no PPO loop — just gradient descent on logged pairs, which removes reward-hacking and the instability of on-policy RL.

Components
  • Frozen reference policy for log-ratios
  • Beta temperature controlling KL strength
  • Chosen/rejected preference pairs
  • Implicit-reward sigmoid classification loss
  • Single trainable policy copy
Use when

Reach for PreferLoom when you have offline preference pairs and want stable, reward-model-free alignment without standing up an RL pipeline.

Terminology 04 · Alignment & Preference
Sign: >0 = correctTarget acc: >0.7Unit: log-odds

Verdance Margin

The signed preference gap a model holds between a winning and losing response.

Grounded inThe implicit-reward margin / reward gap in preference optimization (the log-ratio difference driving DPO and the score difference in Bradley-Terry reward modeling); used as a training-health and accuracy diagnostic.

Verdance Margin is the scalar gap between a model's score for a chosen response and its score for the rejected one on the same prompt. It exists as the core diagnostic of whether preference training is actually separating good from bad, and by how much.

How it works

For a preference pair, the margin is the implicit reward of the chosen completion minus that of the rejected — concretely beta times the difference of policy-minus-reference log-probabilities in a DPO-style setup, or the raw scalar-head difference in a Bradley-Terry reward model. The preference loss is a monotonic function (log-sigmoid) of this margin, so larger positive margins mean lower loss and confident separation; margins near zero or negative flag pairs the model cannot rank. Tracking the margin distribution exposes failure modes: collapsing chosen and rejected log-probs together, over-optimization where both drift down, or reward saturation. Engineers monitor mean margin and accuracy (fraction with positive margin) as the primary alignment training signals.

Components
  • Chosen-minus-rejected implicit reward
  • Beta-scaled policy/reference log-prob delta
  • Log-sigmoid coupling to the loss
  • Preference accuracy (sign of margin)
  • Margin distribution as health monitor
Use when

Cite it whenever you debug or report on preference-tuning runs and need to know if the model genuinely distinguishes preferred from dispreferred outputs.

Framework 04 · Alignment & Preference
N: 4-64Keep: top-1/top-kLoss: cross-entropy

Assayloom Cull

Sample N, keep the best by reward, fine-tune on the survivors — alignment without RL.

Grounded inRejection sampling fine-tuning / best-of-N distillation (RAFT / RFT-style): generate multiple candidates, filter by a reward model or verifier, and SFT on the top-scoring completions.

Assayloom Cull aligns a model by sampling many candidate responses per prompt, scoring them, keeping only the highest-reward survivors, and supervised-fine-tuning on those. It exists as a simple, stable alternative to on-policy RL that still pulls the policy toward high-reward behavior.

How it works

For each prompt the current policy generates N completions at nonzero temperature. A reward model or a hard verifier (exact-match, unit test, rubric judge) scores them, and a cull step keeps the best — top-1 best-of-N, a top-k slice, or all above a reward threshold. The surviving high-quality completions form a new SFT dataset, and the model is fine-tuned on them with standard cross-entropy. Iterating — regenerate, rescore, refit — gives an expectation-maximization-like climb up the reward landscape without importance sampling, advantage estimation, or a KL-penalized RL loop. Because every gradient step is plain supervised learning on self-generated data, it is markedly more stable than PPO while capturing much of the gain.

Components
  • N-sample generation at temperature
  • Reward model or hard verifier scoring
  • Cull rule: best-of-N / top-k / threshold
  • SFT on surviving completions
  • Iterative regenerate-rescore-refit loop
Use when

Reach for Assayloom Cull when you want most of RLHF's gains with supervised-loop stability, or when a reliable verifier or reward model can cheaply rank samples.

05

Distillation & Merging

Pour a large model into a small one; fuse many checkpoints into one. Logit distillation and weight-space merging.

5 components
Framework 05 · Distillation & Merging
Temp: 2-8Params: -40 to -90%Loss: KL + CE

Distilflux

Pour a teacher's full belief into a smaller student through soft-label flux.

Grounded inResponse-based (logit-level) knowledge distillation via temperature-softened KL divergence between teacher and student output distributions (Hinton et al.).

Distilflux is our logit-level knowledge distillation recipe that transfers a large teacher model's full output distribution into a compact student. It exists to compress capability into smaller, cheaper models while preserving the teacher's nuanced confidence structure rather than just its top-1 answers.

How it works

The teacher and student both run forward on the same inputs. Teacher logits are divided by a temperature T (typically 2-8) and softmaxed into 'soft targets' that expose dark knowledge — the relative probabilities across wrong classes. The student trains on a weighted sum of two losses: a KL-divergence (or cross-entropy) against these temperature-scaled soft targets, scaled by T-squared to keep gradient magnitudes stable, plus a standard cross-entropy against the hard ground-truth labels. Backprop updates only the student. The soft-target term carries far more bits per example than one-hot labels, so the student converges to teacher-like behavior with a fraction of the parameters.

Components
  • Temperature T scaling of teacher/student logits
  • KL-divergence soft-target loss term
  • Hard-label cross-entropy anchor term
  • Alpha blend weight + T-squared gradient correction
  • Frozen teacher, trainable student
Use when

Reach for Distilflux when you have a strong, slow teacher and need a fast, deployable student that matches its judgment, not just its labels. Ideal for shrinking a frontier checkpoint for edge or high-QPS serving.

Terminology 05 · Distillation & Merging
Loss: MSE/cosineTargets: hidden+attnProj: learned linear

Tracegraft

Match the teacher's hidden geometry, not just its words.

Grounded inFeature-based (intermediate-representation) knowledge distillation — hint/guided layers matching internal activations, e.g. FitNets and attention/hidden-state transfer.

Tracegraft is the unit of internal-state supervision: a mapped pairing between a teacher hidden layer and a student layer whose activations are forced to align. It exists because matching final logits alone leaves the student's internal reasoning geometry unconstrained, which feature-level distillation fixes.

How it works

Beyond output logits, Tracegraft adds auxiliary losses on intermediate representations. Selected teacher layers ('hint' layers) are paired with student 'guided' layers. Because dimensionalities differ, a small learned linear projection (the graft) maps the student's hidden state into the teacher's space. An MSE or cosine loss then pulls the projected student activations toward the teacher's, often extended to attention maps or hidden-state relations (Gram matrices of token relationships). These feature losses are summed with the logit-distillation objective. Forcing intermediate alignment gives the student a richer, denser training signal and transfers structural knowledge that output-only matching misses, improving deep-layer reasoning fidelity.

Components
  • Teacher hint-layer / student guided-layer pairing
  • Learned linear projection between hidden dims
  • MSE or cosine activation-matching loss
  • Optional attention-map / relation-matrix transfer
  • Layer-mapping schedule across depth
Use when

Use Tracegraft when logit-only distillation plateaus and the student's deeper reasoning diverges from the teacher. It shines for deep transformers where internal representation quality, not just final tokens, drives task performance.

Architecture 05 · Distillation & Merging
Retrain: noneDensity: ~10-30%Inputs: 2-N tunes

Mergespire

Fuse many fine-tunes into one checkpoint by reconciling their task vectors.

Grounded inTraining-free weight merging via task arithmetic with sign-election and sparsification (TIES-merging) plus stochastic drop-and-rescale (DARE).

Mergespire is our topological weight-merging architecture that combines several specialist fine-tunes of a shared base into a single multi-talent checkpoint without any retraining. It exists to consolidate parallel fine-tuning efforts and avoid serving N separate adapters or models.

How it works

For each fine-tune, Mergespire computes a task vector — the element-wise delta between the fine-tuned weights and the shared base. To prevent destructive interference, it first trims each task vector to its highest-magnitude entries (most carry redundant near-zero noise), optionally applying stochastic drop-and-rescale so dropped weights are zeroed and survivors scaled up to preserve expectation. It then resolves sign conflicts by electing, per parameter, the direction with dominant aggregate magnitude across models, and averages only the agreeing task vectors. The reconciled merged vector is scaled and added back onto the base. The result is one set of weights inheriting multiple skills, all with zero gradient steps.

Components
  • Per-model task-vector extraction (fine-tune minus base)
  • Magnitude-based trimming / sparsification
  • Stochastic drop-and-rescale of deltas
  • Per-parameter sign election
  • Scaled re-addition onto base weights
Use when

Reach for Mergespire when you have multiple fine-tunes of one base model and want their combined skills in a single deployable checkpoint without retraining or multi-adapter serving overhead.

Framework 05 · Distillation & Merging
Cost: 1x inferenceInputs: 3-N runsInit: shared

Fluxbroth

Average many checkpoints into one stronger model — no inference-time cost.

Grounded inModel souping — weight-space averaging of multiple independently fine-tuned checkpoints (uniform and greedy soups).

Fluxbroth is our checkpoint-averaging recipe that blends multiple runs of the same base into one model living at the centroid of their weights. It exists to capture ensemble-like robustness and accuracy gains while paying the inference cost of just a single model.

How it works

Fluxbroth fine-tunes several copies of one pretrained base under varied hyperparameters, seeds, or data orderings — crucially all from the same initialization, so they stay in a shared, linearly-connected loss basin. It then averages their weights element-wise. The uniform variant simply means all checkpoints; the greedy variant sorts candidates by held-out accuracy and adds each to the soup only if it improves validation performance, discarding ingredients that hurt. Because the runs share an initialization, the averaged point typically sits in a flatter, better-generalizing region than any single checkpoint. The output is one model — no ensembling, no extra forward passes — that often beats the best individual run.

Components
  • Shared-init fine-tunes (varied seeds/HPs/data order)
  • Element-wise weight averaging
  • Uniform vs greedy ingredient selection
  • Held-out validation gate for greedy adds
  • Single merged checkpoint output
Use when

Use Fluxbroth after a hyperparameter sweep instead of discarding all but the best run: average the good ones for free accuracy and robustness with single-model latency.

Architecture 05 · Distillation & Merging
Active: top-k of NFLOPs/token: ~flatInit: cloned FFN

Spireforge

Upcycle a dense checkpoint into a sparse Mixture-of-Experts.

Grounded inMoE upcycling — initializing a sparse Mixture-of-Experts model by cloning a pretrained dense model's FFN layers into multiple experts plus a router (sparse upcycling).

Spireforge is our MoE-upcycling architecture that converts a trained dense transformer into a sparse Mixture-of-Experts with far higher capacity at near-constant per-token compute. It exists to scale model capacity cheaply by reusing dense pretraining instead of training a large MoE from scratch.

How it works

Spireforge takes a dense checkpoint and, in chosen transformer blocks, replaces each feed-forward layer with an MoE layer holding N expert FFNs — every expert initialized as a copy of the original dense FFN. A freshly initialized router (a small linear gate) is added to score tokens and dispatch each to its top-k experts. Attention and embeddings are inherited unchanged. Because experts start identical, the upcycled model initially matches the dense one, then continued training differentiates the experts and trains the router, typically with a load-balancing auxiliary loss to prevent expert collapse. The result has many times the parameters but activates only k experts per token, so FLOPs per token stay close to the dense base.

Components
  • Dense FFN cloned into N expert copies
  • Freshly initialized top-k router gate
  • Inherited attention + embedding weights
  • Load-balancing auxiliary loss
  • Continued training to differentiate experts
Use when

Reach for Spireforge when a dense model is capacity-bound but you can't afford to pretrain a large MoE from scratch — upcycle the existing checkpoint to grow parameters while holding inference FLOPs roughly flat.

06

Retrieval, Memory & Long Context

Give the model the world it wasn't trained on. Vector retrieval, external memory, and attention that scales to book-length context.

5 components
Architecture 06 · Retrieval, Memory & Long Context
Top-k: 3-20Recall@10: >0.9Refresh: index-only, no retrain

Memvault Lattice

A two-stage retrieval lattice that grounds generation in your own corpus, not the model's guesses.

Grounded inRetrieval-Augmented Generation (RAG): a retriever (dense bi-encoder embeddings + ANN index) fetches passages that are concatenated into the prompt of a frozen generator LLM.

Memvault Lattice is Hyperbridge's end-to-end retrieval-augmented generation architecture: an external document store is embedded, indexed, and queried at inference so the model answers from retrieved evidence rather than parametric memory. It exists to make generations grounded, updatable, and citeable without retraining the base model.

How it works

At ingest, documents are chunked and passed through a dense embedding encoder, producing vectors stored in an ANN index. At query time the user prompt is embedded with the same encoder; cosine/dot-product search returns the top-k nearest passages. Those passages are templated into the generator's context window alongside the question, so the LLM conditions its decoding on retrieved evidence. The generator stays frozen, so the knowledge base can be swapped or refreshed independently of weights. Optional citation spans tie each claim back to source chunks, and a relevance threshold filters weak hits before they pollute the context.

Components
  • Embedding encoder (shared query/doc bi-encoder)
  • ANN vector index (HNSW/IVF-style)
  • Top-k retriever with relevance gating
  • Context assembler / prompt templater
  • Frozen generator LLM with citation binding
Use when

Reach for it when answers must stay current, auditable, and grounded in a private corpus that changes faster than you can retrain. Ideal for knowledge assistants, support bots, and any domain where hallucination is unacceptable.

Terminology 06 · Retrieval, Memory & Long Context
Dim: 384-1536Metric: cosineLoss: InfoNCE

Echograph Embeddings

Dense semantic vectors that let meaning, not keywords, drive retrieval.

Grounded inDense vector embeddings from a contrastively-trained bi-encoder (sentence/passage embeddings, e.g. trained with in-batch negatives / InfoNCE) used for semantic similarity search.

Echograph Embeddings are the fixed-dimensional dense vectors Hyperbridge produces for every chunk and query, placing semantically similar text near each other in vector space. They are the substrate of all Foundry retrieval, turning fuzzy meaning into a metric a machine can search.

How it works

A transformer bi-encoder maps text to an L2-normalized vector by pooling token hidden states (mean or CLS). The encoder is trained contrastively: positive query-passage pairs are pulled together and in-batch negatives pushed apart via an InfoNCE/softmax-over-similarities loss, so geometric proximity encodes semantic relatedness. Because vectors are normalized, dot product equals cosine similarity, enabling fast inner-product ANN search. Dimensionality (typically 384-1536) trades index size and speed against expressiveness. The same encoder embeds both corpus and queries, guaranteeing the two live in one comparable space.

Components
  • Transformer bi-encoder backbone
  • Pooling head (mean/CLS) + L2 normalization
  • Contrastive InfoNCE training with in-batch negatives
  • Fixed output dimensionality (384-1536)
  • Cosine/dot-product similarity metric
Use when

Use whenever lexical search fails on paraphrase, synonymy, or cross-lingual queries, or as the encoding layer feeding any ANN index or reranker in the stack.

Framework 06 · Retrieval, Memory & Long Context
Context: up to 8-32xMethod: RoPE rescaleRetune: <1% steps

Riftspan Rotary

Stretch a trained context window far past its native length without retraining from scratch.

Grounded inLong-context extension via RoPE (rotary positional embeddings) frequency scaling — position interpolation / NTK-aware and YaRN-style rescaling of rotary base frequencies.

Riftspan Rotary is Hyperbridge's recipe for extending a model's usable context length by rescaling its rotary positional encoding so positions beyond the original training window stay in-distribution. It exists to unlock long-document reasoning from models trained on far shorter sequences.

How it works

RoPE encodes position by rotating query/key pairs at frequencies that span fast (high-frequency) to slow (low-frequency) bands. When sequences exceed training length, the slow bands rotate into angles the model never saw, degrading attention. Riftspan rescales the rotary base: low frequencies are interpolated (compressed toward seen angles) while high frequencies are left near-native, preserving local resolution. An NTK/YaRN-style per-band schedule plus a brief fine-tune on long samples re-aligns attention. The result extends context by large multiples with minimal added training, since no architectural change is needed, only positional frequency remapping and light adaptation.

Components
  • RoPE frequency-band analysis (fast vs slow rotations)
  • Position interpolation of low-frequency bands
  • NTK/YaRN-aware per-band scaling schedule
  • Short long-sequence fine-tune for re-alignment
  • Attention-temperature correction at long range
Use when

Reach for it when you must process documents, codebases, or transcripts longer than the base model's native window and full long-context pretraining is too costly.

Architecture 06 · Retrieval, Memory & Long Context
Memory: O(window)Sinks: 4 tokensPrefill: cached, reused

Vaultecho Cache

Persist and stream attention state so long sessions never recompute history.

Grounded inKV-cache management for long-context inference: streaming attention with attention sinks plus a sliding window (StreamingLLM-style) and persistent prefix/context KV reuse.

Vaultecho Cache is Hyperbridge's key-value cache architecture for sustained long-context inference, retaining attention state across turns while bounding memory growth. It exists so models can run on effectively unbounded streams without quadratic recompute or cache blowup.

How it works

Each transformer layer caches the key/value tensors of past tokens so attention never recomputes them. To stay bounded on long streams, Vaultecho keeps a sliding window of recent tokens plus a few persistent 'sink' tokens at the start, whose attention mass stabilizes the softmax and prevents the perplexity collapse that occurs when early tokens are naively evicted. Shared prefixes (system prompts, retrieved context) are cached once and reused across requests, cutting prefill cost. Positions are re-encoded relative to the retained window so evicted tokens leave no positional gap. The result is constant-memory, low-latency decoding over indefinitely long interactions.

Components
  • Per-layer key/value tensor cache
  • Attention-sink tokens for softmax stability
  • Sliding recency window with eviction
  • Shared prefix/context KV reuse
  • Relative position re-anchoring on eviction
Use when

Use for streaming chat, long agent loops, or repeated queries over a shared prompt prefix, where recomputing or unboundedly growing the KV cache is the bottleneck.

Framework 06 · Retrieval, Memory & Long Context
Recall pool: 50-100Keep: top 3-5Stage: 2 (cross-enc)

Graftsieve Rerank

A cross-encoder second pass that re-scores candidates so only the truly relevant reach the model.

Grounded inTwo-stage retrieval with cross-encoder reranking: a cheap bi-encoder/ANN recall stage followed by a cross-encoder that jointly scores query-passage pairs for precise relevance ordering.

Graftsieve Rerank is Hyperbridge's precision reranking framework that takes the candidate set from fast vector recall and re-orders it with a cross-encoder for sharply higher relevance. It exists to fix the precision gap of pure ANN search before context is handed to the generator.

How it works

First-stage retrieval returns a broad candidate pool (e.g. top-50-100) optimized for recall, not precision. Graftsieve then feeds each query-passage pair jointly through a cross-encoder, a transformer that attends across both texts at once and emits a single relevance score. Because it models full token-level interaction (unlike the independent encodings of a bi-encoder), it discriminates near-duplicates and subtle mismatches far better, at higher per-pair cost. Candidates are sorted by this score and the top few survive into the prompt. Running rerank only over the small recalled set keeps latency bounded while lifting end-to-end answer quality and citation accuracy.

Components
  • Stage-1 high-recall ANN candidate pool
  • Cross-encoder query-passage scorer
  • Joint full-attention relevance modeling
  • Score-sorted top-n selection / cutoff
  • Latency budget (rerank only the recalled set)
Use when

Reach for it when vector recall surfaces roughly-right but noisy passages and final answer precision or citation fidelity matters more than shaving milliseconds.

07

Inference & Serving Architecture

Tokens per dollar. Speculative decoding, paged attention, continuous batching, and routing cascades.

5 components
Framework 07 · Inference & Serving Architecture
Speedup: 2-3xBlock K: 4-8Output: lossless

Speccast Relay

A small drafter sprints ahead; the sovereign model verifies in one pass.

Grounded inSpeculative decoding (draft-and-verify decoding), including self-speculative / Medusa-style multi-head drafting.

Speccast Relay is Hyperbridge's draft-and-verify decoding loop that pairs a lightweight drafter with the full target model to emit multiple tokens per forward pass. It exists to cut wall-clock latency without changing the output distribution of the large model.

How it works

A small, cheap drafter model autoregressively proposes a block of K candidate tokens. The large target model then scores that whole block in a single batched forward pass, computing its own next-token probabilities at each position. A modified rejection-sampling test accepts the longest prefix where the draft agrees with the target distribution, then resamples the first rejected token from a corrected residual distribution. Accepted tokens are committed; the loop restarts from the new position. Because verification is parallel over the block, throughput rises with the acceptance rate while output is provably distribution-equivalent to plain sampling from the target.

Components
  • Drafter: small aligned model or Medusa-style extra heads
  • Verifier: full target model, single parallel forward pass
  • Rejection-sampling acceptance test (distribution-preserving)
  • Residual resample on first mismatch
  • Block length K + acceptance-rate telemetry
Use when

Reach for it when single-stream latency on a large model matters and you can afford a cheap, well-aligned drafter. Best when drafts and target agree often (code, structured text, low-temperature decoding).

Architecture 07 · Inference & Serving Architecture
Block: 16 tokWaste: <4%Prefix: COW-shared

Pagewright KV

Virtual-memory paging for the KV cache: no fragmentation, near-zero waste.

Grounded inPagedAttention-style KV-cache management with block-level paging, copy-on-write sharing, and near-zero memory fragmentation.

Pagewright KV is a KV-cache memory manager that stores attention keys and values in fixed-size non-contiguous blocks addressed through a per-sequence block table. It exists to eliminate the internal and external fragmentation that wastes GPU memory under naive contiguous KV allocation.

How it works

Each sequence's KV cache is split into fixed-size blocks (e.g. 16 tokens) that live anywhere in a global GPU block pool. A per-sequence block table maps logical token positions to physical blocks, so the attention kernel gathers KV by indirection instead of assuming contiguity. Blocks are allocated on demand as sequences grow, so only the last block of each sequence is ever partially full, bounding waste to under one block per sequence. Shared prefixes (system prompts, beam siblings) point at the same physical blocks via copy-on-write, duplicating only on divergent writes. The result packs far more concurrent sequences into the same VRAM.

Components
  • Fixed-size KV blocks in a global pool
  • Per-sequence block table (logical to physical)
  • Paged attention gather kernel
  • Copy-on-write prefix sharing
  • On-demand allocator + free list
Use when

Use it as the serving memory layer whenever you batch many concurrent sequences with variable, unpredictable lengths or share long common prefixes and need to maximize sequences-per-GPU.

Framework 07 · Inference & Serving Architecture
Throughput: up to 20x vs staticSched: per-iterationLatency: tail-optimized

Flowbatch Loom

Sequences join and leave the batch every step; the GPU never idles.

Grounded inContinuous (in-flight / iteration-level) batching with a token-budget scheduler for LLM serving.

Flowbatch Loom is an iteration-level scheduler that admits and retires requests at every decode step rather than per-request. It exists to keep GPU utilization high under bursty, heterogeneous traffic where naive static batching stalls on the longest sequence.

How it works

Instead of locking a batch until every sequence finishes, the scheduler re-forms the running batch on each forward iteration. Finished sequences are evicted the moment they hit a stop token, freeing slots that newly arrived prompts fill immediately. A token budget per step bounds compute, and prefill (prompt) work is interleaved with or chunked alongside decode work so long prompts don't block short generations. Combined with paged KV, admission is gated by available KV blocks, with preemption/recompute as a fallback under pressure. This raises effective throughput and lowers tail latency because the device processes a near-full batch every step regardless of length skew.

Components
  • Iteration-level admit/retire loop
  • Per-step token budget
  • Prefill-decode interleaving / chunked prefill
  • KV-block-aware admission control
  • Preemption + recompute under memory pressure
Use when

Deploy it as the request scheduler for any online multi-tenant LLM endpoint with variable prompt and output lengths where you want high throughput without sacrificing time-to-first-token.

Architecture 07 · Inference & Serving Architecture
Mesh: TP x PPTP link: NVLinkBubble: micro-batched

Shardloom Mesh

Split each layer across GPUs, stage the layers in a pipeline — weave both.

Grounded inCombined tensor parallelism (intra-layer sharding with all-reduce) and pipeline parallelism (inter-layer staging with micro-batching) for multi-GPU model execution.

Shardloom Mesh is a hybrid model-parallel execution layout that shards weights within each layer across a group of GPUs and stages groups of layers across pipeline ranks. It exists to serve models too large for one device while keeping both compute and interconnect efficiently saturated.

How it works

Tensor parallelism splits each layer's matmuls along the hidden dimension: attention heads and MLP columns are partitioned across a TP group, and an all-reduce (or reduce-scatter/all-gather) recombines partial results at well-defined boundaries, so per-GPU activations and weights shrink with minimal latency cost on a fast intra-node link. Pipeline parallelism then assigns contiguous layer stages to different GPU groups; activations flow stage to stage as point-to-point sends. Requests are split into micro-batches so multiple stages run concurrently, hiding pipeline bubbles. TP runs over high-bandwidth NVLink within a node; PP spans nodes where bandwidth is lower. The 2D mesh maps a model onto TP_size x PP_size devices.

Components
  • Tensor-parallel intra-layer shards + all-reduce
  • Pipeline-parallel layer stages
  • Micro-batching to fill pipeline bubbles
  • Topology-aware placement (NVLink intra, network inter)
  • Collective comm schedule (all-reduce / P2P sends)
Use when

Reach for it when a model exceeds single-GPU memory and you have a multi-GPU (often multi-node) cluster: TP within fast-linked nodes, PP across nodes.

Terminology 07 · Inference & Serving Architecture
Mem: O(N)Exact: yesBottleneck: HBM IO

Castfuse Kernel

IO-aware attention that never writes the full score matrix to HBM.

Grounded inFlashAttention-style IO-aware, tiled, fused exact attention with online softmax (no materialized N-by-N score matrix).

Castfuse Kernel is Hyperbridge's term for an IO-aware, fused attention kernel that computes exact attention tile-by-tile in fast on-chip SRAM. It exists because attention's bottleneck is memory traffic, not FLOPs, and materializing the full score matrix in HBM is what makes long contexts slow and memory-hungry.

How it works

Queries, keys, and values are loaded in blocks into on-chip SRAM. For each query tile, the kernel streams over key/value tiles, computing partial scores and accumulating the output with an online (running-max, running-sum) softmax that rescales as it goes, so the N-by-N attention matrix is never written to high-bandwidth memory. Softmax normalization, masking, and the score-times-value product are fused into one pass, cutting HBM reads/writes from quadratic to near-linear in sequence length. Memory footprint drops to linear, and the backward pass recomputes tiles on the fly instead of storing them. Numerics remain exact — it is an IO reordering, not an approximation.

Components
  • SRAM tiling of Q/K/V blocks
  • Online (streaming) softmax with running max/sum
  • Fused score-mask-softmax-value pass
  • Recompute-in-backward to avoid storing scores
  • Linear HBM traffic + linear memory in seq length
Use when

Use it as the attention primitive for long-context training and inference, or anytime attention is memory-bandwidth-bound and you need exact (not approximate) results with a smaller footprint.

08

Pretraining & Foundation Architecture

The bones. Sparse experts, attention variants, positional schemes, and the scaling laws that govern them.

5 components
Architecture 08 · Pretraining & Foundation Architecture
Norm: RMSNorm (pre)FFN: SwiGLULayers: 12-120+

Basalt Core

The sovereign decoder backbone every Kynetra model is forged on.

Grounded inModern pre-norm decoder-only transformer stack (GPT/Llama-style): stacked self-attention + MLP blocks with residual connections, pre-normalization, and SwiGLU feed-forward layers.

Basalt Core is Hyperbridge's reference decoder-only transformer backbone — the structural foundation on which every Foundry model is laid down. It standardizes the block topology, residual wiring, and normalization placement so that every downstream temper, graft, or route attaches to a known, stable substrate.

How it works

Each layer applies pre-normalization (RMSNorm) before sub-layers, then a causal self-attention block, then a gated SwiGLU feed-forward expansion, each wrapped in a residual connection so gradients flow cleanly through depth. Pre-norm placement keeps activation variance bounded, letting hundreds of layers train without divergence. The decoder mask enforces strict left-to-right causality for autoregressive next-token prediction. Weight tying between input embedding and output projection trims parameters. Hidden width, layer count, head count, and FFN multiplier are the tunable structural knobs; everything else in Foundry attaches to this fixed contract.

Components
  • Pre-norm residual blocks (RMSNorm-first)
  • Causal self-attention sub-layer
  • SwiGLU gated feed-forward expansion
  • Tied input/output embeddings
  • Configurable depth / width / head-count
Use when

Reach for Basalt Core when you are standing up a new foundation model from scratch and need a proven, stable decoder topology to build every other Foundry component on top of.

Architecture 08 · Pretraining & Foundation Architecture
Experts: 8-128Active: top-1/top-2Capacity: +10-50x params

Spire Lattice

Sparse expert routing — vast capacity, lean per-token compute.

Grounded inSparse Mixture-of-Experts (MoE) with top-k token routing, a learned gating network, and auxiliary load-balancing loss (Switch/GShard-style).

Spire Lattice replaces a dense feed-forward layer with a bank of parallel expert sub-networks and a router that sends each token to only a few. It scales total parameter count enormously while keeping the per-token FLOPs of a much smaller dense model.

How it works

At each Lattice layer the FFN is split into N independent experts. A lightweight gating network scores every token against all experts and dispatches the token's hidden state to the top-k highest-scoring experts (typically k=1 or 2). Only those experts compute; their outputs are combined weighted by the gate softmax, so active compute stays near-constant regardless of N. An auxiliary load-balancing loss plus a capacity factor prevents router collapse and keeps tokens evenly distributed, while expert-parallel sharding spreads the experts across devices. The result: 10-50x parameter capacity at roughly fixed inference cost.

Components
  • Expert bank (N parallel FFNs)
  • Top-k learned gating router
  • Auxiliary load-balancing loss
  • Capacity factor + token dropping
  • Expert-parallel sharding
Use when

Use Spire Lattice when you need to grow model capacity and knowledge far beyond what dense scaling allows, but must hold per-token inference cost and latency roughly flat.

Framework 08 · Pretraining & Foundation Architecture
KV heads: 1-8Cache: -50-87%Quality: ~MHA

Attentryx Grip

Share the keys, free the cache — attention that scales at inference.

Grounded inGrouped-Query Attention (GQA), interpolating between multi-head and multi-query attention by sharing key/value projections across groups of query heads.

Attentryx Grip is Hyperbridge's attention-head sharing scheme that lets many query heads draw on a smaller shared set of key/value heads. It collapses the KV cache that dominates long-context inference memory while preserving nearly all the quality of full multi-head attention.

How it works

Standard multi-head attention keeps a distinct key and value projection per query head, so the autoregressive KV cache grows with head count and sequence length. Grip partitions the query heads into G groups and gives each group a single shared K/V head — so G key/value heads serve all query heads. This shrinks KV-cache memory and memory bandwidth by the ratio (heads/G), the bottleneck in decode-time throughput, while query heads stay independent enough to retain accuracy. G=1 recovers multi-query attention (max compression); G=heads recovers full MHA. Models are typically pretrained directly with the chosen group count, or up-trained from an MHA checkpoint by mean-pooling K/V heads.

Components
  • Query heads grouped into G clusters
  • Shared K/V projection per group
  • Reduced KV-cache footprint
  • MQA (G=1) ↔ MHA (G=heads) interpolation
  • Mean-pool uptraining from MHA
Use when

Reach for Attentryx Grip when long-context or high-throughput serving is memory-bound on the KV cache and you want most of MHA's quality at a fraction of the cache.

Terminology 08 · Pretraining & Foundation Architecture
Params: 0 addedBase: 10k-1M+Context: 4x-32x extend

Helix Anchor

Rotary phase encoding that lets context stretch far past training length.

Grounded inRotary Position Embedding (RoPE) plus long-context extension via frequency-base scaling / NTK-aware interpolation (position interpolation).

Helix Anchor is Foundry's relative-position primitive: it encodes token order by rotating query and key vectors through position-dependent angles. Because position lives in phase rather than added vectors, the same model can be stretched to context lengths far beyond what it saw in pretraining.

How it works

Each query/key vector is split into 2D sub-planes, and Helix rotates each plane by an angle proportional to the token's absolute position times a frequency that decreases geometrically across dimensions. When a query and key dot-product, the rotations combine so the score depends only on their relative offset — giving translation-invariant relative positioning with no added parameters. To extend context, Helix rescales the rotary base (frequency) or interpolates positions (NTK-aware / linear interpolation), compressing unseen far-apart angles into the trained range so attention stays coherent. A short fine-tune re-anchors the model at the new length.

Components
  • Per-dimension rotary frequency bands
  • Query/key phase rotation
  • Relative-offset dot products
  • Base-frequency / NTK rescaling
  • Short re-anchor fine-tune
Use when

Use Helix Anchor when you need parameter-free relative positioning and intend to serve contexts longer than the pretraining window via frequency rescaling.

Framework 08 · Pretraining & Foundation Architecture
Optimal: D≈20N tokensCompute: C≈6NDStages: 2-4 curriculum

Forgecurve Doctrine

Compute-optimal sizing and staged curriculum — train the right model, the right way.

Grounded inNeural scaling laws (Chinchilla compute-optimal parameter/token allocation) combined with curriculum / staged data-ordering pretraining.

Forgecurve Doctrine is Foundry's pretraining-planning framework: it sets the compute-optimal balance of parameters versus training tokens, then orders the data into staged phases. It exists to stop teams from over-parameterizing under-fed models or burning budget inefficiently.

How it works

Given a fixed compute budget C (≈6ND FLOPs for N params over D tokens), the Doctrine fits power-law loss curves to small calibration runs and solves for the N and D that minimize final loss — the Chinchilla-style finding that params and tokens should scale together, roughly D≈20N, rather than growing model size alone. It then schedules a curriculum: broad, high-coverage data early to build general representations, progressively shifting to higher-quality, harder, or domain-targeted mixtures late, with learning-rate warmup and cosine decay tuned to the token budget. Loss-vs-compute extrapolation predicts final quality before the full run commits.

Components
  • Power-law loss-vs-compute fitting
  • Compute-optimal N/D allocation (D≈20N)
  • Staged data-mixture curriculum
  • LR warmup + cosine decay to token budget
  • Small-run extrapolation to full scale
Use when

Reach for Forgecurve Doctrine at the planning stage of any large pretraining run — to size the model against your token budget and sequence the data before committing GPU-months.

09

Evaluation, Observability & Governance

If you can't measure it, you can't ship it. Eval harnesses, judges, drift detection, and full lineage.

5 components
Architecture 09 · Evaluation, Observability & Governance
Tasks: 50-400Seed: fixed/deterministicCI: bootstrap 95%

Proofgrid

A sovereign, versioned eval lattice that scores every checkpoint on the same sealed bench.

Grounded inReproducible evaluation harnesses and benchmark orchestration (e.g. lm-evaluation-harness / HELM-style task suites with frozen prompts, few-shot specs, deterministic decoding, and metric aggregation).

Proofgrid is Hyperbridge's containerized evaluation architecture that runs a model checkpoint against a pinned matrix of tasks, prompts, and metrics under fixed decoding settings. It exists so that every score is reproducible, comparable across checkpoints, and auditable down to the exact prompt and seed.

How it works

Each task is declared as a sealed manifest: dataset hash, prompt template, few-shot exemplars, output parser, and metric (exact-match, F1, pass@k, log-likelihood ranking). Runs execute with pinned decoding (temperature, top-p, max tokens) and fixed seeds so results are deterministic. The grid fans tasks across workers, captures raw generations plus parsed scores, and aggregates per-task and macro metrics with bootstrapped confidence intervals. Every run is keyed by model hash + harness commit + dataset hash, so two checkpoints are compared on byte-identical conditions. Contamination checks flag train/test overlap via n-gram and embedding matching before scores are admitted.

Components
  • Sealed task manifests (dataset hash, prompt, parser, metric)
  • Pinned decoding profile + fixed seeds
  • Distributed run fan-out with raw-generation capture
  • Bootstrapped CI aggregation + macro rollups
  • Contamination scanner (n-gram / embedding overlap)
Use when

Reach for Proofgrid when you need defensible, reproducible scores to gate a checkpoint, compare model variants, or publish a benchmark that survives audit. It is the source of truth before any model ships.

Framework 09 · Evaluation, Observability & Governance
Judges: 1-5 ensembleBias-control: order-swapAgreement: kappa-tracked

Arbiter Lattice

Ensemble LLM-as-judge with calibrated rubrics, position-swapping, and human anchor points.

Grounded inLLM-as-a-judge evaluation: rubric-scored and pairwise model judging (MT-Bench / Chatbot-Arena-style), with position-bias mitigation, judge calibration against human labels, and inter-rater agreement.

Arbiter Lattice is a judging framework that uses one or more strong models to score candidate outputs against explicit rubrics or in pairwise comparisons. It exists to scale quality evaluation beyond hand-labeling while controlling the known biases of model judges.

How it works

Candidates are scored two ways: absolute (a rubric prompt yields a 1-10 or criterion-wise score with chain-of-thought rationale) and relative (pairwise A-vs-B with a forced preference). To suppress position and verbosity bias, every pair is judged twice with order swapped and ties are dropped; length is regressed out. Multiple judge models vote and disagreements surface inter-rater agreement (Cohen's/Fleiss' kappa). The judges are calibrated against a held-out human-labeled anchor set, and a bias-correction term aligns judge scores to human means. Final rankings use Bradley-Terry / Elo aggregation over the pairwise outcomes.

Components
  • Rubric prompts with criterion-wise rationale
  • Pairwise judging with order-swap de-biasing
  • Multi-judge vote + kappa agreement
  • Human anchor set for calibration
  • Bradley-Terry / Elo ranking aggregation
Use when

Use it when references don't exist and metrics like BLEU/ROUGE fail to capture quality — open-ended generation, chat, summarization, or preference data curation. Calibrate against humans before trusting it as a gate.

Terminology 09 · Evaluation, Observability & Governance
Range: 0.0-1.0Checker: NLI entailmentGranularity: atomic-claim

Veracity Quotient

A single faithfulness score: how much of an answer is grounded in cited evidence.

Grounded inHallucination / factuality and groundedness metrics for RAG and open-ended generation: claim decomposition + NLI entailment against sources (FactScore / RAGAS-faithfulness-style atomic-fact verification).

The Veracity Quotient is Hyperbridge's primitive metric for factual grounding: the fraction of a response's atomic claims that are supported by the provided evidence or a trusted knowledge source. It exists to quantify hallucination as a number you can threshold, track, and regress against.

How it works

A response is decomposed into atomic factual claims by a extractor model. Each claim is checked against retrieved source passages (or a reference KB) using a natural-language-inference model that labels it entailed, contradicted, or unsupported. The Quotient is the share of claims that are entailed; an unsupported-claim rate and a contradiction rate are reported alongside. For RAG, two sub-scores split the signal: context-faithfulness (claims grounded in retrieved context) and answer-relevance (claims that actually address the query). Scores are length-normalized so verbose answers can't dilute the penalty, and per-claim verdicts are retained for inspection.

Components
  • Atomic-claim decomposition
  • NLI entailment vs source passages
  • Entailed / contradicted / unsupported tallies
  • Context-faithfulness + answer-relevance split
  • Length normalization + per-claim audit trail
Use when

Reach for it whenever factual accuracy matters — RAG pipelines, summarization, knowledge assistants — and you need a thresholdable groundedness number for CI gates or production monitoring.

Architecture 09 · Evaluation, Observability & Governance
Addressing: SHA-256Output: ML-BOMTamper: signature-chained

Lineagraph

Tamper-evident provenance DAG linking every weight to the data, code, and config that forged it.

Grounded inData and model lineage / provenance: content-addressed dataset and artifact tracking, model cards, and signed supply-chain attestation (ML-BOM / dataset hashing / DVC-style DAGs with cryptographic signing).

Lineagraph is a provenance architecture that records a directed acyclic graph from raw data through every transform, training run, and checkpoint to the deployed weights. It exists so you can prove what went into a model, reproduce it, and trace any output back to its lineage for governance and recall.

How it works

Every artifact — dataset shard, preprocessing step, hyperparameter config, base checkpoint, fine-tune run — is content-addressed by cryptographic hash and registered as a node, with edges encoding produced-by/derived-from relationships. Each node carries signed metadata (author, timestamp, code commit, license, consent flags). Building a checkpoint emits a machine-readable ML bill-of-materials enumerating its full upstream closure. Because nodes are hash-pinned and signatures chain, any post-hoc tampering breaks verification. Queries walk the DAG forward (impact analysis: which models touched a poisoned shard) or backward (audit: what licensed/PII data is in this checkpoint), and reproduction replays the exact recorded inputs.

Components
  • Content-addressed nodes (data, code, config, weights)
  • Produced-by / derived-from edges (the DAG)
  • Signed metadata: author, license, consent, commit
  • ML bill-of-materials per checkpoint
  • Forward impact + backward audit traversal
Use when

Use it when provenance is non-negotiable: regulated deployments, license/PII audits, data-poisoning incident response, or proving a model's training pedigree to a customer or regulator.

Framework 09 · Evaluation, Observability & Governance
Drift: PSI/KL/MMDMode: streamingGate: shadow-canary

Driftwatch Sentinel

Continuous telemetry that catches input drift and quality regressions before users do.

Grounded inProduction drift and regression detection / observability: data and embedding-distribution drift (PSI, KL, MMD), online quality-proxy monitoring, and alerting on metric regressions across model or prompt versions.

Driftwatch Sentinel is a monitoring framework that continuously profiles live traffic and model behavior, comparing them against a sealed reference window to detect distribution drift and quality regressions. It exists to turn silent production degradation into an actionable alert with a diagnosis attached.

How it works

At inference it logs structured telemetry: input embeddings, token-length and topic distributions, latency, refusal and tool-call rates, and a cheap online quality proxy (a lightweight judge or the Veracity Quotient on a sampled slice). Input drift is measured by comparing current windows to a frozen reference using Population Stability Index, KL divergence, and kernel MMD on embeddings; categorical shifts use chi-square. Output drift watches score and refusal-rate deltas across model/prompt versions with statistical change-point detection. Threshold breaches raise alerts tagged with the drifting feature and a traffic slice for triage, and a canary mode gates new versions by running them on shadow traffic before promotion.

Components
  • Structured inference telemetry (embeddings, rates, latency)
  • Reference-window drift: PSI / KL / MMD / chi-square
  • Sampled online quality proxy (judge / Veracity Quotient)
  • Change-point detection + feature-tagged alerts
  • Shadow-traffic canary gating for new versions
Use when

Reach for it once a model is in production and you need early warning when inputs shift, quality slips, or a new version silently regresses — and you want the alert to point at the cause, not just fire.

10

Safety, Sovereignty & Orchestration

Train on your terms, behind your walls. Guardrails, sovereign / air-gapped pipelines, and sharded orchestration at scale.

5 components
Framework 10 · Safety, Sovereignty & Orchestration
Latency: <40ms/turnCategories: 12+Action: block/redact/rewrite

Sentinel Weave

A layered guardrail mesh that filters inputs and outputs before they ever reach the user.

Grounded inGuardrails and content filtering via classifier-based moderation: a separate safety classifier model (or set of models) scoring prompts and generations against policy categories, with allow/block/redact actions, similar to LlamaGuard / NeMo Guardrails / OpenAI moderation pipelines.

Sentinel Weave is a multi-stage content-safety layer that scores every prompt and every model generation against policy categories and applies block, redact, or rewrite actions. It exists to decouple safety policy from the base model so guardrails can be updated without retraining the underlying weights.

How it works

Inbound text is embedded and passed to a fine-tuned classifier (a small transformer head trained on labeled policy categories: violence, self-harm, CBRN, PII, etc.) producing per-category probabilities. A threshold rail decides allow/redact/block before the base model runs. On the output side, generations stream through the same classifier plus regex/entity detectors for PII; flagged spans are masked or trigger a refusal template. Policies are expressed as declarative rules (category -> threshold -> action) evaluated at runtime, so updating a policy never touches base weights. Decisions and category scores are logged for audit and threshold tuning.

Components
  • Inbound prompt classifier (policy-category scoring)
  • Outbound generation classifier + PII entity detector
  • Declarative rail policy (category -> threshold -> action)
  • Redaction / refusal-template engine
  • Audit log of scores and actions
Use when

Reach for Sentinel Weave when you must enforce content policy on a shared or external-facing model without retraining it, and you need updatable, auditable filtering on both inputs and outputs.

Framework 10 · Safety, Sovereignty & Orchestration
ASR: -90% vs baseHierarchy: 4-tierDetect: perplexity+embed

Wardgate

Adversarial-prompt defense that hardens models against jailbreaks and injection.

Grounded inJailbreak and prompt-injection defense: adversarial training plus runtime detection — fine-tuning on red-team / adversarial-suffix datasets, perplexity-based and embedding-similarity detection of known attack patterns, and instruction-hierarchy enforcement (system > developer > user).

Wardgate is a jailbreak-resistance system combining adversarial fine-tuning with a runtime injection detector that enforces a strict instruction hierarchy. It exists to keep models from being coerced into policy-violating behavior by crafted prompts, role-play framings, or embedded instructions in retrieved content.

How it works

Offline, the base model is fine-tuned on a curated corpus of jailbreak attempts (adversarial suffixes, persona attacks, encoded payloads) paired with correct refusals, teaching robust refusal behavior. At runtime, incoming prompts are screened by a detector that flags high-perplexity adversarial suffixes and embedding-space neighbors of known attack templates. An instruction-hierarchy parser tags every token's provenance (system, developer, user, tool/retrieved) so the model down-weights instructions originating from untrusted sources, defeating indirect prompt injection. Detected attacks are blocked or rewritten before inference; novel patterns are harvested back into the adversarial training set on a cadence.

Components
  • Adversarial fine-tuning corpus (attacks -> correct refusals)
  • Perplexity + embedding-similarity attack detector
  • Instruction-hierarchy provenance tagging
  • Indirect-injection filter for retrieved content
  • Continuous red-team harvest loop
Use when

Use Wardgate when the model is exposed to untrusted user input or tool/RAG content and you need defense-in-depth against jailbreaks and prompt injection, not just output filtering.

Architecture 10 · Safety, Sovereignty & Orchestration
Egress: zeroKeys: customer HSMResidency: pinned

Sovryn Vault

Air-gapped, on-prem training topology where data and weights never leave the perimeter.

Grounded inSovereign / air-gapped / on-prem training: fully offline training infrastructure with no egress, local artifact registries and mirrored package repos, encryption at rest, and data-residency controls — the pattern behind regulated/classified on-prem LLM training.

Sovryn Vault is a sovereign training architecture in which the cluster, data, and model weights are confined to a customer-controlled, network-isolated perimeter with no outbound egress. It exists so regulated and sensitive workloads can fine-tune and serve models without data or IP ever crossing an external boundary.

How it works

All training runs inside an air-gapped enclave: package indexes, base-model artifacts, and datasets are pre-mirrored to an internal registry so no build step reaches the public internet. Egress is denied by default at the network policy layer; only an audited, one-way import gate moves vetted artifacts in. Datasets and checkpoints are encrypted at rest (e.g., LUKS/at-rest KMS) with keys held in a customer HSM, and residency rules pin storage to specific physical nodes/regions. An immutable provenance ledger records every dataset hash, base weight, and run config, giving a complete, exportable chain of custody for audits and clean-room reproduction.

Components
  • Network-isolated enclave (egress-deny by default)
  • Mirrored package + base-model artifact registry
  • Audited one-way import gate
  • At-rest encryption with customer-held HSM keys
  • Immutable provenance / chain-of-custody ledger
Use when

Choose Sovryn Vault for classified, regulated, or IP-sensitive training where data residency and zero-egress are hard requirements and cloud APIs are off the table.

Architecture 10 · Safety, Sovereignty & Orchestration
Mem/GPU: ~1/N replicasStage: 3 (params+grads+opt)Offload: CPU/NVMe

Shardbastion

Fully-sharded parallelism that splits weights, gradients and optimizer state across the cluster.

Grounded inFSDP / ZeRO sharding: ZeRO stages 1-3 (and FSDP) partition optimizer states, gradients, and parameters across data-parallel ranks, all-gathering shards just-in-time for compute to train models far larger than a single GPU's memory.

Shardloom is a fully-sharded data-parallel training architecture that partitions parameters, gradients, and optimizer state across all ranks instead of replicating them. It exists to fit models that vastly exceed single-device memory while keeping near-linear scaling efficiency.

How it works

Following ZeRO-3 / FSDP, each rank owns only a shard of every layer's parameters, gradients, and optimizer state. During the forward pass, a layer's full parameters are all-gathered from peers just before its compute, then freed immediately after; the backward pass re-gathers, computes local gradients, and reduce-scatters them so each rank ends with only its gradient shard. Optimizer steps act on the local shard, slashing per-GPU memory roughly by the number of ranks. Communication is overlapped with computation via prefetching, and mixed precision plus optional CPU/NVMe offload extends capacity further. The result is training of multi-billion-parameter models without any single device holding a full copy.

Components
  • Parameter / gradient / optimizer-state sharding (ZeRO-3 style)
  • Just-in-time all-gather and free per layer
  • Reduce-scatter of gradients to local shards
  • Communication-computation overlap (prefetch)
  • Optional CPU/NVMe offload tier
Use when

Reach for Shardloom when a model plus its optimizer state won't fit on one GPU and you need to scale across many devices with minimal memory replication.

Terminology 10 · Safety, Sovereignty & Orchestration
Resume: exactly-onceRecompute: ~+30% FLOPsWrite: async/sharded

Anchorpoint

A durable, resumable training checkpoint that restores the full run state byte-for-byte.

Grounded inCheckpoint / resume orchestration combined with activation (gradient) checkpointing: asynchronous distributed checkpointing of model + optimizer + RNG + dataloader state for fault-tolerant resume, plus trading compute for memory by recomputing activations in the backward pass.

An Anchorpoint is a complete, consistent snapshot of a training run — sharded weights, optimizer state, RNG seeds, scheduler step, and dataloader position — written so a crashed job resumes deterministically with no lost or repeated samples. It is the unit of fault tolerance for long sovereign training runs.

How it works

At a set step cadence, each rank asynchronously writes its shard of the model and optimizer state to durable storage while training continues, coordinating a consistency barrier so the snapshot reflects a single global step. The Anchorpoint also captures RNG state, learning-rate-scheduler position, and the exact dataloader offset, enabling deterministic, exactly-once resumption after preemption or hardware failure. To bound the memory cost of reaching the next Anchorpoint, activation checkpointing stores only layer-boundary activations and recomputes the rest during backprop, trading roughly 30% extra compute for large memory savings. Older snapshots are pruned by a retention policy, with periodic full snapshots kept for rollback.

Components
  • Sharded async write of weights + optimizer state
  • Global-step consistency barrier
  • RNG / scheduler / dataloader-offset capture
  • Activation (gradient) checkpointing for memory bound
  • Retention + rollback policy
Use when

Use Anchorpoints on long multi-GPU runs subject to preemption or hardware failure, where deterministic exactly-once resume and bounded activation memory matter.