# How SDE Works: Request -> Contract -> Decision -> Action -> Evidence

## Purpose
Explain the operating flow of SDE in a way that applies across enterprise decision use cases, not only governed runtime enforcement.

## Audience
- Enterprise architects
- Security and risk reviewers
- Platform and AI engineering teams

## 1) Request and Context
A system, workflow, or operator submits a decision request together with the relevant business, policy, and environmental context.

Examples:
- an exception approval request
- a prioritization decision
- a model-output quality gate
- a governed runtime action request

## 2) Decision Contract Evaluation
SDE evaluates the request against a versioned decision contract. The contract defines:
- required and optional inputs
- validation rules
- constraints and thresholds
- escalation conditions
- expected outputs
- evidence requirements

## 3) Reliability-Aware Assessment
Inputs can be weighted or gated according to quality, freshness, provenance, and confidence so low-quality signals do not silently drive high-impact outcomes.

## 4) Deterministic Outcome
SDE produces a governed outcome such as:
- approve or deny
- allow or constrain
- rank and select
- allocate and budget
- escalate for human review

## 5) Downstream Action
The calling system applies the outcome. Depending on the integration, that may mean:
- continuing a workflow
- blocking an action
- applying returned constraints
- routing to human review

## 6) Evidence Output
SDE emits evidence for review and audit, typically including:
- trace ID
- stable reason codes
- contract or policy version
- confidence and escalation state
- relevant constraints or override path

## Governed Runtime Example
In OpenClaw Trusted Mode, the policy enforcement point submits a tool-action request to SDE. SDE returns `allow`, `deny`, or `constrain`, and the runtime enforces the result while preserving evidence for later review.