muse12-nemo-agentic

# Muse Spark 1.2 High-Reasoning NeMo Agentic Dataset A reproducible, verified 24,000-row synthetic agentic dataset generated with Meta Muse Spark 1.2, NeMo Gym, and deterministic task-family verifiers. The project is a quality-focused successor to [`r0b0tlab/deepseek-v4-pro-0813-agentic`](https://huggingface.co/datasets/r0b0tlab/deepseek-v4-pro-0813-agentic). It keeps rollout prompts separate from reference trajectories and offline-training views, records usage and provenance, and does not publish private chain-of-thought. > [!IMPORTANT] > **Status: production release verified and published privately to [`r0b0tlab/muse12-nemo-agentic`](https://huggingface.co/datasets/r0b0tlab/muse12-nemo-agentic).** The immutable campaign contains exactly 24,000 accepted rows, with all 13 family quotas and 21,600 / 1,200 / 1,200 train / validation / test splits satisfied. Accepted-only replay validation and release audit both passed. ## Documentation - [Hugging Face dataset card source](docs/HUGGING_FACE_DATASET_CARD.md) - [Generation, resume, export, security, and release operations](docs/OPERATIONS.md) - [NeMo Gym collation/evaluation and NeMo RL commands](docs/NEMO_GYM_AND_RL.md) - [Dataset artifact license](DATA_LICENSE.md) - [Upstream source audit](reports/source/REVIEW.md) ## Current evidence and release status | Item | Current result | Interpretation | |---|---:|---| | SQLite task ledger | 24,000 accepted | Exact immutable production target reached | | Splits | 21,600 / 1,200 / 1,200 | Train / validation / test | | Families | 13, all quota-complete | Planning 1,200 and instruction following 3,200 included | | Accepted-only replay | 24,000 / 24,000 | Deterministic verifier replay passed | | Release audit | Passed | 22 checksums, ID/split parity, privacy scans, and 0 duplicate identities | | Release package | 23 files / ~1.09 GB | Versioned accepted-only views plus manifest and checksums | | Hugging Face publication | Private, verified | 67 remote files; manifest byte-for-byte verified | | NeMo RL training | Not run locally | Requires NVIDIA Linux/CUDA and a trainable checkpoint | The production release retains rejected generation attempts only in the private ledger for audit and DPO construction. Public reference, SFT, canonical, and task views contain only verified accepted rows with redacted reasoning visibility. ## Dataset design Tasks are procedurally synthetic and organized into 13 families. The 24,000-row column is a target quota only. | Family | Pilot rows | 24k target | Programmatic verification emphasis | |---|---:|---:|---| | Tool calling | 125 | 5,000 | Final answer, argument shape, required calls, nominal efficiency | | Instruction following | 80 | 3,200 | Bullet count, forbidden word, exact ending, topic coverage | | Structured outputs | 55 | 2,200 | JSON parse, JSON Schema, exact values, format hygiene | | Stateful dialogue | 50 | 2,000 | Recall, mutation accuracy, current-state schema | | Verifiable math | 50 | 2,000 | Exact or tolerance-aware answer checking | | Science | 45 | 1,800 | Physics, chemistry, and biology answer checking | | Multilingual | 45 | 1,800 | Supplied glossary use, order, JSON format | | Planning | 30 | 1,200 | Required keys, fixed facts, list lengths | | Long context | 30 | 1,200 | Retrieval and aggregation over 64K / 128K / 240K-character corpora | | Delegation | 20 | 800 | Coverage, no duplicate work, valid agents, merge order | | Citations | 20 | 800 | Exact allocations, document support, completeness | | Memory | 20 | 800 | Retention, mutation, deletion, stale-value exclusion | | Code execution | 30 | 1,200 | Function interface, hidden tests, use of `py_run` | ### Identity and splits A task identity hash covers normalized Responses API input, tool definitions, task initial state, the verifier contract, and `template_version`. Stable IDs use: ```text muse12-<family>-<seed>-<first-24-hex-of-identity> ``` `assign_splits` ranks each family by SHA-256 of `split-v2:<task_identity_hash>` and assigns approximately 90% train, 5% validation, and 5% test, with at least one validation and test row per family. This prevents exact identity hashes from crossing splits, but it does **not** yet group by nonce-stripped template, semantic similarity, bucket, or operation. The `ood_hard` label is assigned only when a hash-selected test row also has the current index-derived `hard` label; it is not a calibrated OOD benchmark designation. ## Architecture ```text configs/ campaign.yaml campaign/model/schema targets meta_muse_model.yaml NeMo Gym native Meta Responses model config src/muse12_nemo/ task_factory.py deterministic procedural task inventory identity.py canonical task identity and stable IDs schemas.py task, rollout, reward, and ledger contracts tools.py task-scoped record lookup and Python runner verify.py deterministic weighted multi-reward verifiers generator.py Muse Responses API tool loop and retry logic store.py SQLite-WAL campaign ledger export.py split assignment and dataset views cli.py `muse12` command-line interface resources_servers/muse12_agentic/ app.py NeMo Gym resources server and verifier bridge configs/muse12_agentic.yaml agent, datasets, and resource registration scripts/ run_pilot.py pilot orchestration run_full.py current unsafe scale-up runner; do not use analyze_pilot.py implemented pilot quality gates remediate_rejections.py historical pilot remediation audit_dashboard.py responsive dashboard audit dashboard/ server.py read-only campaign projection index.html local monitoring UI ``` ### Generator contract The generator currently pins: - Base URL: `https://api.meta.ai/v1` - Provider: `meta-ai` - Model: `muse-spark-1.2-contributor` - API mode: Responses API - Reasoning effort: `high` - Provider storage: `store: false` - Tool-loop continuation: `include: ["reasoning.encrypted_content"]` - Prompt-cache retention: `24h` - Maximum output: 16,384 tokens - Maximum tool steps: 8 in the NeMo agent config - Campaign concurrency: 4 by default - Task attempts: 3 in the pilot/full scripts Encrypted reasoning may be replayed to the provider in memory to continue a stateless tool loop. New generator code stores only redaction markers and usage-level reasoning-token counts. The existing 600-row pilot ledger and `reference_rollouts` exports predate that storage fix and still contain encrypted reasoning payloads and some non-empty summaries; they are private evidence and must not be published. ### Verifier contract Each family returns: ```text reward: float in [0, 1] reward_components: mapping[str, float in [0, 1]] passed: bool evidence: family-specific diagnostic object ``` The scalar reward is a normalized weighted sum. `passed` requires the family verifier's selected critical components to equal `1.0`; noncritical components can lower reward without failing the rollout. NeMo Gym also receives matching top-level numeric component fields for aggregation. Independent audits found several criticality and semantic-calibration gaps. Treat the verifier suite as a deterministic research baseline, not a trusted production judge, until the blockers in [Known limitations and release blockers](#known-limitations-and-release-blockers) are fixed. ## Install ### Requirements - Python `>=3.12,<3.13` (the lockfile is exercised with Python 3.12.11) - [`uv`](https://docs.astral.sh/uv/) - NeMo Gym 0.4.0 (pinned by `pyproject.toml`) - A Meta Model API key only for live Muse generation - Optional: Ollama for local inference-only NeMo Gym evaluation - NVIDIA Linux/CUDA plus a trainable checkpoint for NeMo RL; the local Mac cannot provide this ```bash git clone <THIS_REPOSITORY_URL> cd muse12-nemo-agentic uv sync --frozen --python 3.12.11 --all-groups ``` Verify the source environment: ```bash uv run pytest uv run ruff check . env -u UV_RUN_RECURSION_DEPTH -u VIRTUAL_ENV \ .venv/bin/gym env test --resources-server muse12_agentic ``` NeMo Gym 0.5.0 is not the project contract. This workspace pins 0.4.0; the audited remote NeMo RL pairing is `nvcr.io/nvidia/nemo-rl:v0.7.0`. ## Authentication without exposing tokens ### Meta Model API Use Hermes' interactive provider setup rather than putting a key in source, a command, an issue, or chat: ```bash hermes model ``` Select `meta-ai` and enter the key only in the credential prompt. The generator checks `MODEL_API_KEY`, `META_API_KEY`, and `META_MODEL_API_KEY`, then `~/.hermes/.env`. Never commit `.env`; it is ignored by this repository. For a process that requires `MODEL_API_KEY` in its environment, use a hidden prompt so the value does not enter shell history: ```bash read -r -s MODEL_API_KEY export MODEL_API_KEY printf '\n' ``` Then run a sanitized smoke request: ```bash uv run muse12 smoke-api ``` Unset the variable when finished: ```bash unset MODEL_API_KEY ``` ### Hugging Face Hub The dataset is not published yet. When a private candidate repository exists, authenticate interactively: ```bash uv run hf auth login uv run hf auth whoami ``` Do not pass a token on the command line. In CI, use a masked/scoped `HF_TOKEN` secret and prevent environment dumps in logs. ## Pilot generation For a fresh pilot, use a new database and output directory rather than mutating the preserved local pilot: ```bash PILOT_DB=state/campaign-pilot-new.sqlite PILOT_OUT=data/releases/pilot-600-candidate uv run muse12 init \ --count 600 \ --campaign-seed 13000000 \ --db "$PILOT_DB" uv run muse12 smoke-api --db "$PILOT_DB" uv run muse12 generate \ --db "$PILOT_DB" \ --concurrency 4 \ --max-task-attempts 3 uv run muse12 status --db "$PILOT_DB" uv run muse12 export --db "$PILOT_DB" --output "$PILOT_OUT" --accepted-only uv run muse12 validate --db "$PILOT_DB" --output "$PILOT_OUT" --accepted-only uv run muse12 checksums --output "$PILOT_OUT" ``` The convenience script uses the default `state/campaign.sqlite`, requires exactly 600 accepted rows, exports, validates, collates train/validation, and runs the implemented pilot report: ```bash uv run python scripts/run_pilot.py ``` Do not use the convenience script against evidence you intend to keep immutable without first making a verified backup. ## Resume and top-up behavior `muse12 generate` resumes rows whose ledger status is `pending`. At startup it resets **all** `leased` rows to `pending`; there is no lease expiry or run heartbeat. Therefore: 1. Run exactly one generator process against a database. 2. Confirm no other runner is active before resuming. 3. Inspect status before and after each run. ```bash uv run muse12 status --db "$PILOT_DB" uv run muse12 generate --db "$PILOT_DB" --concurrency 4 --max-task-attempts 3 uv run muse12 status --db "$PILOT_DB" ``` Terminal `rejected` and `failed` rows are not leased again. There is no supported CLI command for safe same-identity retry, absolute accepted-target top-up, or manifest-slot replacement. `--stop-after-accepted` is relative to process start and can overshoot by up to `concurrency - 1`. Do not call the internal `replace_terminal_tasks` method as an operational workaround. It is not exposed by the CLI, does not implement the full manifest/family/split/provenance contract, and introduces a status not accepted by the current `LedgerEntry` schema. See [OPERATIONS.md](docs/OPERATIONS.md) for the required production-safe contracts. ## Do not scale with the current runner Do **not** run: ```bash uv run python scripts/run_full.py ``` The current source template version is `2026-08-23.2`, while the completed pilot was produced across earlier identity states. `run_full.py` additively calls `init --count 24000` against the pilot ledger, resplits existing accepted tasks, and then requires exactly 24,000 accepted rows. Audit simulation predicts 24,600 tasks on the current worktree, so the runner cannot satisfy its own completion assertion. A production campaign requires a new immutable 24,000-slot manifest and ledger, exact-identity pilot import only, frozen splits, safe leases, absolute target semantics, circuit breakers, streamed/versioned export, and fail-closed release validation before any paid generation begins. ## Dataset views and publication sensitivity | View | Local path | Purpose | Current publication status | |---|---|---|---| | `nemo_tasks` | `data/generated/nemo_tasks/{split}.jsonl` | Prompt-only Responses API tasks | **Private/eval-sensitive:** includes verifier answers, hidden tests, and initial state | | `nemo_collated` | `data/collated/{train,validation}.jsonl` | NeMo-prepared tasks with `agent_ref` | **Private/eval-sensitive:** inherits verifier fields | | `reference_rollouts` | `data/generated/reference_rollouts/{split}.jsonl` | Full teacher traces, tool events, usage, verification | **Do not publish:** current pilot files contain reasoning payloads/summaries | | `sft_openai` | `data/generated/sft_openai/{split}.jsonl` | Verified OpenAI-style SFT conversations | Candidate only after release scan and license review | | `canonical_audit` | `data/generated/canonical_audit/{split}.jsonl` | Joined audit/provenance/reward view | **Private/eval-sensitive:** includes ground truth and verifier evidence | | `canonical` | `data/generated/canonical/{split}-00000-of-00001.parquet` | Parquet form of canonical audit | Same sensitivity as `canonical_audit` | | `dpo_pairs` | `data/generated/dpo_pairs/all.jsonl` | Best/worst same-identity alternatives with reward gap | Candidate only after identity and content audit | Current `nemo_tasks` are prompt-only in the sense that `responses_create_params.input` contains no generated assistant trajectory. That does not make the whole row public-safe: the top-level `verifier` field and parts of `metadata.initial_state` are privileged evaluation material. Detailed schemas and Hugging Face loading examples are in [HUGGING_FACE_DATASET_CARD.md](docs/HUGGING_FACE_DATASET_CARD.md). ## NeMo Gym The resource config registers: - Resource server: `muse12_agentic` - Agent: `muse12_agentic_simple_agent` - `agent_ref`: `{"type":"responses_api_agents","name":"muse12_agentic_simple_agent"}` - Maximum agent steps: 8 - Train source: `data/generated/nemo_tasks/train.jsonl` - Validation source: `data/generated/nemo_tasks/validation.jsonl` Collate with the installed training model proxy config: ```bash env -u UV_RUN_RECURSION_DEPTH -u VIRTUAL_ENV \ .venv/bin/gym dataset collate \ --config resources_servers/muse12_agentic/configs/muse12_agentic.yaml \ --config .venv/lib/python3.12/site-packages/responses_api_models/vllm_model/configs/vllm_model_for_training.yaml \ --mode train_preparation \ --output-dir data/collated ``` A verified one-row local Ollama evaluation and exact, explicitly unverified NeMo RL GRPO/GDPO commands are documented in [NEMO_GYM_AND_RL.md](docs/NEMO_GYM_AND_RL.md). ## Hugging Face loading examples There is no live dataset repository ID yet. For local pilot inspection: ```python from datasets import load_dataset canonical = load_dataset( "parquet", data_files={ "train": "data/generated/canonical/train-00000-of-00001.parquet", "validation": "data/generated/canonical/validation-00000-of-00001.parquet", "test": "data/generated/canonical/test-00000-of-00001.parquet", }, ) sft = load_dataset( "json", data_files={ split: f"data/generated/sft_openai/{split}.jsonl" for split in ("train", "validation", "test") }, ) ``` After a Hub release defines named configurations, replace the placeholder: ```python from datasets import load_dataset repo_id = "ORG_OR_USER/DATASET_NAME" # placeholder; no release exists yet canonical = load_dataset(repo_id, "canonical") sft = load_dataset(repo_id, "sft_openai") ``` Do not upload or load the current `reference_rollouts`, `nemo_tasks`, collated, or canonical audit views as public blinded evaluation data. ## Local Mac constraints The audited local host is a MacBook Air with Apple M4, 10 CPU cores, 24 GB unified memory, and no CUDA/NVIDIA GPU. At the documentation pass, the repository volume had approximately 22.22 GiB free and was 97.60% used. Free space is time-sensitive; check it again before generation or export. The project environment has NeMo Gym 0.4.0 and Ray 2.58.0, but not `nemo_rl`, PyTorch, Transformers, or vLLM. Docker CLI is installed, but its daemon was unavailable. Local Ollama GGUF models are inference-only and cannot replace a differentiable NeMo RL policy checkpoint. The independent scale audit estimated, from the pilot rate: - about 200.6 MB for 24,000 serialized task records alone; - about 30,280 rollout attempts and 38,200 API turns; - about 68.6 million total tokens; - about 552 MB of serialized rollout JSON before SQLite/export duplication; - about 15.7 hours ideal wall time at concurrency 4, excluding throttling. These are planning estimates, not a budget guarantee. The current exporter also materializes large task/rollout collections in memory and is not approved for the full campaign on this host. ## Quality, provenance, and security requirements A releasable candidate must, at minimum: 1. Bind an immutable task manifest to a source-tree digest, semantic template hash, campaign seed, quotas, split assignments, model settings, retry policy, and dataset license review. 2. Contain exactly the declared accepted manifest identities and split/family quotas. 3. Prove accepted task/rollout ID and identity parity, one accepted rollout per slot, and task/rollout/file split consistency. 4. Pass deterministic verifier replay and adversarial false-positive calibration. 5. Pass nonce-stripped/template-level and fuzzy semantic deduplication across splits. 6. Keep public model-facing prompts separate from private verifier sidecars. 7. Recursively forbid persisted reasoning payloads, summaries, visible reasoning fields, and secrets. 8. Isolate untrusted code execution with no network, a minimal read-only/empty filesystem, an unprivileged user, and CPU/RSS/process/file limits. 9. Export incrementally to a new versioned directory, validate it, create checksums, and publish atomically. 10. Preserve immutable pilot and rejected-attempt evidence privately. ### Security warnings - Never place personal, proprietary, private, or regulated data in prompts. Meta contributor-tier prompts and completions may be used to improve Meta products. - Never publish the current pilot `reference_rollouts`; scans found encrypted reasoning payloads and non-empty reasoning summaries in all split files. - Never expose `/py_run` or the resources server to an untrusted network. The current AST filter and temporary subprocess are not a security sandbox. - Never use public `nemo_tasks`, collated rows, or canonical audit rows as a blind benchmark while verifier answers and hidden tests remain embedded. - Never run multiple generators against one ledger; leasing is not concurrency-safe across processes. - Never print, log, commit, or upload API keys. Treat generated tool outputs and error evidence as potentially sensitive until scanned. ## Known limitations and release blockers The current candidate is a research pilot with these known blockers: - **Scale reconciliation:** the pilot and current source identity versions do not reconcile additively to exactly 24,000 tasks. - **Reasoning retention:** existing reference rollouts and the pilot database contain provider reasoning payloads/summaries despite a top-level `redacted` label. - **Code isolation:** `py_run` executes under host-user privileges with no network, memory, process, or filesystem boundary strong enough for untrusted code. - **Verifier calibration:** instruction relevance, planning semantics, tool efficiency, and code-tool/result linkage can accept degenerate trajectories. - **Semantic duplication:** per-task nonces make exact prompt hashes unique while a small number of templates repeat across rows and splits. - **Evaluation quality:** splits are family-stratified but not template/bucket grouped; difficulty is mostly index-derived; `ood_hard` is not calibrated. - **Privileged data exposure:** task and canonical views expose exact verifier answers and code hidden tests. - **Resume/top-up:** terminal rows have no supported safe retry/top-up command; leases have no expiry/heartbeat/owner-checked completion. - **Provenance:** current exports lack a complete immutable campaign manifest and release checksums tied to source/config/database digests. - **Reporting:** some reports describe different campaign stages and do not carry commit/config/database checksums or supersession links. - **GDPO integration:** NeMo RL 0.7.0's NeMo Gym rollout path exposes only `total_reward`; Muse component rewards are not yet mapped to `reward1…K`. ## Reproducibility Pinned contracts: | Contract | Value | |---|---| | Python | `>=3.12,<3.13`; exercised with 3.12.11 | | NeMo Gym | 0.4.0 | | OpenAI client | `<=2.7.2`; resolved locally to 2.7.2 | | PyArrow | `>=23.0.1,<25`; resolved locally to 24.0.0 | | Campaign seed | 13,000,000 | | Schema version | `6.0-muse12-nemo` | | Current source template version | `2026-08-23.2` | | Split ratios | 90% / 5% / 5% | | Pilot target | 600 | | Planned target | 24,000 accepted and released | | Dataset and source license | MIT, subject to applicable provider terms | Use `uv sync --frozen`, preserve the immutable campaign manifest and release `MANIFEST.json`, and verify `SHA256SUMS` before consuming or redistributing an artifact. ## Dashboard The live campaign dashboard is a Rich TUI intended for the separate `24k dashboard` Herdr workspace: ```bash uv run python dashboard/tui.py ``` It reads the SQLite ledger in WAL-safe read-only mode and does not alter campaign state. ## License and research disclaimer The repository software, documentation, and synthetic dataset artifacts are available under the [MIT License](LICENSE), to the extent r0b0tlab has rights to license them. **Research-purpose disclaimer:** This dataset was collected and released for research purposes and is provided "AS IS" without warranty. Users are solely responsible for evaluating fitness for their intended use, complying with applicable law and provider terms, and for all downstream use, redistribution, fine-tuning, deployment, or other actions involving the dataset or derived materials. The authors and copyright holders accept no responsibility or liability for users' actions or outcomes. Model outputs remain subject to applicable Meta Model API terms. See [DATA_LICENSE.md](DATA_LICENSE.md) for the full license and disclaimer.