RND positions

Where SOM 1.0 and the skill library 0.2.2 are silent, or disagree with each other, an executor still has to do something. This page says what RND's reference executor and test tools do, and why.

RND positions, not the standard

Each entry is RND's position. It isn't part of SOM or the skill library, and nothing here is endorsed by the SOM working group. None has been put to the working group yet. We intend to offer each one, and to withdraw it if the working group decides otherwise. Where a test result rests on a position rather than on SOM, it's reported as a note that links here, never as a failure. The one exception is P-15's 30-second limit: a skill harness case with no warning in 30 seconds fails.

The ids are stable. Proposed positions are open for review and may change; decided ones are settled for this suite.

Id	Position	Status
P-01	The schema, not the samples, shapes a warning	Proposed
P-02	system_type: the SOM value closest to the tool	Proposed
P-03	recall_on matches message_type; one event for the three ingest names	Proposed
P-04	Registered configured instances, narrowed by the story's active_skills	Decided
P-05	skill_executor_id is read, not acted on	Proposed
P-06	Other triggers are wake-ups against the latest snapshot	Proposed
P-07	Never evaluate an older snapshot	Proposed
P-08	Raise on open and on change; silence while unchanged	Proposed
P-09	skill_warning_ref names the declaration	Proposed
P-10	Store before publish; a retry is the same bytes	Proposed
P-11	Nothing on the bus when a declaration closes	Proposed
P-12	Terminal stories raise nothing	Proposed
P-13	The story owner turns a flag into a gate	Decided
P-14	A configured instance never triggers on its own warning	Proposed
P-15	5 seconds to emit, 30 to fail	Decided
P-16	Authority is compared on a house-supplied scale	Decided
P-17	Tag matching ignores the scheme	Proposed

P-01

The schema, not the samples, shapes a warning. Every skill's sample warning fails the skill-warning schema: warning_id is "wrn-…" where the schema wants a UUID, and skill_warning_ref is null where it wants a string. One skill also stamps a system_type outside SOM's list.

