Skills for publishers

Available now A skill reads a story and raises a warning for editorial

attention: a claim with no source, a story marked breaking without a senior sign-off, a lower third about to air behind a pending standards gate. It is a second pair of eyes. It never changes the story.

This page is the newsroom's view. Your skill vendors read Skills and executors, which says the same things from the code's side.

Three things to tell apart

Term	To a newsroom	Who owns it
Skill	A written rule from the SOM skill library, such as raise-flag-on-match: what to watch, and how loud to be. A specification, not software	The SOM working group's library (0.2.2 on this bus)
Configured instance	That rule with your values: "flag any story whose phase reads BREAKING, cleared by a duty editor or above". It has your label, which every warning it raises carries as its rule_id	You, the house
Executor	The vendor software that runs your configured instances, usually beside one tool: a rundown, a media store, a CMS	A vendor, or you for an in-house one

One executor can run many configured instances. Two vendors' executors can run the same skill with different values. You decide which runs where: see Configuring your house's skills.

The skill fields on a story

A story's story.context may carry skills_config.active_skills: the skills active on this story. Each item names a skill (skill_id, skill_version) and carries four more fields SOM 1.0 defines:

Field	Values SOM allows	What it tells you
skill_type	NEWSROOM, VENDOR, REFERENCE	Required. Where the skill comes from. The names suggest a skill your newsroom defined, one a vendor supplies, and one from the SOM skill library
disclosure_level	L1, L2, L3	Optional. A disclosure tier
migration_policy	HOT, COLD, GATED	Optional. How a change of skill is rolled out
skill_priority	CRITICAL, NORMAL, LOW	Optional. How much the skill matters when several fire on one story

SOM names these values, but doesn't define them yet

SOM 1.0's schema lists the values; it doesn't say what each one means or what a system must do with it. How to rank skills that fire on the same story is an open question in SOM's own glossary. So:

• The bus checks the values (a skill_type outside the list is refused, like any schema error) and carries them to every receiver. It doesn't act on them.
• RND's reference executor doesn't act on them either. Only skill_id and skill_version decide what runs on a story (RND position P-04).
• If you use them, agree what they mean in your house, write it in your vendors' brief, and check it in your scenarios. Don't assume two vendors read CRITICAL the same way.

hold, flag and inform, in editorial terms

Every warning has a severity. Each skill has a range it may use; your values choose within it.

Severity	In the newsroom	What systems should do
hold	Stop. "This doesn't go out until it's cleared." The warning lists what is withheld (blocks) and can't be overridden (non_overridable)	Every tool that would output an affected field withholds it: graphics doesn't commit, playout doesn't air, the CMS doesn't publish. Any one hold means held
flag	Look at this before it goes. A person should review it	Show it to the editor. The story's owner may turn it into an editorial gate, and then the gate holds output until it's cleared
inform	For your information. Advisory	Show it; nothing waits for it

The bus doesn't enforce any of them. It checks that the warning is valid SOM and delivers it; the tools that receive it act on it. So "graphics honours a hold" is something you test, product by product: see Skills in your scenarios.

Who acts on a warning

Who	Does	Where it's written
The executor	Raises the warning, once per condition, with the story's correlation_id and the snapshot that caused it. Never edits the story	How an executor behaves
The story's owner (usually your newsroom system)	Shows it to the editor. For a flag that needs sign-off, adds an editorial gate in its next snapshot: PENDING, naming the skill and the configured instance	RND position P-13, Story ownership
The editor or standards desk	Decides. Clears the item, recorded as system.audit, and the owner publishes the gate as approved	Your newsroom's own process
Every tool that outputs (graphics, playout, CMS, prompter)	Withholds held fields while a hold or a pending gate stands; goes ahead once cleared	Each vendor's product
The bus	Checks and carries every message. Never enforces, never authors, never changes a story	Verdicts

Two consequences to plan for:

• The flag-to-gate chain works only where your story owner implements it. Ask your newsroom-system vendor. If nobody does it, a flag is just a notice, and graphics goes ahead.
• A warning is never withdrawn on the bus. SOM 1.0 has no message for it. When the condition stops holding or is cleared, the executor simply raises nothing more; what tells your tools it's over is the gate being approved, or the clearance in system.audit.

Next

• Configuring your house's skills: which skills run, with which values.
• Which executors cover your skills: evidence per vendor.
• Skills in your scenarios: testing the whole chain.