# Core concepts and decision states

Understand the vocabulary used in setup, policy, approval, and evidence guides.

Updated: 2026-09-22

Canonical: https://docs.kastra.ai/start/concepts

## 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](https://docs.kastra.ai/start/overview) · [First workflow](https://docs.kastra.ai/start/first-workflow) · [Approval lifecycle](https://docs.kastra.ai/approvals/overview) · [Failure behavior](https://docs.kastra.ai/reference/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](https://docs.kastra.ai/reference/self-hosted).