Authority model
Permission is explicit. Enforcement needs evidence.
The design separates a proposal from the authority to act on it. Opening or expanding live-capital access requires human authority; bounded risk-reducing automation has a separately defined envelope.
Proposal
A model or rule supplies information. Its output does not create execution permission.
Permission
An authorization has an owner, scope and applicable conditions. The component consuming it must enforce those conditions.
Execution
The engine retains its execution context. Health summaries, portfolio controls and the risk or permission checks that consume a particular order request have separate responsibilities.
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.
The release-authority artifact was not read by the dated inspection. That leaves its state unknown; it does not establish that release-control implementation is missing. Some runtime status or contract-evaluation methods can mutate state, so this public explanation uses fixed records and source review rather than calling those methods.
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.
Scope limitation: 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 · 1 October 2026
Server-side order refusal
The original inspection records identified order attempts refused by the server-side risk check and the core sell block.
Scope limitation: 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 · 27 September 2026
Event window stated in the original: 26 September (KST)
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.
Scope limitation: 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 · 27 September 2026
These are bounded records, not a present-state dashboard or universal enforcement claim. Unobserved runtime coverage does not erase the implementation or behavior that the record actually supports.
What counts as enforcement
Inspect the component that consumes the permission.
A readable setting, a healthy endpoint and an allowed action are different observations. An enforcement claim needs the actual consuming path, its applicable permission and both accepted and refused cases.
The dated inspection records selected settings and particular refused paths. It does not establish universal coverage or a fresh census of every permission-writing surface. The release-authority artifact was not read; its state remains unknown, separately from the implementations and observations summarized above.
Technical scope and remaining evidence →
Dated supporting record
The original record preserves the observed approval summary, promotion state and inter-host gate modes with their original limits.
Neurobrick · systems, authority and evidence
Last updated · 22 October 2026