Read → Propose → Approve → Execute

Read → Propose → Approve → Execute is Ethen’s canonical control model for work that can move from understanding information to changing state. Use it when defining an agent, workflow, tool call, or human review process. The pattern is supported by approved platform language, but the exact controls, roles, and runtime states must still be verified in the product that performs the action.

Control model

The model creates explicit transitions between four stages:

The stages are not merely labels. Each transition changes what can be claimed. Reading supports understanding; proposing supports review; approval supports authorization; execution evidence supports a statement about action.

A task may intentionally stop at any stage. Research often ends after Read. Planning may end after Propose. A risk-sensitive workflow may wait at Approve. A blocked integration may prevent Execute even after approval.

Read → Propose → Approve → Execute is the approved control sequence for sensitive or state-changing work. It separates understanding and planning from an action that changes a system, account, file, workflow, or external service.

The pattern is a platform boundary. The precise UI and runtime implementation can differ by product, and some surfaces may stop at a draft, simulation, or dry run.

Read

Read gathers or inspects permitted information without changing the target state. Examples include browsing Model Library, reviewing a Model Intelligence profile, inspecting workspace context, or retrieving information through a verified read-only tool.

A read stage should identify:

• the source or surface being inspected;
• the current route, status, or timestamp where relevant;
• the context the reader or system is allowed to use;
• missing or uncertain fields;
• the question the read is intended to answer.

Reading does not make all retrieved information equally authoritative. A catalog status is operational evidence. A benchmark is test evidence. A normalized profile may contain derived presentation logic. A policy page owns legal commitments.

A model-generated summary of read data is still an interpretation. Preserve the source references needed to verify it.

During Read, Ethen works with context the current surface is authorized and configured to access. Reading should not change external state.

The reader should be able to identify the active workspace, files, provider lane, and other context. If access scope is unclear, stop before moving to a proposal.

Propose

Propose converts understanding into a candidate decision or action. The proposal should be complete enough for another person to review without reconstructing the entire session.

A well-formed proposal includes:

1. the intended outcome;
2. the target model, system, object, or recipient;
3. the exact action or change;
4. the context and evidence used;
5. expected effects and known limitations;
6. required configuration, credentials, or tools;
7. the verification plan;
8. an explicit statement that execution has not occurred.

For model selection, the proposal may recommend a candidate based on capability, status, context, cost, latency, and evidence. For a workflow, it may describe tool calls and approval points. For a document task, it may be a draft artifact.

A proposal should not hide substitutions. If a fallback model or provider is acceptable, name the conditions under which it may be used. If the evidence is incomplete, include the unresolved question rather than presenting confidence that the sources do not support.

During Propose, the system presents intended work in a reviewable form before execution. A proposal should make the action, target, expected effect, and relevant evidence visible.

A generated plan is not proof that the action is possible or approved. If the plan changes materially, the updated proposal should be reviewed again.

Approve

Approve authorizes a specific proposal through the mechanism supported by the owning product. Approval should be tied to what will happen, not treated as a broad permission for any future action.

Before approval, the reviewer should be able to see:

• the target and scope;
• the proposed inputs or changes;
• the selected model, provider, tool, or integration where relevant;
• the expected external effect;
• sensitive context involved;
• cost, availability, or operational uncertainty that could alter the decision;
• the evidence that will confirm success.

Batch 01 does not verify universal role names, approval buttons, expiration behavior, delegation, or multi-party approval. Therefore, documentation should say “through the supported approval control” until the product-specific source defines the procedure.

Approval is not a runtime capability. It cannot resolve a missing key, unsupported modality, invalid input, or unavailable target. If the proposal changes after approval, the revised action should be reviewed again.

Approval is the explicit decision to permit the supported proposed action to continue.

This batch does not define approver roles, quorum, expiry, delegation, or escalation. Do not infer approval from silence, prior access, or a model recommendation. The product-specific implementation must show the approval boundary.

