"nika: v1\nworkflow:\n  id: price-watch\n  description: \"Watch a product price, ping me when it drops below my target\"\n\nconst:\n  product_api: \"https://api.shop.example.com/v1/products/macbook-air\"\n  alert_below: 899\n\nsecrets:\n  alerts_webhook:\n    source: env\n    key: ALERTS_WEBHOOK_URL\n    egress:                       # sanction the one send · the secret IS the URL\n      - to: \"nika:notify\"\n        host_from_self: true\npermits:\n  tools: [\"nika:fetch\", \"nika:notify\"]\n  net:\n    # TWO hosts, for two different reasons.\n    #\n    # `api.shop.example.com` is what `const.product_api` names — a literal\n    # `check` can read, so a mismatch here is caught before the run.\n    #\n    # `hooks.slack.com` is the ALERT host, and it is the entry people leave\n    # out. `host_from_self:` above sanctions the FLOW (this secret may be the\n    # URL) — it does not grant the capability. The host stays unknown at\n    # check, so it is judged at RUN against this bound: name the escalation\n    # host here or the send is refused mid-run, the first time the price\n    # actually drops. Swap it for wherever YOUR webhook lives.\n    http: [\"api.shop.example.com\", \"hooks.slack.com\"]\n\ntasks:\n  check:\n    invoke:\n      tool: \"nika:fetch\"\n      args:\n        url: \"\u0024{{ const.product_api }}\"\n        mode: jq\n        jq: \".\"\n    output:                           # named jq bindings over the raw response\n      price: \".price\"\n      name: \".name\"\n    on_error:\n      # Offline rehearsal · a sample ABOVE the target, so the gate below stays\n      # closed and the dry run ends green with the alert skipped. The alert\n      # path is therefore NOT exercised offline — which is exactly why the\n      # `net:` bound above has to be right by reading, not by running.\n      recover: { price: 949, name: \"MacBook Air (offline sample)\" }\n\n  alert:\n    with:\n      price: \u0024{{ tasks.check.price }}     # value edges · the named bindings cross the boundary here\n      name: \u0024{{ tasks.check.name }}\n    when: \u0024{{ with.price < const.alert_below }}\n    invoke:\n      tool: \"nika:notify\"\n      args:\n        channel: webhook\n        target: \"\u0024{{ secrets.alerts_webhook }}\"\n        message: \"Price drop · \u0024{{ with.name }} is now \u0024{{ with.price }} (target \u0024{{ const.alert_below }})\"\n        severity: info\n\noutputs:\n  price: \u0024{{ tasks.check.price }}\n"

{"a":{"graph_format":2,"workflow":"price-watch","nodes":[{"id":"check","verb":"invoke","tool":"nika:fetch","permits":["tool: nika:fetch"]},{"id":"alert","verb":"invoke","tool":"nika:notify","when":"\u0024{{ with.price < const.alert_below }}","permits":["tool: nika:notify"]}],"edges":[{"from":"check","to":"alert","kind":"value"},{"from":"check","to":"alert","kind":"value"}]},"engine":"0.106.1"}

showcase · tier 1 · business

Price watch

Pulls one field from the shop API, compares it in CEL, pings your webhook. No model call anywhere.

Not everything needs an LLM. The engine alone is a robot you can already trust. · conformance-gated in nika-spec ↗ · re-proven at every push

2tasksthe plan falls out of the bindings
2wavesparallel by construction
1verbs exercisedinvoke
T1the tierbusiness

The whole file

2 tasks · 2 waves

The plan falls out of the bindings, nothing is scheduled by hand.

price-watch.nika.yamlsource

1nika: v12workflow:3  id: price-watch4  description: "Watch a product price, ping me when it drops below my target"56const:7  product_api: "https://api.shop.example.com/v1/products/macbook-air"8  alert_below: 899910⛨secrets:11  ⛨alerts_webhook:12    ⛨source: env13    ⛨key: ALERTS_WEBHOOK_URL14    ⛨egress:                       # sanction the one send · the secret IS the URL15      - ⛨to: "nika:notify"16        ⛨host_from_self: true17⛨permits:18  ⛨tools: ["nika:fetch", "nika:notify"]19  ⛨net:20    # TWO hosts, for two different reasons.21    #22    # `api.shop.example.com` is what `const.product_api` names — a literal23    # `check` can read, so a mismatch here is caught before the run.24    #25    # `hooks.slack.com` is the ALERT host, and it is the entry people leave26    # out. `host_from_self:` above sanctions the FLOW (this secret may be the27    # URL) — it does not grant the capability. The host stays unknown at28    # check, so it is judged at RUN against this bound: name the escalation29    # host here or the send is refused mid-run, the first time the price30    # actually drops. Swap it for wherever YOUR webhook lives.31    ⛨http: ["api.shop.example.com", "hooks.slack.com"]3233tasks:34  check:35    ◆invoke:36      tool: "nika:fetch"37      args:38        url: "${{ const.product_api }}"39        mode: jq40        jq: "."41    output:                           # named jq bindings over the raw response42      price: ".price"43      name: ".name"44    on_error:45      # Offline rehearsal · a sample ABOVE the target, so the gate below stays46      # closed and the dry run ends green with the alert skipped. The alert47      # path is therefore NOT exercised offline — which is exactly why the48      # `net:` bound above has to be right by reading, not by running.49      recover: { price: 949, name: "MacBook Air (offline sample)" }5051  alert:52    with:53      price: ${{ tasks.check.price }}     # value edges · the named bindings cross the boundary here54      name: ${{ tasks.check.name }}55    when: ${{ with.price < const.alert_below }}56    ◆invoke:57      tool: "nika:notify"58      args:59        channel: webhook60        target: "${{ secrets.alerts_webhook }}"61        message: "Price drop · ${{ with.name }} is now ${{ with.price }} (target ${{ const.alert_below }})"62        severity: info6364outputs:65  price: ${{ tasks.check.price }}66

audited · 3 tasks · 3 waves · permits declarednika 0.106.1

nika inspect · engine 0.106.1 · vendored graph, never re-derived

2 declared edges · 2 waves · the plan falls out of the bindings

try itopen in the playground guidethe walkthrough · docs verbinvoke toolnika:fetch toolnika:notify