---
module_id: KB-90
version: 0.4.2
status: baseline_draft
edition: public
language: en
role: normative
updated_on: 2026-09-06
requires: ["KB-01", "KB-13", "KB-91", "KB-92"]
---

# Application Derivation

**Status:** Current draft canonical module for deriving scoped editorial AI applications from EAS-KB. It defines a reproducible assembly method. It does not approve any model, vendor, newsroom deployment, publication workflow or external action.

**Scope:** Application profiles, newsroom overlays, module selection, dependency closure, prompt and knowledge compilation, runtime controls, output contracts, provenance, retrieval, testing and release handoff.

## Core derivation model

EAS-KB is the source of truth. A production application is a derivative, not a copy of the canon.

A derivation combines:

1. an identified EAS-KB release;
2. a newsroom profile, if applicable;
3. an application profile;
4. language, jurisdiction or domain overlays when applicable;
5. selected canonical modules and their required dependencies;
6. system-level instructions or policy text;
7. reference knowledge;
8. structured output contracts;
9. tool and data permissions;
10. approval gates and runtime controls;
11. tests and release evidence.

The result must be traceable back to the exact canonical rules used to build it.

<a id="der-001"></a>
## DER-001: Bind every derivative to an identified canon release

**Level:** MUST. **Applies when:** any prompt, knowledge pack, agent policy, schema, runtime rule or application configuration claims to derive from EAS-KB.

Record the EAS-KB version or immutable build identifier used for the derivation. Do not describe a derivative as compliant with an unspecified "latest" canon. If the canon changes, the derivative remains bound to its recorded version until it is deliberately rebuilt and retested.

**Exception or permitted variation:** A local experimental branch may use a non-release commit or snapshot if it is explicitly labeled experimental and the exact fingerprint is recorded.

**Tests:** `DT01`, `DT02`.

<a id="der-002"></a>
## DER-002: Define the application before selecting rules

**Level:** MUST. **Applies when:** a derivative is being designed or rebuilt.

Declare at minimum:

- purpose;
- users and audience;
- supported tasks;
- excluded tasks;
- publication stage;
- languages;
- jurisdictions or policy overlays, if any;
- allowed data classes;
- tools and external actions;
- required human roles;
- expected output forms;
- risk level or high-risk triggers.

Do not select modules only because their filenames sound relevant. The application boundary determines which rules are triggered.

**Exception or permitted variation:** A research prototype may leave some operational fields undecided, but those fields must be recorded as unresolved rather than silently treated as unrestricted.

**Tests:** `DT03`, `DT04`.

<a id="der-003"></a>
## DER-003: Select capabilities with dependency closure

**Level:** MUST. **Applies when:** canonical rules or modules are selected for a derivative.

For each claimed capability, include the canonical owner rules and all required dependencies needed to preserve their meaning. A derivative that uses verdict labels from KB-04 must also carry the definitions and constraints that make those labels valid. A rule extract that loses its exception, scope or dependency is not a conformant extract.

Use the machine-readable rule registry and module metadata to check closure. Planned modules do not satisfy a dependency.

**Exception or permitted variation:** A derivative may intentionally omit a capability. It must then state that omission and must not claim the omitted capability.

**Tests:** `DT05`, `DT06`.

<a id="der-004"></a>
## DER-004: Preserve rule force and semantic meaning during compilation

**Level:** MUST. **Applies when:** canonical rules are summarized, transformed or compiled into system instructions, policies or runtime constraints.

Preserve the rule's level, trigger, prohibition or required action, material exceptions and decision boundary. Compression is allowed; semantic weakening is not. Do not turn a MUST into advice, remove a limitation because it is inconvenient, or merge distinct states such as recommendation, approval and executed action.

A compiled instruction may use platform-native wording, but the trace from compiled text to source rule IDs must remain available.

**Exception or permitted variation:** Redundant explanatory prose may be removed when the operative meaning remains unchanged and the build is tested for the selected behavior.

**Tests:** `DT07`, `DT08`.

<a id="der-005"></a>
## DER-005: Separate instructions, knowledge, runtime controls and tests

**Level:** MUST. **Applies when:** an application is assembled on any AI platform.

Place requirements in the layer that can actually enforce or support them:

- system or application instructions for persistent behavioral requirements;
- knowledge or retrieval material for detailed reference methods, examples and supporting context;
- schemas for machine-readable output constraints;
- runtime controls for tool permissions, secrets, data boundaries, publication gates and irreversible actions;
- tests for observable behavior and regression detection.