Approval scope

The approval should cover the exact target, action, inputs, and expected effect visible to the reviewer. Broad language such as “approve the workflow” can hide later changes in model, provider, tool, recipient, or payload. When those elements materially change, return to Propose.

This scope rule also applies to repeated work. Approval for one instance does not establish a permanent authorization unless the owning product explicitly supports and records that policy.

Execute

Execute performs the authorized action through a supported model, tool, integration, or product route. It is the stage with the strongest evidence requirement because it can change state or create external effects.

Execution should begin only after these conditions are separately satisfied:

• the proposal is current and approved;
• the actor has permission;
• the model, provider, tool, or integration is configured;
• the requested capability or modality is supported;
• required credentials are available through the proper control;
• the target and inputs pass validation;
• the verification path is known.

After the call, distinguish request accepted, operation completed, and outcome verified. A tool response may confirm submission while the target operation remains pending. A receipt may record Ethen’s action while external evidence is still needed.

If execution fails, preserve the proposal and approval with the error evidence. Do not silently change the target or repeat a state-changing call when duplicate effects are possible.

Execute is the phase in which an approved, supported action can change state.

Execution should remain within the approved scope. A draft, simulation, copied request, or playground preview is not the same as a completed external action. Product documentation must explain the expected result and failure state.

Where the pattern appears

Model research and access

A reader reads Model Intelligence and Model Library evidence, proposes a model and provider path, receives any required review or configuration approval, then executes a supported request through Gateway or the console. Research evidence and runtime evidence remain distinct.

Tool-assisted workflow

An agent reads current context, proposes a structured external change, pauses for approval, and uses a configured tool to execute. The result is verified through tool output, target-system evidence, or a receipt.

Fallback decision

A preferred route is blocked. The system or operator reads the status, proposes an alternate model or provider, obtains approval if the substitution changes risk or external effect, and then executes the alternate path. Invisible fallback is avoided.

Artifact review

A model reads supplied material and proposes a draft artifact. The reviewer may approve the artifact for use without any automated external execution. In that case, the control model stops at approval and a person handles the later action.

Safety boundary

When the owning surface does not expose a grounded approval or execution path, remain at Read or Propose. That is not an incomplete workflow; it is the correct boundary for the available evidence.

This control model should be referenced consistently across Ethen documentation. Product guides may add precise controls and states, but they should not erase the distinction among understanding, recommendation, authorization, and completed action.

Use the pattern whenever work can cross from analysis into a state change, including supported tools, integrations, workflow steps, provider configuration, or other external actions.

Not every read-only model request requires an approval. Not every recognized product route currently implements live execution. Apply the pattern according to the verified capability and risk of the owning surface.

Writing stage-aware status messages

Status language should state the stage rather than imply completion. Prefer “source data reviewed,” “proposal prepared,” “approval recorded,” “execution request sent,” or “target result verified” over a generic “done.” The precise wording makes receipts and interfaces easier to audit.

A stage-aware message should also name the object. “Proposal approved” is incomplete if the proposal changed after review. “Execution succeeded” is incomplete if only the tool accepted the request. Include the proposal or run identity when available and preserve the evidence that supports the statement.

Revising a proposal

A material change to target, model, provider, input, output, tool, or external effect creates a new proposal. The earlier approval should not be stretched to cover the revised action. This is particularly important for fallback, where a substituted provider can change cost, data flow, or operational risk.

Minor editorial refinement can remain within the same review when the intended action is unchanged, but the owning product should define the boundary. Batch 01 does not specify approval versioning, so documentation must avoid claiming automatic inheritance.

Using the model for non-execution work

The control model also clarifies when no execution stage is needed. A comparison, summary, draft, or recommendation can be complete as an artifact after human review. The artifact should be labeled as analysis or proposal rather than as an external change.

This prevents documentation from treating automation as the only valuable outcome. Reviewable work often creates the information needed for a later decision without crossing the execution boundary.