Scrydon

NATO OODA — tutoriel complet

Importez le pack de réponse aux incidents en zone grise NATO et exécutez une veille fictive de l'opération Aegean Sentinel à travers la boucle OODA complète — DÉTECTER, FUSIONNER, ANALYSER, DÉCIDER, EXÉCUTER, RÉVISER.

Objectif

À l'issue de ce tutoriel, vous aurez importé le Pack Scrydon NATO — Réponse aux incidents en zone grise (Flanc Est) dans votre tenant, créé une nouvelle instance pour la veille fictive de surveillance des sanctions maritimes de l'Opération Aegean Sentinel, guidé les contacts de surveillance à travers la boucle OODA complète, et produit un rapport après action signé.

La LtCdr Sofia Konstantinou, officier de renseignement J2 à bord du FGS Wernicke, et le Commodore Halvor Sletten, commandant de la SNMG2, sont nos principaux fictifs. L'Opération Aegean Sentinel, les pistes de contacts, les rapports de renseignement et le mémorandum de décision de ce tutoriel sont entièrement fictifs et existent uniquement pour illustrer le flux.

Le pack NATO livre un sous-répertoire d'ontologie vide aujourd'hui (objectTypes: [], linkTypes: []). Lorsque vous l'importez, l'étape de reliaison de slugs ne trouve rien à résoudre — aucune instance d'objet typée de style BoardMeeting n'est matérialisée pour l'instant. Le même format de pack permettra à une cellule de doctrine d'étendre l'ontologie avec les types d'objets Track, Contact, Decision, Engagement dans une future version ; le tutoriel indique où ceux-ci s'intégreraient.


Prérequis

Vous disposez d'un déploiement Scrydon avec les surfaces agentic et ontology activées. Définissez les variables d'environnement suivantes dans votre shell pour l'étape d'importation :

export SCRYDON_URL="https://<your-scrydon-url>"
export ORG_ID="<your-org-id>"
export SESSION_COOKIE="$(cat ~/.scrydon/session-cookie)"  # ou collez depuis le navigateur

Le modèle référence trois workflows système sous requirements.systemWorkflows. Jusqu'à leur déploiement, ces actions de type workflow se dégradent en checklists manuelles dans l'interface runtime, ce qui guide néanmoins proprement le tutoriel.


Étape 1 — Télécharger le pack

Le pack est un flux gzip de ≈ 6 Kio contenant pack.json, un ontology/manifest.json vide, et process-flow/manifest.json (six stages, 10 personas, le DAG de tâches complet).

Télécharger nato-1.0.0.scrydon-pack.tar.gz

mkdir -p nato-tutorial && cd nato-tutorial
curl -O https://docs.scrydon.com/static/process-pack-examples/nato-1.0.0.scrydon-pack.tar.gz

Étape 2 — Inspecter le pack

bunx @scrydon/sdk-authoring pack inspect nato-1.0.0.scrydon-pack.tar.gz

Sortie attendue :

Pack:
  Package:  nato@1.0.0
  Contents: ontology@1.0.0, process-flow@1.0.0
  Install order: ontology → process-flow
  ontology: nato@1.0.0
  process-flow: nato (6 stages)

Le DAG de tâches du sous-répertoire process-flow est volumineux — plus de 30 tâches réparties sur les six stages avec des dependsOnTaskSlugs inter-stages. L'inspecteur exécute le contrôle de cycle du DAG ; tout cycle ferait échouer l'inspection ici, avant le téléversement.


Étape 3 — Téléverser le pack

curl -X POST "$SCRYDON_URL/api/packs/import?organizationId=$ORG_ID" \
  -H "Cookie: $SESSION_COOKIE" \
  -F "file=@nato-1.0.0.scrydon-pack.tar.gz"

Réponse 200 attendue :

{
  "packageId": "nato",
  "version": "1.0.0",
  "bundleHash": "sha256:...",
  "ontology": {
    "branchId": "br_01HF...",
    "alreadyInstalled": false,
    "slugs": { "objectTypes": {}, "linkTypes": {} }
  },
  "processTemplate": {
    "processTemplateId": "pt_01HF..."
  }
}

Le pack NATO n'est plus auto-installé sur chaque tenant — il est livré comme exemple téléchargeable. Vous pouvez l'importer avec le slug nato non modifié ; créez un fork avec un slug personnalisé uniquement si un fork en-tenant d'une version antérieure existe encore avec le même slug.


Étape 4 — Ouvrir une nouvelle instance d'opération

Naviguez vers $SCRYDON_URL/process-flows. La carte NATO — Réponse aux incidents en zone grise (Flanc Est) apparaît sous le tag Defense & Security. Cliquez sur Nouvelle instance depuis le modèle, nommez l'instance Operation Aegean Sentinel.

