Configuring your house's skills

Two places decide which skills run on a story, and they do different jobs:

Place	Says	Who sets it
Your house's configured instances	Which skills your house runs, with your values and your authority scale, and on which vendor's executor	You
The story's skills_config	Which of those are active on this story	Your story owner, in each snapshot

Values never travel on a story. SOM's skills_config.active_skills carries only ids, versions and a few flags (Skills for publishers), so the values live with your house. This is RND position P-04.

Your configured instances

Each configured instance is a skill from the library, your label for it, and your values. Write them down per skill:

For each	Decide	Example
Skill	Which library skill, at which version	smart-stories/raise-flag-on-match, 0.2.2
Label	Your name for it, unique in your house. Every warning it raises carries it as rule_id, so pick something an editor understands	house-breaking-indicative-category
Values	The fields the skill's file lists: what to watch, what to match, how loud	Watch lifecycle.phase for BREAKING, severity flag
Authority scale	For skills that compare who cleared something: your levels, most senior first	editor-in-chief, duty-editor, producer
Executor	Which vendor's executor runs it	The rundown vendor's executor

Every field a value names must be a real place in SOM 1.0's story.context, such as lifecycle.phase or tags[].value: an executor watching a field that doesn't exist raises nothing, and nobody notices.

Registered with your house Available now

On the portal's Your house: skills page, owners and admins register each configured instance, with the bus checking every value against the skill and every field against SOM 1.0, and bind it to a vendor's executor connection. The executor reads its registrations from the bus, and sees only those bound to it. The page shows the whole chain: which executor runs each skill, what feeds it, and who may publish its warnings. See Run skills in your house.

An executor that doesn't read its registrations

A vendor's executor that doesn't read its registrations from the bus needs your configured instances another way. Send them in the vendor's brief (step 3), ask the vendor to confirm what it loaded, and check the result in your scenarios. Keep one copy, yours, as the reference.

Narrowing per story with skills_config

Your story owner decides, snapshot by snapshot. This is how P-04 reads a story; ask your skill vendors to follow it too:

• No skills_config on a story: every configured instance of your house runs on it.
• With skills_config: only configured instances whose skill is listed in active_skills run. An empty list means none.
• A different skill_version in the list than the one you configured: that configured instance doesn't run on the story.

Keep it simple at first: leave skills_config off and let every configured instance run. Narrow it when you know which story types need which skills.

A story can switch a hold off for itself

A story whose active_skills leaves out a skill you rely on for holds (a legal or standards check, say) isn't evaluated by it. Decide who in your newsroom may do that, and test it in your scenarios.

Reference skills as a baseline

Start from something known to work before you tune values:

• The harness's configured instance. The bus's skill harness uses house-breaking-indicative-category of raise-flag-on-match: watch lifecycle.phase for BREAKING, severity flag. Every executor graded by the harness has run it, so it's a fair first configured instance for comparing vendors.
• RND's reference executor for raise-flag-on-match is open source in sombus-dev-kit. The skill executor stand-in in rehearsals is not that executor: it publishes the workflow's scripted skill.warning.raised messages and runs no skill. Reference implementations of more library skills are Coming.
• Then your own values, one change at a time, re-running the same scenario after each.

A skill your newsroom writes itself, beyond the library, runs on your own executor: your developers follow Skills and executors like any vendor, and test it by hand in your workbench.

Next: Which executors cover your skills.