• Position: follow the schema. warning_id is a UUIDv7, skill_warning_ref a string (P-09), system_type a SOM value (P-02). Everything else in the samples (what fields mean, rule_id as the configured instance's label, what goes in detail and blocks) is followed as written.
• Why: SOM requires every published payload to validate, and the library itself says the schema is the source of truth.

P-02

system_type: the SOM value closest to the tool. The library says an executor stamps its tool's own type (rundown, mam, playout…). Only graphics and archive of those are in SOM 1.0's list, and the envelope is strict.

• Position: use the SOM value that best describes the tool the executor sits beside. The library's type may be repeated in system_name. The bus doesn't record it anywhere yet: a registration has no field for it.

  Library type	system_type
  graphics	graphics
  archive	archive
  planning, rundown	ncs
  playout	automation
  compliance_hub	compliance_engine
  mam, cms, ingest, distribution, discovery, transcription, verification, multimodal, markets_data	custom

• Why: it keeps to the library's intent (tools have executors) without breaking the envelope, and it's reversible: new values are a 1.x change. skill_worker also validates, and remains a valid choice on the bus.

P-03

recall_on matches message_type. The library calls recall_on entries topics, but on the wire topic is free text.

• Position: a recall_on entry matches the envelope's message_type exactly, never topic. asset.ingested, media.ingested and media.asset.ingested are one event: recalling on any subscribes to all three. telling.proposed isn't satisfied by telling.started.
• Why: SOM makes message_type the only thing that selects a payload. Treating the three ingest names as one avoids silently missing whichever a producer chose.

P-04

Registered configured instances, narrowed by the story's active_skills. A configured instance's values can't travel in the story's skills_config, whose items carry only ids, versions and a few flags.

• Position: values always come from the house's registration. A story with no skills_config gets every configured instance the house registered. A story with one gets only those whose skill_id is in its active_skills (an empty list means none). If the listed skill_version differs from the registered one, that configured instance isn't evaluated on that story, and the executor logs why.
• Why: it honours the one thing SOM lets a story say ("these skills are active here") without inventing a place for values SOM doesn't have.
• On the bus: a house registers its configured instances, and an executor reads them.

P-05

skill_executor_id is read, not acted on. It's one string, but a story can have one executor per tool.

• Position: logged when it names another executor; never used to skip an evaluation.
• Why: acting on it would let one field switch off every other tool's executor for the story.

P-06

Other triggers are wake-ups against the latest snapshot. Skills recall on messages that aren't snapshots, most without a 1.0 schema.

• Position: the executor subscribes to story.context and keeps the latest snapshot per story. Any other trigger re-evaluates against it, with causation_id set to the trigger's message_id. It reads no field of a payload without a 1.0 schema. No snapshot held, no evaluation.
• Why: evaluations then depend only on complete story state and the configured instance, so they're deterministic, whatever shape those messages end up with.

P-07

Never evaluate an older snapshot.

• Position: an executor keeps the highest sequence_number it has evaluated per story and doesn't evaluate one at or below it.
• Why: replays, redrives and buses without per-story order can deliver an old snapshot after a new one. Evaluating it would reopen declarations that have closed.

P-08

Raise on open and on change; silence while unchanged.

• Position: a configured instance publishes when a declaration opens, and again only when the warning it would publish now differs from its last one for that declaration in anything but warning_id. Otherwise it publishes nothing.
• Why: consumers see every change and no noise. Routine re-publication buries the holds that matter.

P-09

skill_warning_ref names the declaration. The schema requires a string and gives it no meaning.

• Position: <rule_id>/<scope>/<n>, for example house-breaking-indicative-category/story:hurricane-2026-0911/1. Every warning of one declaration has the same value; n starts at 1 and goes up each time the condition reopens after closing.
• Why: consumers can group a declaration's warnings and find the latest, which nothing else in the payload allows.

P-10

Store before publish; a retry is the same bytes.

• Position: key every emission on (configured instance, trigger message_id), store the complete outgoing message before publishing, and publish the stored bytes on any retry or redelivery. Keep the record for at least the bus's 7-day idempotency window.
• Why: the bus recognises a retry by message_id and content, and content includes the envelope timestamp. A rebuilt message is a second warning, or a 409.

P-11

Nothing on the bus when a declaration closes. SOM 1.0 has no message for a closed warning, and system.audit can't target a story.

• Position: publish nothing on closure; record it in the executor's own state and log. Consumers read the current position from the story (the gate, the watched field), not from the absence of a warning.
• Why: the alternatives either use a "raised" message to say the opposite, or invent a message type the working group hasn't named. We intend to propose a closing message to the working group; none has been proposed yet.

P-12

Terminal stories raise nothing.

• Position: when a story becomes KILLED, SPIKED or ARCHIVED, its open declarations close and no new ones open.
• Why: a terminal story doesn't come back, so nothing is left to withhold or review.

P-13

The story owner turns a flag into a gate. Decided. Raise skills may only publish warnings, yet hold-while-flagged reads editorial_gates. Something has to carry a flag into a gate.

• Position: the system that publishes the story's story.context (its owner) acts on the raise skill's warning and adds an editorial_gates entry in its next snapshot: gate_type from the flag, status: PENDING, required_by_skill set to the warning's skill_id and gate_rule_id to its rule_id. Executors never publish story.context, and the bus never changes or authors messages.
• Why: the schema already has required_by_skill and gate_rule_id on a gate. It keeps one writer per story. An executor that published snapshots would need every other system's state, and would race the owner.
• Consequence: the flag-to-hold chain works only where the story's owner implements this. Who the owner is, and how a story passes from one system to another: Story ownership.

P-14

A configured instance never triggers on its own warning.

• Position: a skill.warning.raised with the configured instance's own skill_id and rule_id isn't a trigger for it. Other configured instances may recall on it.
• Why: hold-while-flagged recalls on warnings; without this rule a configured instance could wake itself in a loop.

P-15

5 seconds to emit, 30 to fail. Decided: the 30-second limit is applied in the skill harness; the 5 seconds is a recommendation the bus doesn't check.

• Position: an executor should publish within 5 seconds of receiving its trigger. The skill harness in test runs fails a case at 30 seconds, and passes a no-trigger case if nothing arrives in 30 seconds. When the skill dev kit ships, it will run the same harness, with the same limits.
• Why: every library skill is a comparison against one snapshot. 30 seconds leaves room for cold starts and queue polling on a shared Sandbox.

P-16

Authority is compared on a house-supplied scale.

• Position: as the library assumes: authority is a role on the assertion's provenance, ranked on an ordered list the house supplies with the configured instance, most senior first. An authority not on the list ranks below the declaring one, so the declaration stands.
• Why: it's the library's own working assumption, and it fails closed.
• On the bus: the scale is the registration's authority_scale; every authority a configured instance names must be on it.

P-17

Tag matching ignores the scheme.

• Position: a configured instance that watches tags[].value matches the value whatever the tag's scheme, as the library does today.
• Why: scheme-qualified matching would change which stories a configured instance sees. SOM lists it as an open question (open register, §2, "Scheme-qualified tag matching").