NATO OODA — end-to-end tutorial

Goal

By the end of this tutorial you will have imported the NATO — Grey-Zone Incident Response (Eastern Flank) Scrydon Pack into your tenant, created a fresh instance for the fictional Operation Aegean Sentinel maritime sanctions-monitoring watch, walked surveillance contacts through the full OODA loop, and produced a signed after-action report.

LtCdr Sofia Konstantinou, J2 Intelligence Officer aboard FGS Wernicke, and Commodore Halvor Sletten, Commander SNMG2, are our fictional principals. Operation Aegean Sentinel, the contact tracks, intelligence reports, and decision memo in this tutorial are entirely fictional and exist purely to illustrate the flow.

Prerequisites

You have a Scrydon deployment with the agentic and ontology surfaces enabled. Set the following env vars in your shell for the import step:

export SCRYDON_URL="https://<your-scrydon-url>"
export ORG_ID="<your-org-id>"
export SESSION_COOKIE="$(cat ~/.scrydon/session-cookie)"  # or paste from the browser

The template references three system workflows under requirements.systemWorkflows. Until they ship those workflow-typed actions degrade to manual checklists in the runtime UI, which still drives the tutorial cleanly.

Step 1 — Download the pack

The pack is a ≈ 6 KiB gzip stream containing pack.json, an empty ontology/manifest.json, and process-flow/manifest.json (six stages, 10 personas, the full task DAG).

Download 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

Step 2 — Inspect the pack

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

Expected output:

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)

The process-flow subdir's task DAG is large — 30+ tasks across the six stages with cross-stage dependsOnTaskSlugs. The inspector runs the DAG cycle check; any cycle would fail the inspection here, before upload.

Step 3 — Upload the 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"

Expected 200:

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

The NATO pack is no longer auto-installed in every tenant — it ships as a downloadable example. You can import it with the unmodified nato slug; only fork to a custom slug if an in-tenant fork from an earlier release is still lingering with the same slug.

Step 4 — Open a new operation instance

Browse to $SCRYDON_URL/process-flows. The NATO — Grey-Zone Incident Response (Eastern Flank) card appears under the Defense & Security tag. Click New from template, name the instance Operation Aegean Sentinel.

The instance opens on the wizard view by default. The left rail lists the six stages and their tasks; the right panel walks through each task as a scene:

• SENSE — passive surveillance and sensor fusion (8 tasks).
• FUSE — single-track correlation across sensor types (5 tasks).
• ANALYSE — pattern-of-life and threat assessment (6 tasks).
• DECIDE — commander's release-authority loop (4 tasks).
• EXECUTE — kinetic / non-kinetic action by component commands (5 tasks).
• REVIEW — after-action review, doctrine update (4 tasks).

The first task — Open Daily Intel Brief — is assigned to the operator persona and unlocked. Everything else is gated.

Step 5 — SENSE: stage the surveillance picture

Open Open Daily Intel Brief and paste the demo situation brief into the document action:

Download 01-situation-brief.md — Operation Aegean Sentinel mission orders: surveillance of the 34–36°N / 25–28°E "Aegean box" for sanctioned shipping, 08–22 March 2026.

The OOD then walks the SENSE stage tasks:

Download 02-ais-contact-log.md — the OOD's eight-hour contact log feeding the daily 0600Z brief. Three Tracks of Interest (TOI) elevated under the suspect-indicator rules.

Mark all SENSE tasks complete. The DAG opens the FUSE stage.

Step 6 — FUSE: build the cross-source picture

The FUSE stage correlates each TOI across AIS, IMINT (helo flybys), HUMINT (NCAGS port-agent network in Cyprus and Crete), and pattern-of-life data from the past 12 months. The intel-analyst persona drives this stage.

The single deliverable is the Intelligence Fusion Product, a multi-source assessment with named confidence levels:

Download 03-intel-fusion-product.md — the fusion product attributing a medium-to-high-confidence assessment of an imminent ship-to-ship cargo transfer at 35°15′N 26°45′E between M/V Polaris Star (TOI-A) and M/V Wasilla Trader (TOI-B).

