> Neurobrick is an AI governance architecture that separates AI decision proposals from execution authority. Implemented in multi-asset financial research and execution environments. The relationship between proposals, explicit permission, execution contexts and evidence of actual enforcement. [neurobrick]() [principles]() [architecture]() [capabilities]() [authority]() [observation]() [evidence]() [engineering]() [verification]() [scope]() 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 [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. 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) [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. 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 [Scope and original evidence →]() 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. [Original inspection →]() [SHA-256 →]() Neurobrick · systems, authority and evidence Last updated · 22 October 2026 [Public scope →]() [Canonical page]()