Nexusflow/NexusRaven-13B warn

Convert the weights to safetensors before loading them anywhere that matters.

1. Do not load the pickle files in-process — pickle deserialization executes arbitrary code from the file.
2. Convert locally in a sandbox: `pip install safetensors` and use `safetensors.torch.save_file` on a state dict loaded with `torch.load(..., weights_only=True)` (refuses most code-execution payloads), or use Hugging Face's `convert.py` space/script.
3. Pin the exact revision hash you converted from, and load only your converted safetensors artifact from then on.

Review and pin the custom code; never float on `main` with trust_remote_code=True.

1. Read every `.py` file in the repo before first load — this code runs in your process.
2. Pin the revision: `from_pretrained(model_id, revision="<commit sha>", trust_remote_code=True)` so a later push can't swap the code under you.
3. Prefer a version of the architecture already in `transformers` if one exists, which removes the remote-code requirement entirely.

Restore the parent's chat template in `tokenizer_config.json` — a pure metadata fix.

1. Run `ingot patch <owner/model>` — the patch manifest carries the parent's template and applies it to a local copy's `tokenizer_config.json`.
2. Or fix by hand: copy the `chat_template` value from the parent repo's `tokenizer_config.json` into this model's, and pin your serving stack to that file.
3. If the drift was intentional (the author retrained on a new template), confirm that in the model card before "fixing" it — restoring the parent template on retrained weights changes behavior too.

Not patchable: the vocab size mirrors the embedding matrix in the weights. Verify the change was intentional.

1. Do not edit `vocab_size` in config.json to "match the parent" — it must equal the embedding table in the shipped weights or the model won't load.
2. Diff the tokenizers (`tokenizer.json` / added_tokens) against the parent to see what was added or removed, and test your own identifiers, codes, and non-English text through both.
3. If the drift is unexplained by the model card, treat tokenization-sensitive behavior as unvalidated on this model.

Keep the affected token strings out of the model's input — the scan-derived runtime guard carries this model's exact blocklist.

1. Fetch this model's guard artifact (`/api/v1/guard/<owner>/<model>`): the confirmed corrupting tokens and the low-norm candidate list, derived from the published scan.
2. Screen inbound text with it (the `@ingotai/guard` package is a reference implementation) and route flagged records to a different model or human review — verbatim-copy tasks on flagged strings are the failure mode.
3. The underlying cause is undertrained embeddings in the weights; a true fix is weight-level (continued pretraining on the affected tokens) — that is not a patch, it's a training job.