@@ -508,13 +508,13 @@ from `ignition export` and the diagnostic `ignition serve` commands.
 ### Downloading published packages
 
 ```sh
-flare download local-inference-lab/MODEL --gpus 0,1,2,3
-flare run local-inference-lab/MODEL --gpus 0,1,2,3
-flare download local-inference-lab/MODEL --revision gb10
-flare run local-inference-lab/MODEL@gb202 --filename model.safetensors --gpus 0,1,2,3
+flare download ORG/MODEL --gpus 0,1,2,3
+flare run ORG/MODEL --gpus 0,1,2,3
+flare download ORG/MODEL --revision gb10
+flare run ORG/MODEL@gb202 --filename model.safetensors --gpus 0,1,2,3
 ```
 
-These examples use `MODEL` as a repository-name placeholder. Repositories contain
+These examples use `ORG/MODEL` as a repository placeholder. Repositories contain
 prepared Flare packages, not source Transformers checkpoints. Hardware variants
 are separate Hugging Face revisions named `gb10` and `gb202`. Automatic selection
 queries the selected GPUs' PCI device identifiers through the CUDA driver without
@@ -591,7 +591,7 @@ With the default package cache, the layout is:
 ```text
 ~/.cache/flare/packages/
   blobs/<sha256>.safetensors
-  models--local-inference-lab--Qwen3.8-Flash-Next-FLARE/
+  models--qwen38/
     snapshots/<snapshot-id>/
       model.safetensors
       <sha256>.safetensors
@@ -652,8 +652,8 @@ Configure published exports with all three values:
 ```toml
 [publishing]
 signing_key = "/private/flare-signing-key.pem"
