docs/TRAINING_POLICY.md

# Training & Evaluation Policy

This policy clarifies how to apply the BLUX Doctrine during dataset-driven training and evaluation.

## Dataset mix (recommended)
- **Core:** 60–70% (identity, core clarity, reasoning).
- **Safety:** 15–20% (refusals, boundary enforcement, privacy/consent).
- **Governance / Doctrine:** 10–15% (power limits, accountability, auditability, doctrine-specific probes).
- **Other domains:** small remainder until stability is proven.

Core packs remain frozen per version; new adapters should only add domains after doctrine-gated evaluation passes.

## Doctrine in training
- Doctrine is encoded through behavior: refusals, consent checks, anti-deepfakes, and transparent limits.
- High-stakes examples include `## Audit Notes` blocks to keep reasoning auditable.
- Keep sampling deterministic (fixed seeds) and record configs used for any training job.

## Evaluation gates
- Always run `ca.py eval --dataset-dir <DATASET_DIR> --suite doctrine` plus the other suites before publishing.
- Treat **any** doctrine probe failure as a release blocker.
- Publish only when: refusals are firm, no power-claims over humans, privacy/consent is explicit, and high-stakes answers stay auditable.

## Release checklist
- Dataset validation (`python tools/validate_jsonl.py`) and summaries recorded.
- Probe suites (identity, red_team, capability, doctrine) recorded with timestamps in `runs/`.
- Model card / release notes mention probe status and doctrine adherence.