kitelogik check

Dry-run a JSON governance event against the loaded policies and print the decision the gate would return. The fastest path from "does this event allow or deny?" to an answer — no agent, no model, no tool execution.

Synopsis

kitelogik check '<JSON-EVENT>' [--path PATH]

Argument / Flag	Default	Meaning
JSON-EVENT	required	Event payload as a JSON string
--path PATH	auto-discover	Path to a policies directory

What it does

1. Resolves the policies directory (same auto-discovery as validate).
2. Parses the input string as JSON. Bad JSON exits with code 1 and a parse error.
3. Runs opa eval -d <policies> --stdin-input data.kitelogik.main with the JSON piped to stdin — this is the same query the runtime gate issues.
4. Pretty-prints the resulting decision dict (allow, deny, requires_hitl, risk_tier, reason).

Example

A simple allow:

$ kitelogik check '{
  "action":  "read_customer_record",
  "context": {
    "session_id":     "s1",
    "user_role":      "support_agent",
    "session_scopes": ["read_customer"]
  }
}'
{
  "allow":         true,
  "deny":          false,
  "requires_hitl": false,
  "risk_tier":     "INFORMATIONAL",
  "reason":        ""
}

A hard deny from security.rego:

$ kitelogik check '{
  "action":        "read_file",
  "resource_path": "/etc/passwd",
  "context":       {"session_id": "s1", "user_role": "support", "session_scopes": []}
}'
{
  "allow":  false,
  "deny":   true,
  "reason": "Access to system files is forbidden",
  "risk_tier": "SECURITY_CRITICAL"
}

A HITL trigger (allow=False, requires_hitl=True):

$ kitelogik check '{
  "action":  "approve_refund",
  "args":    {"amount": 500},
  "context": {"session_id": "s1", "user_role": "support_agent", "session_scopes": ["approve_refund"]}
}'
{
  "allow":         false,
  "deny":          false,
  "requires_hitl": true,
  "risk_tier":     "TRANSACTIONAL_HIGH",
  "reason":        "Refunds over $200 require manager approval"
}

Event shape

The JSON shape mirrors the governance event the runtime emits. The minimum useful payload is action plus context.{session_id, user_role, session_scopes}. Add args, resource_path, event_type, delegation_target, etc. as needed by the rules you're testing.

For the full set of fields and event types, see the governance events reference.

Why it's faster than a unit test

A _test.rego file is the right home for assertions you want to keep. But during interactive policy development — "will this rule fire on this event?" — check is a one-liner against the live bundle, no test boilerplate to write or maintain.

Pair the workflow:

# Iterate
vim policies/financial.rego
kitelogik check '{...}'           # quick "does this work?"

# When the rule's right, capture the case
vim policies/financial_test.rego  # add a test that asserts the same outcome
kitelogik test                    # confirm

OPA binary or Docker

Same fallback story as every OPA-using command — see CLI overview.

Related

• Governance events — the JSON shape check consumes
• test — promote a useful one-off check into a permanent assertion
• Risk tiers & HITL — what requires_hitl=true means downstream