Authority model

Separate the proposal
from permission to act.

KisOrderExecutor consumes precheck and authorize at the execution-envelope gate. Owner-signed delegation constrains child envelopes and shared usage. Portfolio checks in validate_trade and the role-scoped fleet-halt route address a different responsibility: limiting or stopping exposure. Approval, admission, halt and broker submission are distinct operations.

Authority is asymmetric by design. The human operator owns opening or expanding live-capital access. Risk-reducing automation acts only within its defined envelope; halting a path does not authorize its release.

Proposal

Research and inference supply a proposed action. Neither a score nor a decision reference carries execution permission.

Permission

An envelope represents attributable permission. In the selected KIS source, the executor checks the envelope and owner-bounded delegation at its consuming boundary.

Execution

The engine submits through its account and broker context. Portfolio protection may constrain exposure; Control Plane may aggregate health or coordinate a workflow. Those roles do not replace order-path authority checks.

Control responsibilities

Shared controls. Distinct consuming paths.

Control Plane includes coordination, market-access and control services. Its health aggregation is one responsibility; portfolio protection and the checks on a particular order path are other responsibilities. They are not represented as one universal central approval switch.

Health and observation

Aggregate availability, settings and dated state reports. Reading the approval-axis summary is not an order-admission decision.

Portfolio-level controls

Portfolio stop and kill-switch implementations are distinct from the health summary. A reported ARMED state is not evidence of a triggered stop across every engine.

Engine-local permission

Each engine consumes its own applicable permission, arm or lease context. A model proposal and a shared support service do not create that permission.

Order risk and admission

Selected consumers apply risk, trading-halt and submission conditions before a broker action. The original records include a particular refusal and a separate autonomous-submission condition window.

Broker or exchange execution

The exchange or broker adapter submits an admitted request. A health response, approval summary or successful scheduler result is not a fill or accounting receipt.

These responsibilities are documented from source and dated records. The record for an individual control identifies the observed path and date; engine-local admission remains distinct from portfolio controls and shared health aggregation.

Observed controls, source and limits →
Implementation and dated observations

Controls have observable behavior.

The public records contain specific control states, refused order attempts and guarded submission paths alongside scoped local engineering tests. Each observation keeps its original environment and date.

Portfolio kill-switch state

The inspection reported the portfolio kill switch as ARMED, separately from the approval-axis summary.

Recorded scope: ARMED is a reported configuration state. This record does not demonstrate a triggered portfolio stop, its reach across every order path, or the current state.

Record observed/reviewed ·

Scope and original evidence →

Server-side order refusal

The original inspection records identified order attempts refused by the server-side risk check and the core sell block.

Recorded scope: This is an internal dated observation on a particular execution context. The executing commit was not recorded; accepted-case testing, universal enforcement and present operating state are not established by it.

Record observed/reviewed ·

Event window stated in the original: 26 September (KST)

Scope and original evidence →

Opt-in, lease and certified-trial conditions

Every autonomous submission attempt in the stated half-hour was skipped while opt-in, admission-lease and certified-trial conditions were inactive or not ready.

Recorded scope: This records refused or skipped progression, not successful issuance, certification or release. Development/testnet observations elsewhere refer to another service and must not be read as this same path changing over time.

Record observed/reviewed ·

Scope and original evidence →

Follow each link for the original evidence scope, source references and integrity checks.

Enforcement at the consumer

Connect the permission to the submitted action.

A complete enforcement observation identifies the consuming engine, applicable permission and both accepted and refused inputs. A readable setting establishes configuration; a healthy endpoint establishes a response. Neither substitutes for the action that the order path allowed or refused.

The published inspection records selected settings and particular refused paths. Current live activation and a current allowed/refused pair remain outside that record; the map keeps those limits attached to the implemented controls.

Project scope and operating model →
Dated supporting record

The original record preserves the observed approval summary, promotion state and inter-host gate modes with their original limits.