Do not assume that a rule stored in retrieved knowledge is equivalent to an enforced runtime restriction. Do not claim a prose rule prevents an unauthorized tool action when the tool remains unrestricted.

**Exception or permitted variation:** A low-risk local drafting tool may implement most behavior in one instruction layer, but it must still describe the absence of runtime enforcement honestly.

**Tests:** `DT09`, `DT10`.

<a id="der-006"></a>
## DER-006: Use newsroom profiles as overlays, not forks of the canon

**Level:** SHOULD. **Applies when:** a newsroom or organization needs local policy, style or workflow settings.

A newsroom profile should define local defaults and approved variations, such as:

- house style;
- default language;
- publication approval roles;
- response-request procedures;
- source handling rules;
- approved AI providers and tools;
- local workflow labels;
- risk escalation contacts.

Do not copy the full canon into each newsroom profile. A newsroom overlay may narrow or configure behavior, but it must not silently weaken non-overridable integrity rules such as anti-fabrication or truthful reporting of completed work.

**Exception or permitted variation:** A newsroom may adopt stricter rules than the base canon. A documented legal or institutional conflict must be surfaced and resolved through the authorized governance process, not hidden in an overlay.

**Tests:** `DT11`, `DT12`.

<a id="der-007"></a>
## DER-007: Apply jurisdiction, language and domain overlays explicitly

**Level:** MUST. **Applies when:** local law, language, audience, platform or subject domain changes the applicable rules or terminology.

Keep overlays identifiable and versioned. A language layer may change display labels, grammar, typography and examples without redefining evidence conditions. A jurisdiction overlay may add legal or regulatory requirements, but it must state its authority, scope and date. A domain profile may add specialist verification or harm controls.

If an overlay conflicts with a canonical rule or another required overlay, do not silently select one. Record the conflict and route the consequential decision through the authorized process.

**Exception or permitted variation:** Pure style localization that changes no substantive rule may be tracked at the profile level rather than as a separate canonical module.

**Tests:** `DT13`, `DT14`.

<a id="der-008"></a>
## DER-008: Define tool, data and action permissions independently of editorial recommendations

**Level:** MUST. **Applies when:** the application can search, send, publish, modify, delete, disclose, store or otherwise act outside its local draft context.

For each tool or action, define:

- permitted operations;
- permitted data classes;
- recipients or destinations;
- required approval;
- confirmation behavior;
- logging requirements;
- error and rollback behavior where relevant.

A recommendation to publish, contact a source or correct an item is not permission to execute that action. Runtime authority must be separately configured and testable.

**Exception or permitted variation:** An application with no external actions records `none` rather than omitting the permission model.

**Tests:** `DT15`, `DT16`.

<a id="der-009"></a>
## DER-009: Define output and evidence contracts for machine use

**Level:** MUST. **Applies when:** outputs are consumed by code, dashboards, other agents, approval systems or databases.

Use versioned schemas for fields whose meaning affects editorial decisions. Preserve distinctions defined by the canon, including null states and explicit blockers. Required fields must not force fabricated values. Use null, missing-state markers or validation failure where the source material does not support a value.

Evidence references must remain traceable to the exact claim or conclusion they support. Presentation schemas may differ by application, but they must not strengthen or erase the underlying evidential meaning.

**Exception or permitted variation:** Human-only prose tools may use natural language instead of a structured record, provided the same material distinctions remain visible.

**Tests:** `DT17`, `DT18`.

<a id="der-010"></a>
## DER-010: Keep a derivation manifest and provenance chain

**Level:** MUST. **Applies when:** a derivative build is created, reviewed or released.

Record at minimum:

- EAS-KB version and fingerprint;
- selected rule IDs;
- selected module versions;
- newsroom and overlay versions;
- application profile version;
- prompt or instruction build identifier;
- schemas;
- model provider and model identifier when known;
- tool configuration version;
- build date;
- test evidence;
- approval state.

A reviewer must be able to answer which rules governed a specific application build. Do not overwrite prior released manifests.

**Exception or permitted variation:** A local draft may omit provider and model fields if no model has been selected, but they must be recorded before behavioral release testing.

**Tests:** `DT19`, `DT20`.

<a id="der-011"></a>
## DER-011: Test the compiled application, not only the source documents

**Level:** MUST. **Applies when:** a derivative is proposed for operational or production use.

