# How SDE Works: Request -> Decision -> Enforcement -> Evidence

## Purpose
Explain the self-serve adapter flow in both standalone hardening mode and governed SDE-backed mode.

## Audience
- Adapter operators
- Security and assurance reviewers
- Platform engineers validating enforcement behavior

## 1) Request
The adapter policy enforcement point intercepts a tool-action request before execution.

## 2) Free Standalone Decision
In free standalone mode, the adapter checks the action against a local hardening baseline. If the action is not allowed, it is blocked locally.

## 3) Paid Governed Decision
In paid mode, SDE evaluates the request against the configured governance policy and returns one of:
- `allow`
- `deny`
- `constrain`

## 4) Enforcement
The calling runtime applies the resulting outcome. In standalone mode this is a local allow or block. In paid mode, returned constraints can be applied and denies block execution.

## 5) Evidence
The governed flow records evidence such as:
- trace ID
- stable reason code
- policy or pack version
- returned constraint payloads

In free standalone mode, the main evidence is the local blocked/allowed behavior and the configured hardening baseline.

## 6) Validation Use
The PDP-backed flow is used to support:
- release verification
- compatibility validation
- operational troubleshooting

## Runtime Examples
- OpenClaw: plugin intercepts runtime tool calls and can deny or constrain high-risk actions.
- Codex: adapter evaluates `functions.shell_command` and `functions.apply_patch` against local or PDP-backed policy.