Paste the fusion product into the Publish fused intelligence product task and mark complete. Once approved by the senior intel analyst, the ANALYSE stage opens.

Step 7 — ANALYSE: assess and escalate

The ANALYSE stage runs pattern-of-life and threat-assessment tasks in parallel:

• Compute confidence assessment — re-runs the fusion math, surfaces single-source vs. multi-source confidence;
• Compare against pattern-of-life baseline — cross-references the 12-month AIS dataset for prior co-location of the two TOIs (none found in this scenario);
• Tag third-party assets — identifies the Eltherian-flagged auxiliary Vostok-3 as the likely onward link;
• Draft escalation memo to commander — the analyst's recommendation for DP-3 action.

Once the commander acknowledges receipt of the escalation memo (the gating approval action), the DAG opens the DECIDE stage.

Step 8 — DECIDE: commander's release authority

The DECIDE stage is the OODA loop's critical decision gate. Four tasks, assigned to the commander persona with aco-shape-liaison and legal-officer (LOAC) review:

Download 04-commanders-decision-memo.md — the Commodore's signed decision memo authorising visible-presence approach, bridge-to-bridge hail, AIS-on demand, and an HQ boarding-authority request.

After the commander signs (the approval action), the EXECUTE stage opens.

Step 9 — EXECUTE: components carry out the order

The EXECUTE stage parcels the commander's intent to component commands. The naval-component persona (and air-component for AWACS support) carry out the visible-presence approach:

• Position naval-asset — FGS Wernicke closes to 4 NM on TOI-A; HMCS Charlottetown closes to 4 NM on TOI-B.
• AWACS coverage on station — sortie SE-26-032 from 14 March 0330Z to 0930Z.
• Bridge-to-bridge hail — both warships hail, demanding AIS-on. Refused by both vessels.
• Submit boarding-authority request to HQ — sent at 0612Z, granted at 0904Z.
• Report contact to HQ — hourly OPREP-3 throughout the window.

The rendezvous aborts at 0743Z, before boarding authority is granted. The commander declines to execute boarding. The DAG opens REVIEW.

Step 10 — REVIEW: doctrine cell closes the loop

The final REVIEW stage produces the After-Action Report. Four tasks:

• Compile timeline of events — the operator builds the minute-by-minute event log from the operational chat record.
• Identify doctrinal gaps — the doctrine-cell persona flags the 2h 52m boarding-authority latency, the AIS-spoofing referral to ITU, the HUMINT-network gap in Limassol.
• Author AAR — the commander finalises the narrative.
• Sign and distribute AAR — the commander signs (the approval action) and the report is pushed to HQ Northwood (J2/J3/J5), NATO HQ MARCOM, and SHAPE J5.

Download 05-after-action-report.md — the AAR for the 14 March 2026 watch.

Three error variants worth seeing

Customising the pack

The shipped NATO pack ships an empty ontology and stops short of typed Track / Contact / Decision Object Types. Three customisation paths:

1. Add typed ontology contributions. Fork packages/sdk-authoring/src/process-flows/examples/nato/ and add an ontology/manifest.json declaring Track, Contact, Decision, Engagement Object Types plus ObservedBy, BasedOnIntel, Authorises Link Types. Wire each task's ontologyContract.{reads,writes} to reference those slugs. Rebuild with bunx @scrydon/sdk-authoring pack build src/pack.ts --outDir dist. The importer will rebind slugs to your tenant's class IDs and persist the contracts.
2. Replace component personas with national equivalents. Component names (air-component, naval-component, land-component) are generic. A national task force fork (e.g., German Navy Squadron 7) would rename them — straightforward TypeScript edit in the fork.
3. Sub-pack per command level. SNMG2-level packs, brigade-level packs, and national-task-force-level packs would each tweak ROE checklists and reporting cadence. The base process flow remains identical; only the action metadata (metadata.channel, metadata.recipientPersonas, metadata.completion) diverges.

If you fork, change package.id and template.slug away from nato to avoid colliding with the shipped example pack when both are imported into the same tenant.

Where to go next