---
module_id: KB-92
version: 0.4.2
status: baseline_draft
edition: public
language: en
role: normative
updated_on: 2026-09-06
requires: ["KB-01", "KB-91"]
---
# Tests and Release Policy
## Purpose
This module defines how EAS-KB changes and derived applications should be checked before operational use. It separates document integrity, editorial review, behavioral evaluation and production approval.
## REL-001: Distinguish package integrity from behavioral validity
**Level:** MUST. **Applies when:** a release or derived application is evaluated.
Static checks can confirm files, identifiers, dependencies and references. They cannot prove that a language model will follow the rules, that retrieval will select the right material, or that a tool will respect an intended permission boundary. Behavioral claims require behavioral tests in the actual application environment.
**Exception or permitted variation:** None for claims of tested behavior.
## REL-002: Keep approval states explicit
**Level:** MUST. **Applies when:** material is described as draft, candidate, approved or production-ready.
A draft is authored material for review. A candidate has completed the checks required by its declared scope. Production approval requires an authorized owner, a defined deployment scope, completed relevant tests and documented acceptance of remaining risks. A checksum, successful static validator or instruction to continue drafting is not production approval.
**Exception or permitted variation:** A limited module or application may be approved for a narrowly defined use without approving the entire baseline.
## REL-003: Test the rules that matter to the declared capability
**Level:** MUST. **Applies when:** an application profile selects rules or capabilities.
Map selected rules to observable test cases. Include normal cases, uncertainty, missing evidence, conflicting evidence, prompt injection, sensitive data, unauthorized actions and relevant escalation paths. A critical rule should have at least one failure-oriented test.
**Exception or permitted variation:** Low-risk documentation-only derivatives may use a smaller test set if they cannot perform consequential actions and the limitation is explicit.
## REL-004: Record the tested configuration
**Level:** MUST. **Applies when:** behavioral results are used to support deployment or quality claims.
Record the EAS-KB version, application profile version, newsroom profile version where applicable, model provider and model, prompt or build identifier, retrieval configuration, tool permissions, schema version and test date. Results from a materially different configuration should not be treated as equivalent validation.
**Exception or permitted variation:** Fields that genuinely do not exist in a given architecture may be marked not applicable rather than invented.
## REL-005: Retest after material change
**Level:** MUST. **Applies when:** the model, prompt, retrieval layer, tools, permissions, selected rules or relevant external policy changes materially.
Identify affected capabilities and rerun the relevant regression tests. A previous pass should not be presented as validation of a materially different system.
**Exception or permitted variation:** Pure formatting or documentation changes that cannot affect behavior may use a reduced review.
## REL-006: Label independent review accurately
**Level:** MUST. **Applies when:** a review is described as independent, external or multi-agent.
Independent reviewers should receive the same frozen material without being given the conclusions of other reviewers in advance. Record reviewer identity or model configuration where appropriate and reconcile disagreements with reasons. Multiple analytical lenses applied by one reviewer are useful but are not independent review.
**Exception or permitted variation:** A self-review is acceptable when clearly described as such.
## REL-007: Protect sensitive material in evaluation records
**Level:** MUST. **Applies when:** tests or reviews involve confidential, personal or otherwise sensitive information.
Use synthetic or minimized fixtures where possible. Do not expose source identities, credentials, unpublished sensitive material or unnecessary personal data in public test logs. Record simulation honestly rather than implying that a real contact, publication or external action occurred.
**Exception or permitted variation:** Controlled secure environments may retain additional evidence when required by newsroom policy or law.
## REL-008: Treat runtime controls as separate from prose policy
**Level:** MUST. **Applies when:** a derived application can send, publish, modify, delete, contact, purchase, disclose or otherwise take consequential external action.
The application should enforce permissions, approval gates, recipient boundaries, data boundaries, monitoring and suspension independently of the text of the policy. A written rule alone is not a technical access control.
**Exception or permitted variation:** A drafting-only application may have no external-action capability, but its scope should still be accurately described.
## Test inventory
The machine-readable inventory is stored in `../governance/tests.json`. Test entries can be complete fixtures or structured test designs. Entries marked `not_run` are not evidence of observed model behavior.
## Suggested release sequence
1. Validate package structure and references.
2. Review the selected editorial rules and local overrides.
3. Build the derived application and record its configuration.
4. Run applicable behavioral and contract tests.
5. Review high-risk failures and unresolved exceptions.
6. Complete any required independent, legal or specialist review.
7. Record the authorized deployment scope and accountable owner.
8. Monitor operational behavior and maintain a rollback or suspension path.
## Baseline status
The public EAS-KB package is distributed as a reusable draft baseline. It is not, by itself, a production approval for any application or newsroom.