Un bus para el contexto de la historia.
Todas las herramientas en él.

No. Una skill declara lo que es cierto sobre una historia; la herramienta dueña del executor decide qué hacer al respecto; una persona aprueba todo lo que llega a una audiencia. Una aprobación se concede a una versión concreta del texto, así que una reescritura reabre el gate en lugar de heredar la aprobación. Si una regla no se puede evaluar, la salida que protege sigue retenida y decide una persona.

Se trata de capturar su criterio. Las decisiones que dan forma a una historia ya existen —en un chat, en un nuevo briefing, en la cabeza de alguien— y desaparecen con el siguiente turno. Escribirlas en la historia deja cada decisión registrada y atribuida a quien la tomó. La persona deja de acarrear estado entre sistemas y vuelve a decidir.

Un solo escritor. El sistema de gestión de historias del medio crea la historia y es dueño de su sequence_number —nunca el cable de agencia, ni siquiera en un flash. Todo lo demás contribuye a través de su propia familia de mensajes. Cuando las skills discrepan, los gates se combinan por conjunción (basta un hold para que quede retenido), el cumplimiento normativo es fail-closed y una transformación nunca levanta un hold.

Cada redacción gestiona el suyo, como cualquier otra infraestructura de mensajería del edificio. Si se cae, las herramientas siguen funcionando por separado, como hoy, y se reconcilian al reconectar: nada depende del bus para seguir al aire. Como la historia se republica completa, una herramienta que vuelve lee un único objeto y queda al día.

No. SOM define un envelope y siete familias de payload que viajan sobre un bus pub/sub corriente. La única regla sobre topics es que un topic empieza por som. —y, de todos modos, un consumidor nunca deduce el tipo de payload a partir del topic; message_type es el único discriminador.

Una consulta de recuperación responde a una sola pregunta para una sola herramienta, y nadie más ve la respuesta. Una producción necesita lo contrario: un único estado que todas las herramientas lean igual, gates que sigan en pie cuando el trabajo pasa de un proveedor a otro y un registro atribuido de cada decisión. La posición del estándar es que los modelos son consumidores de SOM, no un sustituto.

Nunca. Los Assets son referencias. En la conexión con TAMS, una historia apunta a una Source URI y un rango de tiempo; un MAM o cualquier otro almacén se direcciona igual, mediante un locator. La vinculación de un medio a una historia ocurre en el acto editorial, nunca en la ingesta.

Se quedan. SOM no es un MAM, ni una escaleta, ni un producto, y no reemplaza nada. MOS sigue funcionando, con un puente que lo hace más inteligente, y lo que hayas construido con agentes sigue siendo tuyo. Basta un sistema para empezar.

Ponlo en extensions["com.{vendor}.{field}"]. Los consumidores DEBEN ignorar las claves de extensión que no reconozcan y NO DEBEN rechazar el mensaje por ellas. Los valores de enum de proveedor usan en cambio el prefijo x-: x-graphics_pack.

Porque los consumidores se incorporan tarde, se reinician y pierden mensajes. Un mensaje story.context es el estado completo de la historia, así que omitir significa ausente, no sin cambios. Un escritor que envía solo sus propios campos borra en silencio el trabajo de todos los demás: la declaración de conformidad lo considera el error más dañino que puede cometer una implementación.

En abierto. Cada cambio llega como un pull request a storyobjectmodel/som y cualquiera puede abrir uno. Dentro de 1.x solo se publican cambios aditivos; eliminar o renombrar algo espera a la 2.0, y un campo obsoleto sigue funcionando hasta entonces. Lo que aún no está resuelto figura en el registro abierto.

De nadie. El estándar es abierto y no tiene dueño. Los schemas, ejemplos, herramientas y skills son Apache 2.0; el texto de la especificación es CC BY 4.0. No hay cuota ni nada que firmar.

El método del que salió el modelo. Se toma una historia real después de su emisión y se rastrea cómo se movió realmente su contexto, salto a salto, entre personas y sistemas: dónde se creó conocimiento, dónde se perdió y quién lo llevó a mano. Story, Asset y Telling se transcribieron de esas sesiones en lugar de inventarse.