@zatsepin/jigor — System One decision gateway

Installs the jigor binary: a CLI and an HTTP gateway over one System One wire — noul/choice/score questions in, typed JSON answers out. von and laya run locally as ONNX (no API key); jev runs remote on OpenRouter Decisions, or on the Klava gateway at klava.zatsepin.dev — same wire, --provider klava, KLAVA_API_KEY.

Node ≥ 18 is needed once, at install time, to pick the platform package — the installed jigor is a standalone binary with no Node runtime.

Install

npm install --global @zatsepin/jigor
jigor --help

One-off, no install:

npx @zatsepin/jigor models

The binary comes from an optional dependency matched to your OS and CPU — @zatsepin/jigor-linux-x64-gnu, @zatsepin/jigor-linux-arm64-gnu, @zatsepin/jigor-darwin (universal2: Apple Silicon + Intel) or @zatsepin/jigor-win32-x64-msvc — installed automatically, never a source build.

Quick start

jigor ask --model von <<'JSON'
{
  "state": { "error": "Disk volume /var/log at 98% capacity." },
  "questions": {
    "requires_intervention": {
      "type": "noul",
      "instructions": "Does this disk space condition require operational intervention?"
    }
  }
}
JSON
{"answers":{"requires_intervention":{"noul":0.7822,"type":"noul"}},"backend":"local","model":"von-1.0.0"}

Every question carries instructions plus an optional criteria (object or list) that spells out how to judge the state. Answer shapes are the same on every backend:

• noul → {"type":"noul","noul":0.7822} — probability of yes in [0, 1]
• choice → {"type":"choice","choice":"refund","confidence":0.91,"probabilities":{...}}
• score → {"type":"score","score":1.0,"confidence":0.7,"probabilities":{...},"legend":{...}}

{
  "state": "Invoice charged twice for order #4471.",
  "questions": {
    "domain": {
      "type": "choice",
      "instructions": "Classify the root cause domain.",
      "criteria": { "billing": "Invoices, payments, refunds", "infrastructure": "Database, network, hardware" }
    },
    "severity": {
      "type": "score",
      "instructions": "Assess degradation level.",
      "criteria": ["Nominal operation", "Degraded performance", "Critical risk"]
    }
  }
}

HTTP gateway

jigor serve --host 127.0.0.1 --port 8000

curl -X POST http://127.0.0.1:8000/v1/systemone \
  -H "Content-Type: application/json" \
  -d '{
    "model": "von-1.0.0",
    "state": { "error": "Disk volume /var/log at 98% capacity." },
    "questions": {
      "requires_intervention": {
        "type": "noul",
        "instructions": "Does this disk space condition require operational intervention?"
      }
    }
  }'
# {"answers":{"requires_intervention":{"noul":0.7822,"type":"noul"}},"backend":"local","model":"von-1.0.0"}

POST /v1/systemone takes the same body as jigor ask; errors are {"error": "...", "code": "..."} with machine-readable codes (invalid_json, unknown_model, scoring_failed, ...).

GET /healthz reports liveness plus per-model readiness (ready / loading / not_loaded):

curl -s http://127.0.0.1:8000/healthz
# {"status":"ok","version":"0.1.14","model":"von-1.0.0",
#  "models":{"von":"ready","laya":"ready","jeff":"not_loaded"}}

jeff (3.2 GB) loads lazily on first use; make the wait explicit with jigor serve --load jeff at startup or curl -X POST http://127.0.0.1:8000/v1/preload -H 'Content-Type: application/json' -d '{"models":["jeff"]}' at runtime (concurrent callers share the load).

Full agent-harness guide: https://github.com/Partysun/jigor, section "Using jigor from scripts and agent harnesses".

Models

--model takes an alias (von, laya, jev, jev-latest) or a full id (von-1.0.0, typesafe/jev-1.13); jigor models lists every provider × model pair. The local ONNX models download from Hugging Face to ~/.cache/huggingface on first use and are cached afterwards (--cache-dir <dir> or JIGOR_CACHE_DIR=<dir> moves the cache); the remote jev backend needs OPENROUTER_API_KEY, the Klava gateway (--provider klava) reads KLAVA_API_KEY instead.

Source, Rust crates and the pip package: https://github.com/Partysun/jigor