Effects and adaptive depth

What it is. Two related ideas. Effects are what an operation may do: read, write, or execute. Adaptive depth is how much visible process a task gets: Tiny, Normal, or High-impact. Defined in framework/trust-and-authority.md (KIYO-SAFE-001) and workflows/adaptive-flow.md (KIYO-FLOW-001).

Why it exists. An agent that can edit files should not assume it may also run tests, migrate a database, or rewrite Memory. And a typo fix should not need a three-page plan.

Effects are separate

Effect	Covers	Not implied by
Read	Inspecting permitted files, config, Memory, and safe metadata commands	Tool availability, since a tool that can reach a file does not authorize it
Write	Changing files: source, tests, docs, Memory, report files	Read permission, or a found defect
Execute	Running project code, tests, builds, installers, migrations, network calls	Write permission; “test” or “dry-run” labels prove nothing

The router selects an action mode per operation. Code edits may be authorized while a test command is held for an environment check. A Tiny change still separates these effects.

Read-only stays read-only

KIYO-SAFE-001 is one of the strongest rules in the framework:

A review or other read-only request authorizes inspection and reporting within scope, not fixes, formatting, Memory sync, or writing a report file.
Commands with write or execute effects do not become acceptable because they are labeled tests or checks.
A found defect is reported with evidence, impact, and a proposed repair. The agent does not turn review into implementation or keep asking for edits.

These Skills and modes are read-only by contract: Review, Architecture, Security, Test assess, Memory show/check, Init preview, and Requirement by default.

Adaptive depth

Depth is chosen from the actual action, uncertainty, and effects, not from line count. A one-line change to authentication or policy can require High-impact handling.

Depth	When appropriate	Visible working shape
Tiny	Bounded, understood, low-impact change or narrow analysis	Compact scope/risk check → small edit → applicable checks → Memory impact → result
Normal	Several related steps or meaningful behavior	Short plan naming affected behavior, areas, and checks
High-impact	Sensitive effects, broad impact, hard recovery, material uncertainty	Explicit scope/impact assessment, required human decision, stronger evidence; hold dependent actions

Depth is not a governance level or risk rating. G1–G4 and LOW–CRITICAL are separate decisions (see Governance and approval).

What never shrinks

At every depth, these obligations remain:

actual authority and read-only intent;
authorized evidence and Memory validation before asserting facts;
applicable human approval, reused rather than repeated;
command, target, and side-effect inspection before execution, and honest results;
minimum change, preservation of human edits, scoped review, and Memory impact.

If scope, API or schema, data destination, target, approved intent, or a required native control changes mid-task, the agent pauses the dependent step and re-plans. It raises the depth rather than keeping a risky action “Tiny”.

Minimal example

Change 'recieve' to 'receive' in the README only. Do not edit any other file.

The framework’s walkthrough writes this request in Thai, to show that intent is read from natural language in any language. The expected shape is a compact scope and risk check, one correction, a diff and spelling check, Memory impact, and a concise result. There is no long plan, package upgrade, broad formatting, or unrelated test suite.