L'instance s'ouvre sur la vue tracker par défaut. Six lanes de stages apparaissent :

  • SENSE — surveillance passive et fusion de capteurs (8 tâches).
  • FUSE — corrélation de pistes uniques à travers les types de capteurs (5 tâches).
  • ANALYSE — évaluation du pattern de vie et de la menace (6 tâches).
  • DECIDE — boucle d'autorisation de tir du commandant (4 tâches).
  • EXECUTE — action cinétique / non cinétique par les commandements de composante (5 tâches).
  • REVIEW — revue après action, mise à jour de la doctrine (4 tâches).

La première tâche — Ouvrir le Briefing Intel du jour — est assignée à la persona operator et débloquée. Tout le reste est conditionné.


Étape 5 — SENSE : constituer le tableau de la surveillance

Ouvrez Ouvrir le Briefing Intel du jour et collez le briefing de situation de démonstration dans l'action document :

Télécharger 01-situation-brief.md — ordres de mission de l'Opération Aegean Sentinel : surveillance de la « boîte Égée » 34–36°N / 25–28°E pour la navigation sous sanctions, du 8 au 22 mars 2026.

L'OOD parcourt ensuite les tâches du stage SENSE :

TâchePersonaEntrée de démonstration
Exécuter la détection AIS des naviresoperatorLe flux AIS de 24 heures pour la boîte Égée. Trois pistes suspectes sont élevées.
Exécuter la détection satellitaire des naviresoperatorTasking de l'hélicoptère ISR NATO ; les résultats atterrissent dans la section IMINT du produit de fusion.
Exécuter la détection radar UAVoperatorAucun contact UAV dans ce scénario ; marquer « sans contact » pour l'exhaustivité.
Exécuter la détection SIGINT de brouillageoperatorAucun brouillage détecté dans la boîte ; un auxiliaire sous pavillon Elthérien sur VHF maritime standard.
Confirmer les détections de convoioperatorLe journal AIS identifie un auxiliaire de convoi Elthérien à l'est de la ligne de restriction.

Télécharger 02-ais-contact-log.md — le journal de contacts de huit heures de l'OOD alimentant le briefing quotidien à 0600Z. Trois Pistes d'intérêt (TOI) élevées selon les règles d'indicateurs suspects.

Marquez toutes les tâches SENSE comme terminées. Le DAG ouvre le stage FUSE.


Étape 6 — FUSE : construire le tableau multi-sources

Le stage FUSE corrèle chaque TOI à travers l'AIS, l'IMINT (survols en hélicoptère), le HUMINT (réseau d'agents portuaires NCAGS à Chypre et en Crète), et les données de pattern de vie des 12 derniers mois. La persona intel-analyst pilote ce stage.

Le livrable unique est le Produit de fusion de renseignement, une évaluation multi-sources avec des niveaux de confiance nommés :

Télécharger 03-intel-fusion-product.md — le produit de fusion attribuant une évaluation à confiance moyenne à élevée d'un transfert de cargaison navire-à-navire imminent à 35°15′N 26°45′E entre le M/V Polaris Star (TOI-A) et le M/V Wasilla Trader (TOI-B).

Collez le produit de fusion dans la tâche Publier le produit de renseignement fusionné et marquez comme terminée. Une fois approuvé par l'analyste de renseignement senior, le stage ANALYSE s'ouvre.


Étape 7 — ANALYSE : évaluer et escalader

Le stage ANALYSE exécute les tâches d'analyse de pattern de vie et d'évaluation des menaces en parallèle :

  • Calculer l'évaluation de confiance — recalcule les chiffres de fusion, met en évidence la confiance mono-source vs multi-source ;
  • Comparer avec la base de référence du pattern de vie — croise le jeu de données AIS des 12 mois pour les co-localisations antérieures des deux TOI (aucune trouvée dans ce scénario) ;
  • Étiqueter les actifs tiers — identifie l'auxiliaire sous pavillon Elthérien Vostok-3 comme le lien onward probable ;
  • Rédiger le mémorandum d'escalade au commandant — la recommandation de l'analyste pour une action DP-3.

Une fois que le commandant accuse réception du mémorandum d'escalade (l'action approval de porte), le DAG ouvre le stage DECIDE.


Étape 8 — DECIDE : autorité de tir du commandant

Le stage DECIDE est la porte de décision critique de la boucle OODA. Quatre tâches, assignées à la persona commander avec révision aco-shape-liaison et legal-officer (DROIT) :

TâcheCe que le commandant décide
Réviser le mémorandum d'escaladeAccepter / rejeter / demander plus de renseignements
Confirmer l'applicabilité des ROEL'officier de droit (legal-officer) confirme que la surveillance RCSNU 2683 est autorisée ; pas d'abordage sans autorisation HQ
Autoriser l'action de composanteLe commandant signe le mémorandum de décision
Notifier ACO / SHAPELe aco-shape-liaison pousse la notification en haut de la chaîne de commandement

