Engram adapter

The Engram experiment trains added n-gram memory tables, projections and gates over a frozen base model. Token-history lookups contribute inside the model's forward pass. This is learned internal memory, not a document retrieval/RAG index or an editable list of phrases injected into a prompt.

For example, train recurring product names and domain terminology from reviewed answers, then check unseen combinations and unrelated language. Repeating a phrase in the training set does not establish broad factual learning.

Set up the experiment

Choose New → Engram in Experiments.

The runtime fixes supported hook layers, token suffix orders, hash/table shape, projection dimensions and history handling. These are not arbitrary editable architecture fields. The implemented post-hoc Qwen adapter is separate from a native DeepSeek model or a throughput claim about another architecture.

Inputs follow the reviewed supervised text boundary described in SFT with LoRA. Table lookups use the exact tokenizer and request history. Different tokenization or reused history can change the model's effective computation.

Read the result

Inspect actual table/projection/gate training, finite loss, artifact size, export and fresh reload. Compare the starting model, trained adapter and Off path with the same input and sampling. Off must restore the exact parent/base behavior, and request history must not leak between inputs or users.

An exact compatible saved Engram parent can be used for supported continuation. That starts fresh optimizer state; it is different from recovering an interrupted optimizer. Arbitrary LoRA/steering/Engram stacking is not implied.

Review, run and recover

Use Review → Prepare review to resolve the exact inputs, compatible runtime and maximum spend. Inspect the retained preparation before approving Start. Opening the editor, changing tabs and saving a draft do not start paid compute. Preparing a run is separate from starting it.

If a response is lost, reopen the same experiment and retained execution before retrying. Preserve its operation identity and revision; creating a second run can duplicate work and charges. Use the existing refresh, retry or cancellation controls. Cancellation is a request: follow the execution through cleanup and inspect remaining capacity and funding before treating it as finished.

Runtime discovery is authoritative. A selectable action or saved configuration does not prove that a checkpoint/image/GPU combination is qualified. Unsupported combinations cannot start simply because sufficient credits are available.

Save and serve

After a successful execution with verified artifacts, choose Save Model. The saved version retains its exact base, modification and artifact identity. Saving is separate from allocating serving capacity. Open the saved Model, review compatible serving and approve activation explicitly. Use Stop and verify released capacity when finished.

Measure a baseline and candidate on the same held-out tasks and grader versions. Training loss, successful export and a working endpoint do not establish better answers. Keep runtime correctness and task quality as separate checks.

API, SDK and harness

Use compileEngramExecution, prepareEngramExecution and startEngramExecution. CLI commands are training hosted-compile-engram, hosted-prepare-engram, hosted-start-engram and hosted-engram-execution. Save with hosted-save-engram-model; serving uses hosted-control-engram-serving.

Use the official CLI with your configured account and workspace. Run openpond training --help and the selected command's help for the current request schema; start from the SDK's typed draft/request builders rather than inventing an unversioned JSON payload. Web, API, TypeScript/Python SDKs and the CLI retain the same preparation, execution and Model identities. Paid Start and serving activation require explicit approval; a harness should retain these identities for recovery.