# Editorial AI Standard Knowledge Base (EAS-KB)

**Edition:** Public baseline  
**Version:** 0.4.2 Draft  
**Date:** 2026-09-06

EAS-KB is a platform-independent editorial knowledge base for designing editorial AI prompts, assistants, agents, workflows and newsroom tools. It provides a structured starting point for editorial reasoning, source handling, verification, publication ethics, privacy, corrections, AI governance and application design.

## What this package is

EAS-KB is a **baseline reference framework**, not a universal, complete or ideal editorial standard. It is intended to be adapted to the needs of a specific newsroom, audience, jurisdiction, language, workflow and risk profile.

The package can be used as:

- a reference for writing system prompts and editorial instructions;
- a source for creating task-specific knowledge packs;
- a basis for fact-checking, monitoring, editing, research and publication workflows;
- a policy source for editorial AI applications;
- a starting point for newsroom-specific profiles, tests and runtime controls.

It should not be treated as legal advice, as a substitute for an organization’s own editorial policy, or as evidence that a particular AI application is safe or production-ready. Local law, newsroom policy and specialist review may require stricter or different rules.

## How to use it

The recommended approach is to select and adapt only the modules relevant to the intended application. A typical derivation is:

```text
EAS-KB baseline
+ newsroom profile
+ application profile
+ language / jurisdiction / domain requirements
= derived application policy
```

The derived policy can then be converted into system instructions, a scoped knowledge pack, output schemas, tool permissions, approval gates and evaluation tests. `canonical/90-KB-application-derivation.md` describes this process in more detail.

The entire package does not need to be loaded into every AI system. Behavioral instructions should be placed where the target platform actually enforces behavior, while reference material can remain in a knowledge or retrieval layer.

## Current scope

The current baseline includes modules for:

- core principles and rule hierarchy;
- editorial judgment and input analysis;
- sources and research;
- verification;
- fairness, independence and public interest;
- privacy, harm and sensitive content;
- corrections and accountability;
- AI editorial governance;
- workflow, output control and escalation;
- application derivation;
- reference sources;
- testing and release policy.

Writing, enrichment, format-specific guidance, language profiles and final quality-assurance modules are still incomplete or planned. The absence of those modules should be taken into account when building a derived application.


## Human-readable editorial modules

Canonical modules are intended to work as editorial reference documents, not only as technical specifications. Rule identifiers and machine-readable registries support derivation and testing, but the main Markdown modules should remain understandable to editors, trainers and prompt designers without requiring the registry.

## Package structure

### `canonical/`
Normative and supporting EAS-KB modules.

### `governance/`
Machine-readable rule, test and source registries.

### `schemas/`
Schemas for application profiles, newsroom profiles and derivation manifests.

### `examples/`
Synthetic examples and machine-readable contracts. They are examples only and are not editorial evidence.

### `profiles/`
Minimal example profiles showing how newsroom and application overlays can be structured.

### `tools/`
A local validator for checking package integrity and detecting development-only wording in the public edition.

## Adaptation principles

When adapting EAS-KB:

1. Preserve core truth, evidence and authorization boundaries.
2. Add local law, newsroom policy, language and domain requirements where needed.
3. Do not assume that one source hierarchy, workflow or publication threshold fits every newsroom.
4. Test the derived application with realistic scenarios before relying on it operationally.
5. Keep a record of the EAS-KB version and any local overrides used to build the application.
6. Reassess the configuration after material model, tool, retrieval or policy changes.

## Status and limitations

This public edition is a **draft baseline**. It has not been certified by any external standards body and does not claim endorsement by the organizations cited in the reference materials. The cited standards and guidance informed parts of the framework, but EAS-KB is an independent synthesis.

Static package validation checks structure and references only. It does not prove that a language model will follow the rules. Behavioral evaluation, newsroom review and application-specific approval remain separate steps.