> ## Documentation Index
> Fetch the complete documentation index at: https://docs.simplefunctions.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Stability and side effects

> How SDK and Agent contract slices classify permissions, side effects, and deferred surfaces.

The draft contract map lives at:

```text theme={null}
contracts/sf-contract-map.draft.json
```

The hosted strict manifest is:

```text theme={null}
GET /api/contracts/tools
```

It is the SDK/Agent contract manifest. The broader `/api/tools` endpoint is a compatibility inventory and should not be used as canonical SDK truth.

Every implemented surface declares:

* canonical dotted tool name
* HTTP endpoint
* CLI command
* SDK method
* Agent tool metadata
* permissions
* side-effect class
* auth requirement
* schema name
* trace events

## Side-effect classes

`none` means read-only.

`user_write` means user state can change.

`paper_trade` is reserved for explicit paper-only execution contracts.

`live_trade` means live Kalshi or Polymarket execution, or executable intent mutation. It is not hard-forbidden at the contract layer; SDK and Agent consumers must opt in with auth, `maxSideEffect: "live_trade"`, `maxCostEffect`, and trade guardrails.

`runtime` is reserved for daemon/runtime mutation.

`secret` is reserved for surfaces that create or reveal secret material.

## Deferred examples

`market.related`, `events.search`, `event.inspect`, and `event.markets` are deferred because the repo does not currently expose canonical endpoints for those object meanings.

`intents.propose` is deferred because the current intent endpoint creates executable intents but does not expose an explicit paper-only mode contract.

`webhooks.create` is deferred because the endpoint returns a one-time signing secret and needs a dedicated secret-handling SDK contract.

Live execution is implemented through `execution.place` and intent management through `intents.create`, `intents.get`, and `intents.cancel`. Runtime discovery and startup are implemented through `runtime.status` and `runtime.ensure`; `execution.place` uses them before creating an executable Kalshi or Polymarket intent unless explicitly disabled. The legacy `live_trade` name is a compatibility alias for `execution.place`, not a canonical tool.

High-frequency market making, direct venue order lifecycle handling, and latency-sensitive replace/cancel loops remain raw venue API territory. SDK/Agent execution is the governed intent/runtime path for traceable application workflows, not a venue-native matching-engine client.