# Kling billable create guardrails

Status: mandatory operating rule
Captured: 2026-03-29
Reason: prevent accidental multi-create spending during schema probing or comparison work

## Core rule
Every successful `create`-type API call must be treated as a billable production action.
This includes schema probes, body-shape experiments, and validation-oriented create attempts.

## Non-negotiable rules

### 1. No “free probe” assumption
- `POST` create calls are never assumed to be free
- if a create succeeds, it counts as a real generated task

### 2. One purpose, one create by default
For the same immediate purpose, only one create is allowed unless the user explicitly approves more.
Examples of same immediate purpose:
- checking one body shape
- comparing one prompt/reference pair
- verifying one endpoint/model combination

### 3. First success stops further create attempts
If a create succeeds while probing candidate request bodies:
- stop immediately
- do not continue testing more billable success-capable variants
- reuse the successful output as the comparison artifact when possible

### 4. Multi-create requires explicit pre-approval
If a task is expected to require more than one billable create, state before running:
- expected number of create calls
- purpose of each create call
- maximum expected unit exposure
Do not continue without user approval.

### 5. Probes and final runs must not be duplicated casually
If a probe already produced a valid output:
- treat that output as a real artifact
- do not rerun the same purpose just because it was originally called a probe

### 6. Prefer narrowing by documentation before create
When possible:
- read docs/screenshots/blog notes first
- reduce candidate body shapes before any live create attempt
- keep live billable probing to the smallest possible set

## Required operator checklist before any create run
- Is this create definitely necessary?
- Is there already a successful output for the same purpose?
- Am I about to test more than one candidate body shape?
- If yes, did I warn the user about create count and possible units?
- If the first candidate succeeds, will I stop immediately?

## Incident note motivating this rule
During Omni request-shape exploration, multiple successful create calls were made while narrowing the correct body structure. That caused several billable tasks where the user reasonably expected a single test. This must not happen again.


## SOT-before-create rule
Before any new payload shape, new field, or new workflow is tried against a billable create endpoint:
1. Check the Qingque-derived SOT/API reference first.
2. Use documented fields first; do not guess field names when an SOT exists.
3. If the desired field/workflow is not present in SOT, mark it explicitly as a hypothesis.
4. Hypothesis payloads require explicit user approval before any billable create.
5. The run note must state whether the payload is:
   - doc-derived
   - live-confirmed
   - hypothesis-only

This rule exists because having an SOT is meaningless if execution bypasses it.