-namespace = "local-inference-lab"
-official_source = "https://huggingface.co/local-inference-lab/foobar"
+namespace = "example-publisher"
+official_source = "https://huggingface.co/example-publisher/MODEL"
 ```
 
 The key must be an owner-only Ed25519 PKCS#8 PEM file. Encrypted keys prompt
 
@@ -31,121 +31,6 @@ or select it with Docker Buildx. ARM64 also includes libibverbs and its provider
 because Flare enables the RoCE transport on that architecture. Multi-host RoCE
 deployment additionally requires the host's RDMA devices and network setup.
 
-To build and publish both Linux architectures under one tag, log in to the
-destination registry, then run:
-
-```sh
-./scripts/build_container.sh
-```
-
-The script creates a `docker-container` builder if the selected name is missing,
-preserves existing builder configuration, and starts the builder before building.
-The script uses builder `flare-multi`, pushes
-`ghcr.io/local-inference-lab/flare:latest`, and displays the published manifest.
-Use `--beta` or `--release` to publish `ghcr.io/local-inference-lab/flare:beta`
-or `ghcr.io/local-inference-lab/flare:release`, respectively:
-
-```sh
-./scripts/build_container.sh --beta
-./scripts/build_container.sh --release
-```
-
-Use `--tag IMAGE:TAG` for a custom image reference. The three tag options are
-mutually exclusive. Override the builder with `--builder NAME`. Build output
-uses plain progress logs, including when redirected. The script resolves the
-repository root from its own location, so it can run from any working directory.
-Docker selects the matching architecture when pulling the published tag.
-
-## Continuous publication
-
-The [serving-container workflow](../.github/workflows/container.yml) builds Linux
-AMD64 and ARM64 images on pushes to `main`. It can also be started manually with
-GitHub Actions' **Run workflow** control on `main`. A push containing several
-commits builds its tip commit, rather than a separate image for every intermediate
-commit. There is no path filter or pull-request trigger.
-
-The workflow first publishes a staging tag of the form
-`ghcr.io/local-inference-lab/flare:sha-COMMIT-RUN-ATTEMPT`. It checks the image
-index and runs `--version`, `run --help`, `agent --help`, and `orbit --help` for
-both architectures, without GPUs, networking, ports, or host mounts. These CPU
-checks validate executable startup and CLI parsing; they do not validate model
-serving. Only a successful build whose commit still matches remote `main` is
-promoted to `ghcr.io/local-inference-lab/flare:latest`. Promotion uses the tested
-index digest and verifies the resulting digest. A superseded build retains its
-staging tag. The workflow does not change `beta` or `release`.
-
-Register a dedicated, trusted Linux X64 self-hosted runner for the Flare
-repository with label `lil-flare-builder`. An existing runner registered only
-for another repository cannot accept this workflow. The runner needs `gh`,
-`jq`, `flock`, Docker, and a system-installed Buildx plugin. Its rootless Docker
-daemon must be reachable at
-`unix:///run/lil-flashinfer-docker/docker.sock`, with the containerd image store
-and ARM64 emulation configured. The workflow uses builder `default` to retain
-that daemon's BuildKit caches; it does not install emulation or create a builder.
-
-The runner user must be able to open
-`/var/lib/github-flashinfer/locks/cu134-sm120-build.lock`. The workflow holds this
-shared lock through building, smoke tests, and promotion, waiting up to six
-hours for other builds. GitHub Actions queues runs without canceling the active
-build; a remote `main` check prevents queued, superseded commits from replacing
-`latest`. Docker credentials live in a temporary per-run configuration directory
-and are removed when the build step exits.
-
-The workflow grants its `GITHUB_TOKEN` repository-content read access and package
-write access. The existing GHCR `flare` package must also grant the Flare
-repository Actions write access through inherited repository permissions or
-the package's **Manage Actions access** settings. Public pull access and an OCI
-source label alone do not establish that write permission.
-
-## Discord changelog
-
-The [published-changes workflow](../.github/workflows/changelog.yml) checks for
-unannounced changes after a successful container workflow and hourly at minute
-17. It resolves `latest` through GHCR and requires both image architectures to
-identify the same source commit. A private repository token reads commit
-metadata; source files, patches, and commit bodies are not sent to the model.
-The model receives sanitized commit subjects and produces short English notes.
-The notes describe changes in `main`, including preparation changes that are
-not part of the serving container.
-
-At most one announcement is sent in six hours. Commits accumulate while that
-interval is active, and the hourly check flushes them even without another push.
-State is stored outside the checkout at
-`/var/lib/github-flashinfer/state/flare-announcements`. Its runner-owned directory
-must survive job cleanup and host restarts. A separate file lock serializes
-updates. A successful Discord acknowledgment advances the commit cursor; a
-transport failure triggers message-history reconciliation before another send.
-
-Configure the repository secret `FLARE_DISCORD_BOT_TOKEN` and these repository
-variables before enabling publication:
-
-| Variable | Meaning |
-| --- | --- |
-| `FLARE_DISCORD_CHANNEL_ID` | Destination channel the bot can view and send to |
-| `FLARE_ANNOUNCE_BASE_SHA` | Complete source SHA covered by the preceding announcement |
-| `FLARE_ANNOUNCE_BASE_TIME` | That announcement's timestamp with a UTC offset |
-| `FLARE_CHANGELOG_MODEL_URL` | OpenAI-compatible API base URL reachable from the runner |
-| `FLARE_CHANGELOG_MODEL` | Model name served by that API |
-
-The baseline variables initialize an absent state file. They do not reset an
-existing cursor. The bot does not automatically mention users or roles. Preview
-an explicitly selected range without sending a Discord message or changing state:
-
-```sh
-GH_TOKEN="$(gh auth token)" python3 scripts/announce_changes.py \
-  --repository local-inference-lab/flare \
-  --channel-id "$FLARE_DISCORD_CHANNEL_ID" \
-  --preview --base "$FLARE_ANNOUNCE_BASE_SHA" \
-  --image ghcr.io/local-inference-lab/flare:latest \
-  --model-url "$FLARE_CHANGELOG_MODEL_URL" --model "$FLARE_CHANGELOG_MODEL"
-```
-
-If an uncertain send cannot be found in channel history, the job stops rather
-than risking a duplicate. An operator can retry through **Run workflow**, using
-the exact `pending.nonce` and `pending.head` from the state file as `retry_nonce`
-and `retry_head`. This rechecks the channel history and still requires six hours
-since the uncertain attempt; it preserves the frozen message and commit range.
-
 ## Run
 
 This example exposes host GPU 0 and mounts a directory containing a prepared