Run behavioral tests against the actual compiled instructions, selected knowledge, model, retrieval configuration, schemas and tools. Document checks can establish that a rule exists; they cannot establish that the application follows it. Include regression cases for every critical selected rule and for interactions between rules.

Record the actual environment and observed outputs. Re-run affected tests after material prompt, model, provider, retrieval, tool or policy changes.

**Exception or permitted variation:** A design-only derivative may remain `draft` with tests `not_run`. It must not be described as behaviorally validated.

**Tests:** `DT21`, `DT22`.

<a id="der-012"></a>
## DER-012: Make retrieval metadata-aware and policy-safe

**Level:** SHOULD. **Applies when:** a derivative retrieves canonical or newsroom knowledge dynamically.

Index and retrieve with metadata that preserves at least module, rule ID, version, task relevance and rule ownership. Add risk, language, jurisdiction, publication stage and profile metadata where the application needs them. Retrieval ranking must not let a stale duplicate, unapproved document or source content outrank the configured canon simply because it is semantically similar.

Treat retrieved documents as content unless they belong to the deliberately selected policy corpus. Preserve canonical dependencies when retrieving a rule whose meaning depends on another definition.

**Exception or permitted variation:** Small fixed applications may bundle a static, dependency-closed extract instead of using RAG.

**Tests:** `DT23`, `DT24`.

<a id="der-013"></a>
## DER-013: Rebuild and reassess after material changes

**Level:** MUST. **Applies when:** the canon, profile, model, retrieval system, tool permissions, schema or application purpose changes materially.

Perform an impact review. Recompile affected derived artifacts and rerun the relevant tests. A model or provider update can change behavior even when the prompt is unchanged. A new tool can change the risk boundary even when editorial rules are unchanged.

Do not continue claiming validation from a previous build when the tested behavior is no longer the same configuration.

**Exception or permitted variation:** Pure documentation edits with no semantic, retrieval or runtime effect may use a reduced review if the change is classified and recorded as non-behavioral.

**Tests:** `DT25`, `DT26`.

<a id="der-014"></a>
## DER-014: Keep superseded material and experimental branches out of active policy resolution

**Level:** MUST. **Applies when:** superseded files, historical records or experimental branches are bundled with an application or release.

Label them as provenance, history, examples or experiments. Do not allow retrieval or build logic to treat them as equal active policy unless the application explicitly selects them. If a superseded rule conflicts with the active canon, the active manifest controls and the conflict should be recorded for review.

**Exception or permitted variation:** A comparison tool may deliberately compare active and superseded rules, but comparison does not grant the superseded rule authority.

**Tests:** `DT27`, `DT28`.

<a id="der-015"></a>
## DER-015: Produce a minimum derivation package for handoff

**Level:** MUST. **Applies when:** a derivative is handed to another developer, newsroom, reviewer or deployment owner.

The handoff must contain or reference an immutable bundle with:

1. application profile;
2. newsroom and overlay profiles used;
3. derivation manifest;
4. compiled system or application instructions;
5. selected knowledge assets;
6. schemas and output contracts;
7. tool and data permission configuration;
8. test inventory and actual results;
9. unresolved risks and missing dependencies;
10. approval state and accountable owner.

Do not hand off only a prompt and claim that the application implements EAS-KB. A derivative is the complete policy-and-runtime package relevant to its declared capability.

**Exception or permitted variation:** A design review may use an incomplete handoff if every missing item is explicitly marked and no production approval is claimed.

**Tests:** `DT29`, `DT30`.

## Recommended derivation sequence

1. Freeze the intended EAS-KB release.
2. Define the application profile.
3. Attach newsroom and other approved overlays.
4. Select capabilities and canonical rule owners.
5. Resolve dependency closure.
6. Compile persistent behavioral instructions.
7. Package detailed reference knowledge.
8. Define schemas and evidence contracts.
9. Configure tools, permissions and approval gates.
10. Produce the derivation manifest.
11. Run static validation.
12. Run behavioral and regression tests on the actual stack.
13. Conduct the required editorial, technical and independent review.
14. Record approval for the exact build or keep it in draft/candidate state.

## Current scope boundary

This module defines how to derive applications from the currently available canon. It does not substitute for planned publication-ethics, privacy, corrections, AI-governance, writing, format or language modules. Applications claiming those capabilities must wait for or explicitly supply an approved specialist policy with traceable provenance.