# Neurobrick > Neurobrick is an AI governance architecture that separates AI decision proposals from execution authority. Implemented in multi-asset financial research and execution environments. Document version: evidence-first-v5 Public content updated: 2026-10-10 The update date is editorial; each evidence record keeps its original observation date. ## System identity Neurobrick is an AI governance architecture that separates AI decision proposals from execution authority. Implemented in multi-asset financial research and execution environments spanning domestic and overseas equities, cryptocurrency spot, perpetual futures and options, and domestic and overseas futures and options. Coverage is engine and broker specific; reviewed integrations do not imply current live activation. ## Control 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 →]() ## Engine-specific market paths ### NeuroPublic Domestic and US equities; cryptocurrency spot, perpetual futures and options; a separate US equity-option integration. Path: KIS equity consumers, Binance exchange consumers and the separate Alpaca option branch. Scope: Generic KIS derivative scaffold branches are sealed. Source integrations do not establish every product is currently enabled. ### KR Rotation Domestic stocks and ETFs. Path: A scheduled KIS cash-order lane with its own arm, lease and submission journal. Scope: Its domestic mandate is not the desktop host's entire market scope. ### NeuroForAll Account-scoped domestic and overseas equity workers in the reviewed source snapshot. Path: Separate worker contexts, live-permission checks, submission recording and reconciliation. Scope: The local source mirror is not an attested current deployment or a statement that every account is eligible. ### Control Plane market access Cryptocurrencies, domestic and overseas equities, domestic and overseas futures and options. Path: Market-specific exchange and broker services, including dedicated KIS derivative order routes. Scope: This is a shared service layer, not a fourth independent engine or one universal central order-approval switch. ## Dated control observations 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. ## Implementation and observation meanings How to interpret status ## Not observed ≠ not implemented. A verification limitation qualifies a particular claim. It is not automatically a verdict that the underlying function does not exist. Source presence alone also does not prove a reachable or verified execution path. ### Implemented and observed in the stated scope IMPLEMENTED\_AND\_OBSERVED A specified behavior or state was observed in the recorded environment and window. This is not universal coverage or a fresh live-state claim. ### Implementation present; runtime effect not verified IMPLEMENTED\_NOT\_RUNTIME\_VERIFIED Source, an installed-source inspection or a local candidate exists. The relevant natural consumer behavior or current operating effect has not been established. ### Partial implementation or integration PARTIALLY\_IMPLEMENTED Named paths exist, while another named part is incomplete, sealed or not connected. Read the exact gap rather than treating the whole system as absent. ### Design only for this claim DESIGN\_ONLY An intended responsibility or interface is described, without an implementation bound to this particular claim. ### Unknown in the examined scope UNKNOWN The necessary source, observation or consumer identity was not available or not read. Unknown is neither permission nor evidence that a function is missing. ### Not observed is not not implemented Implementation existence, path reachability, a dated observation and verified operating effect are separate questions. Evidence that was not read cannot establish absence. ### Not implemented This requires evidence about a named searched code or execution scope. An unread artifact, a missing runtime observation or a design limitation alone is insufficient. ### Observed in a limited scope Keep the specific behavior, environment, original time and measured population. A refused attempt is a narrower observation than testing all accepted and refused cases. ### Verified for a specific execution path The actual consuming path, applicable inputs and accepted/refused or defective/corrected cases must be bound to the tested source and population. ### Not universally established Evidence for one path can coexist with missing coverage across other engines or markets. It does not erase the path that was actually examined. ## Historical findings and current reconciliation Historical findings and current reconciliation ## A past finding is preserved. Its closure needs new evidence. The review on 2026-10-10 separates original findings from later source and publication observations. UNKNOWN does not confirm a current defect or establish its closure. An implemented candidate with successful CI still needs its own operating verification. Public claims, original-record integrity, current candidate PR metadata and one pinned source inspection; no runtime or live-state execution. Current session ownership was not established. System owners retain implementation and runtime verification; this registry records public evidence and leaves unobserved scopes open for verification. [Reconciliation record and evidence IDs →]() [Reconciliation file SHA-256 →]() Dated reconciliation on 2026-10-10: 34 finding families — 0 CLOSED\_VERIFIED; 27 UNKNOWN; 1 OPEN\_CONFIRMED; 5 IMPLEMENTED\_AWAITING\_VERIFICATION; 1 HISTORICAL\_ONLY. These counts describe the dated public evidence registry, not confirmed current defects or fleet-wide operating verification. **Current status meanings** - CLOSED\_VERIFIED: correction and verification are linked to the original finding for an exact named scope. - IMPLEMENTED\_AWAITING\_VERIFICATION: implementation evidence exists; the claimed operating scope is not verified. - REMEDIATION\_IN\_PROGRESS: active remediation ownership is confirmed; completion is not established. - OPEN\_CONFIRMED: a new observation confirms the specific gap at its stated source or runtime scope. - HISTORICAL\_ONLY: the statement describes a prior observation rather than the present state. - STALE\_OR\_INACCURATE: a later scoped observation contradicts the current wording; the original remains preserved. - UNKNOWN: evidence or access is insufficient to determine current state. [Read the 34 finding families, original records and later observation scopes →]() ## Evidence navigation Read the [evidence index]() for the summary, environment, observation date, source identifier and original JSON pointers. The original inspection JSON carries the evidence scope and limits; it is part of the verification trail rather than a decorative appendix. Its SHA-256 identifies the original file and does not independently reproduce a private run. An unread source or unobserved runtime is not evidence that implementation is absent. Do not add populations from overlapping test selections or infer that a source inspection establishes present live activation. This guide links to the same published public pages. Read the stated scope and verification limits alongside any technical claim. A local test, publication or merge is not proof of current deployment or operating effect. ## Recommended reading order 1. [Neurobrick — AI Governance Architecture](): Neurobrick is an AI governance architecture that separates AI decision proposals from execution authority. Implemented in multi-asset financial research and execution environments. 2. [System architecture — Neurobrick](): Neurobrick is an AI governance architecture that separates AI decision proposals from execution authority. Implemented in multi-asset financial research and execution environments. Research, evaluation, authority, execution, observation and receipts with distinct execution contexts and scoped infrastructure evidence. 3. [Authority boundary — Neurobrick](): 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. 4. [Technical evidence and archive — Neurobrick](): Neurobrick is an AI governance architecture that separates AI decision proposals from execution authority. Implemented in multi-asset financial research and execution environments. Inspect dated engineering results, source and test populations, alongside an unchanged archive of original system and technical records. 5. [Verification standard — Neurobrick](): Neurobrick is an AI governance architecture that separates AI decision proposals from execution authority. Implemented in multi-asset financial research and execution environments. Historical findings, current scoped reconciliation, pinned local results and the evidence required for operating adoption and external reproduction. 6. [Engineering progress — Neurobrick](): Neurobrick is an AI governance architecture that separates AI decision proposals from execution authority. Implemented in multi-asset financial research and execution environments. Reproduced failures and scoped repairs to observation, provenance, input validation and recovery, with preserved historical sources. 7. [Observation and recovery — Neurobrick](): Neurobrick is an AI governance architecture that separates AI decision proposals from execution authority. Implemented in multi-asset financial research and execution environments. Interpretable observations, explicit unknowns and affected-component evidence for health and recovery claims. 8. [Public scope and technical limits — Neurobrick](): Neurobrick is an AI governance architecture that separates AI decision proposals from execution authority. Implemented in multi-asset financial research and execution environments. The scope of published architecture and engineering evidence, with separate requirements for enforcement, adoption, recovery and reproduction. 9. [Authority is the hard problem — Neurobrick](): Neurobrick is an AI governance architecture that separates AI decision proposals from execution authority. Implemented in multi-asset financial research and execution environments. The Neurobrick thesis: prediction is advisory; authority is explicit, bounded and evidenced. For a complete read, use [all published page text](). For a specific question, follow the relevant page and its original evidence links. Menu labels below identify their canonical URLs; use those links rather than guessing paths. ## Public pages - [Neurobrick — AI Governance Architecture](): Neurobrick is an AI governance architecture that separates AI decision proposals from execution authority. Implemented in multi-asset financial research and execution environments. - [System architecture — Neurobrick](): Neurobrick is an AI governance architecture that separates AI decision proposals from execution authority. Implemented in multi-asset financial research and execution environments. Research, evaluation, authority, execution, observation and receipts with distinct execution contexts and scoped infrastructure evidence. - [System capabilities — Neurobrick](): Neurobrick is an AI governance architecture that separates AI decision proposals from execution authority. Implemented in multi-asset financial research and execution environments. Market-specific execution paths, distinct execution contexts, explicit authority, input provenance and scoped engineering verification. - [Authority boundary — Neurobrick](): 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. - [Observation and recovery — Neurobrick](): Neurobrick is an AI governance architecture that separates AI decision proposals from execution authority. Implemented in multi-asset financial research and execution environments. Interpretable observations, explicit unknowns and affected-component evidence for health and recovery claims. - [Technical evidence and archive — Neurobrick](): Neurobrick is an AI governance architecture that separates AI decision proposals from execution authority. Implemented in multi-asset financial research and execution environments. Inspect dated engineering results, source and test populations, alongside an unchanged archive of original system and technical records. - [Engineering progress — Neurobrick](): Neurobrick is an AI governance architecture that separates AI decision proposals from execution authority. Implemented in multi-asset financial research and execution environments. Reproduced failures and scoped repairs to observation, provenance, input validation and recovery, with preserved historical sources. - [Verification standard — Neurobrick](): Neurobrick is an AI governance architecture that separates AI decision proposals from execution authority. Implemented in multi-asset financial research and execution environments. Historical findings, current scoped reconciliation, pinned local results and the evidence required for operating adoption and external reproduction. - [Public scope and technical limits — Neurobrick](): Neurobrick is an AI governance architecture that separates AI decision proposals from execution authority. Implemented in multi-asset financial research and execution environments. The scope of published architecture and engineering evidence, with separate requirements for enforcement, adoption, recovery and reproduction. - [Authority is the hard problem — Neurobrick](): Neurobrick is an AI governance architecture that separates AI decision proposals from execution authority. Implemented in multi-asset financial research and execution environments. The Neurobrick thesis: prediction is advisory; authority is explicit, bounded and evidenced. ## Menu names and canonical URLs Use these actual links when a menu label differs from the URL. Menu-labelled aliases redirect to the same page. - principles: [/thesis]() · [Markdown]() · [Readable HTML]() - authority: [/boundary]() · [Markdown]() · [Readable HTML]() - observation: [/oversight]() · [Markdown]() · [Readable HTML]() - engineering: [/progress]() · [Markdown]() · [Readable HTML]() - scope: [/limits]() · [Markdown]() · [Readable HTML]() ## Browser-readable HTML - [Readable page index]() - [Neurobrick — AI Governance Architecture]() - [System architecture — Neurobrick]() - [System capabilities — Neurobrick]() - [Authority boundary — Neurobrick]() - [Observation and recovery — Neurobrick]() - [Technical evidence and archive — Neurobrick]() - [Engineering progress — Neurobrick]() - [Verification standard — Neurobrick]() - [Public scope and technical limits — Neurobrick]() - [Authority is the hard problem — Neurobrick]()