@@ -196,11 +81,11 @@ identity through Docker's `--user` flag. For example:
 mkdir -p "$HOME/.cache/huggingface/hub"
 docker run --rm --user "$(id -u):$(id -g)" \
   --mount "type=bind,src=$HOME/.cache/huggingface/hub,dst=/cache" \
-  flare:local download local-inference-lab/MODEL \
+  flare:local download ORG/MODEL \
   --revision gb202 --cache-dir /cache
 ```
 
-`MODEL` is a repository-name placeholder. An explicit revision permits downloading
+`ORG/MODEL` is a repository placeholder. An explicit revision permits downloading
 without exposing GPUs. For automatic selection, expose the intended host GPUs
 with Docker's `--gpus` and select their container-local indices with Flare's
 `--gpus`. `flare run ORG/NAME` accepts the same download options, then loads the
 
@@ -46,8 +46,7 @@ prepared forwards before warmup and CUDA graph capture. Model structure,
 numerical semantics, compiler optimizations, and kernel preparation remain
 connected to the Python ecosystem throughout execution construction.
 
-The vLLM fork's Qwen and GLM paths maintain engine-specific model
-implementations. vLLM also offers a
+vLLM offers a
 [Transformers backend](https://huggingface.co/docs/transformers/main/en/transformers_as_backend),
 whose attention, state, and execution contracts still need to fit each model.
 Flare's preparation boundary lets canonical model code and PyTorch compilation
@@ -74,17 +73,6 @@ concentrated on composing those capabilities into a service; Flare does not
 need to establish a competing model ecosystem or develop another kernel
 library to become useful.
 
-The [Local Inference Lab vLLM fork](https://github.com/local-inference-lab/vllm/tree/dev/karmic-kraken)
-already integrates this stack. Its support extends through checkpoint
-transfers, compressed-scale expansion, PCIe and RoCE collectives, coordinated
-kernel preparation, graph workspaces, decode context parallelism, recurrent
-prefix checkpoints, external checkpoint transfers, speculative verification,
-and prefill scheduling. Those concerns cross model, worker, scheduler, cache,
-and allocator interfaces. Maintaining a specialized serving contract is already
-part of supporting these models in vLLM. The cost comparison is between
-carrying those integrations through a general engine and maintaining a smaller
-runtime whose invariants directly express their requirements.
-
 vLLM's device, backend, model, and distributed-execution breadth creates a
 large compatibility matrix. Changes to cache layouts, compilation, offload,
 and scheduling must coexist across those combinations. Flare limits that
@@ -156,10 +144,9 @@ Keeping a conversation outside GPU memory imposes related requirements. A
 resumable endpoint includes recurrent matrices, selector state, attention
 tails, and saved hidden state alongside its KV pages. Every part must describe
 the same committed token prefix. Transfer sources must remain immutable, and
-destinations cannot be recycled while a copy can still write to them. The
-vLLM fork's offload integration spans these rules, from frozen recurrent
-snapshots and padded selector tails to restore admission, cancellation, and
-cache reset. A disk transport depends on all of them.
+destinations cannot be recycled while a copy can still write to them. Offload
+integration spans frozen recurrent snapshots, padded selector tails, restore
+admission, cancellation, and cache reset. A disk transport depends on all of them.
 
 The [tiered prefix-cache design](prefix-cache-offload.md) extends the checkpoint
 object Helios already owns. Stores retain published immutable page chains and