Core concepts and decision states
Understand the vocabulary used in setup, policy, approval, and evidence guides.
On this page
The objects in a governed workflow
| Concept | Meaning |
|---|---|
| Workspace | The organization context for membership, configuration, and governance activity |
| Environment | A policy and runtime scope, such as a test or production environment |
| Integration | The hook, proxy, gateway, or application code that supplies context and handles the decision |
| Action | The operation being evaluated, with the tool, target, and available attributes |
| Policy and rule | A versioned policy contains rules describing when a supported effect applies |
| Decision | The evaluated outcome and its recorded context; distinguish this from the tool’s execution result |
| Checkpoint | A supported HOLD workflow awaiting human resolution or a terminal timeout/lifecycle outcome |
| Evidence | Recorded decisions, approval history, administrative events, and scoped exports used to investigate behavior |
For example, an agent requests a file edit through a connected hook. A rule matches that file and requires HOLD. An authorized member resolves the checkpoint, and the integration handles the result before continuing the edit.
Interpret the outcome
| State | What it means for the action |
|---|---|
| ALLOW | The evaluated action may proceed through the integration; execution can still fail in the target system |
| DENY | The integration should stop the evaluated action |
| HOLD | Wait for the supported approval contract; pending is not permission |
| Shadow mode | Observe policy outcomes while allowing work to continue without blocking enforcement |
| Hosted billing observe-only | Hosted trial or subscription lapse has removed blocking enforcement |
| Fail-open | A particular failure path allows work without a normal enforced decision |
Policy effects such as monitor, redact, hide, rate limits, and spend caps have surface-specific behavior. They should be interpreted using the relevant integration guide, not as additional universal HTTP response states.
Read evidence in context
An approved checkpoint records a human decision. An expired checkpoint follows its configured timeout outcome. A post-action audit event describes completed activity. A verified chain establishes integrity within its recorded scope. Each answers a different review question.
How Kastra works · First workflow · Approval lifecycle · Failure behavior
Self-hosted license expiry follows a separate contract: authoring and licensed configuration become limited while runtime policy enforcement continues. See self-hosted deployment.