Télécharger 04-commanders-decision-memo.md — le mémorandum de décision signé du Commodore autorisant l'approche de présence visible, la communication radio pont-à-pont, l'AIS sur demande, et une demande d'autorisation d'abordage au HQ.

Après la signature du commandant (l'action approval), le stage EXECUTE s'ouvre.


Étape 9 — EXECUTE : les composantes exécutent l'ordre

Le stage EXECUTE répartit l'intention du commandant aux commandements de composante. La persona naval-component (et air-component pour le support AWACS) effectue l'approche de présence visible :

  • Positionner la composante navale — le FGS Wernicke se rapproche à 4 NM de TOI-A ; le HMCS Charlottetown se rapproche à 4 NM de TOI-B.
  • Couverture AWACS en station — sortie SE-26-032 du 14 mars 0330Z au 0930Z.
  • Communication radio pont-à-pont — les deux navires de guerre héèlent, exigeant l'AIS-on. Refusé par les deux navires.
  • Soumettre la demande d'autorisation d'abordage au HQ — envoyée à 0612Z, accordée à 0904Z.
  • Rendre compte du contact au HQ — OPREP-3 horaire tout au long de la fenêtre.

Le rendez-vous est interrompu à 0743Z, avant que l'autorisation d'abordage soit accordée. Le commander décline l'exécution de l'abordage. Le DAG ouvre REVIEW.

Dans les scénarios de corridor de câbles pour lesquels le modèle a été initialement rédigé, les tâches EXECUTE comprennent « intercepter le navire approchant le câble » et « engager le UAV conformément aux ROE autorisées » — assignées respectivement à naval-component et air-component. Aegean Sentinel utilise la même surface de tâches pour le suivi de surface et la surveillance non cinétique ; les libellés des actions sont appropriés pour l'un ou l'autre scénario.


Étape 10 — REVIEW : la cellule de doctrine boucle la boucle

Le stage final REVIEW produit le Rapport après action. Quatre tâches :

  • Compiler la chronologie des événements — l'opérateur constitue le journal minute par minute à partir du journal de communication opérationnel.
  • Identifier les lacunes doctrinales — la persona doctrine-cell signale le délai de 2h 52m pour l'autorisation d'abordage, le renvoi du spoofing AIS à l'UIT, la lacune du réseau HUMINT à Limassol.
  • Rédiger le RAA — le commandant finalise le récit.
  • Signer et distribuer le RAA — le commandant signe (l'action approval) et le rapport est transmis au HQ Northwood (J2/J3/J5), au MARCOM HQ de l'OTAN, et au SHAPE J5.

Télécharger 05-after-action-report.md — le RAA pour la veille du 14 mars 2026.


Trois variantes d'erreur à observer

ErreurComment la déclencherCe que cela signifie
STAGE_DEPENDENCY_NOT_METTentez d'ouvrir Publier le produit de renseignement fusionné avant que les cinq tâches SENSE soient terminées.Le runtime applique stageFlow: "sequential".
TASK_DAG_BLOCKEDTentez de démarrer Autoriser l'action de composante avant que l'officier de droit signe Confirmer l'applicabilité des ROE.dependsOnTaskSlugs est appliqué.
AGENT_FAILEDSoumettez un journal AIS malformé (zéro octet) dans Exécuter la détection AIS des navires.Le classificateur se dégrade en checklist manuelle avec une erreur lisible par l'humain plutôt que de masquer l'échec.

Personnaliser le pack

Le pack NATO livré comprend une ontologie vide et s'arrête avant les types d'objets typés Track / Contact / Decision. Trois chemins de personnalisation :

  1. Ajouter des contributions d'ontologie typées. Forkez packages/sdk-authoring/src/process-flows/examples/nato/ et ajoutez un ontology/manifest.json déclarant les types d'objets Track, Contact, Decision, Engagement plus les types de liens ObservedBy, BasedOnIntel, Authorises. Câblez les ontologyContract.{reads,writes} de chaque tâche pour référencer ces slugs. Reconstruisez avec bunx @scrydon/sdk-authoring pack build src/pack.ts --outDir dist. L'importateur reliera les slugs aux ID de classe de votre tenant et persistera les contrats.
  2. Remplacer les personas de composante par des équivalents nationaux. Les noms de composante (air-component, naval-component, land-component) sont génériques. Un fork de groupe de travail national (par ex., Escadron 7 de la Marine allemande) les renommerait — modification TypeScript simple dans le fork.
  3. Sous-pack par niveau de commandement. Les packs niveau SNMG2, les packs niveau brigade, et les packs niveau groupe de travail national ajusteraient chacun les checklists des ROE et la cadence des rapports. Le flux de processus de base reste identique ; seules les métadonnées d'action (metadata.channel, metadata.recipientPersonas, metadata.completion) divergent.

Si vous forkez, changez package.id et template.slug depuis nato pour éviter les conflits avec le pack d'exemple livré lorsque les deux sont importés dans le même tenant.


Pour aller plus loin

Sur cette page

Sur cette page