pllm
Research

Compositions and recipes

Learn how PLLM records research recipes and changes to a model plan.

PLLM documentationView Markdown ↗

Research workflows describe source acquisition, target model operations, required evidence, review gates, and failure policy. They are documentation, not executable package records. Start with the research backlog and choose a workflow under research recipes.

A composed plan records the method, value formats, conversions, numeric policy, parties, threat model, visible information, state lifetime, workload, component version from the component inventory, and coverage. Matching shapes and data types are not enough. A change to the source, implementation, configuration, plan, workload, or cohort creates new plan history. Components contribute declared capabilities; they do not establish runtime coverage, privacy, fidelity, or benchmark parity by their presence alone.

MPCache is one example: pllm/kv-cache-eviction structurally adapts a compatible plan through code in crates/pllm-models/src/cache.rs. It is not a protected MPCache runtime. See method implementations and the public component APIs.

Method and lifecycle choices remain separate, so research configurations can declare and later recombine them:

from pllm.nonlinear import R03CrtGatedMultiplyQ7
from pllm.schedulers import IndependentLanesProtectedTensorSchedule

method = R03CrtGatedMultiplyQ7()
schedule = IndependentLanesProtectedTensorSchedule(max_elements=4)

assert method.describe().category == "pllm/nonlinear-protocol"
assert schedule.describe().category == "pllm/protected-scheduler"

These declarations are immutable configuration inputs. The baseline Experiment profile rejects them because it does not execute this protected region. The specialized native region test path consumes both selections; full-decoder Experiment resolution and matched benchmarking remain deferred until compiler coverage is complete.

Loading documentation index…

Search runs locally in this browser.