# Neurobrick — published public pages > Neurobrick is an AI governance architecture that separates AI decision proposals from execution authority. Implemented in multi-asset financial research and execution environments. Complete text of the same published pages, retaining their canonical links, evidence and scope limits. > Neurobrick is an AI governance architecture that separates AI decision proposals from execution authority. Implemented in multi-asset financial research and execution environments. [neurobrick]() [principles]() [architecture]() [capabilities]() [authority]() [observation]() [evidence]() [engineering]() [verification]() [scope]() NEUROBRICK · A GOVERNANCE ARCHITECTURE # Prediction is not the hard problem. Authority is. 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. [Markets, engines and controls]() [Read the principles]() The design question What may the system do when its inference is wrong? AI proposals supply information. Engine-local permission, portfolio controls and risk checks govern execution paths, with separate broker or exchange boundaries and scoped evidence. [Inspect the authority model →]() Design commitments ## Make the conditions for action explicit. 01 ### A proposal carries information. Authority carries permission. Inference supplies a candidate. Its score does not authorize an action. Permission is evaluated in the engine and context that consume it. 02 ### Shared infrastructure has a bounded role. Research, inference and fleet tooling support several systems. Execution context and permission remain inside the relevant engine boundary. 03 ### Evidence has an identity and a scope. A result retains its input, source revision, test population and observation window. Local behavior, installed code and natural operating effect are measured separately. These are architectural commitments. Enforcement and integration coverage must be established on the specific path being claimed. Role separation · design model ## Six responsibilities. Explicit handoffs. 1. 01 ### Research Inputs retain source, observation time and applicability. 2. 02 ### Evaluation A fixed candidate is evaluated against a declared policy. 3. 03 ### Authority Permission has an owner, scope and consuming boundary. 4. 04 ### Execution An engine acts inside its own execution context. 5. 05 ### Observation Missing or unreadable evidence remains unknown. 6. 06 ### Receipts Results retain identity, source and the measured population. This model describes responsibilities and intended handoffs. It does not establish a completed end-to-end deployment across every engine. Separate systems · shared support ## One architecture. Distinct execution contexts. ### NeuroPublic Research and multi-market execution A research and execution environment covering cryptocurrencies and domestic and overseas equities. Cryptocurrency spot, perpetual futures and options use separate exchange paths; equity orders use broker-specific paths. Data readiness, product admission and execution authority remain separate gates. ### KR Rotation Independent domestic equity rotation A dedicated scheduled rotation engine for domestic stocks and ETFs, with its own execution and account boundary. Its focused mandate does not describe every trading capability available on the desktop host. ### NeuroForAll Account-scoped execution engine The reviewed source snapshot contains domestic and overseas equity workers with separate account contexts, permission checks, submission recording and reconciliation. Account separation describes an execution boundary; this source review does not establish current deployment or public service availability. ### Control Plane Coordination and shared market access A coordination and integration layer supplying state, portfolio controls, release conditions, evidence services and market-specific exchange and broker adapters. Its integrations cover cryptocurrencies, domestic and overseas equities, and domestic and overseas futures and options. Each consuming execution path retains its own permission boundary; this layer is not counted as a fourth independent execution system. [Roles, infrastructure and integration boundaries →]() 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. Public scope ## Architecture, authority and technical evidence. Public material covers system architecture, authority boundaries and scoped technical evidence. Returns, balances and proprietary strategy parameters remain private. [Read the principles →]() Copy for AI [Full Documentation]() [Home in Markdown]() [AI reading guide]() [Readable text index]() Neurobrick · systems, authority and evidence Last updated · 10 October 2026 [host@neurobrick.ai]() [Canonical page]() > 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. [neurobrick]() [principles]() [architecture]() [capabilities]() [authority]() [observation]() [evidence]() [engineering]() [verification]() [scope]() System architecture # One fleet. Separate responsibilities. Research, inference and delivery share infrastructure. Each execution engine retains its own context and permission boundary. Evidence connects a claim to the path and revision that were actually examined. Role separation · design model ## Six responsibilities. Explicit handoffs. 1. 01 ### Research Inputs retain source, observation time and applicability. 2. 02 ### Evaluation A fixed candidate is evaluated against a declared policy. 3. 03 ### Authority Permission has an owner, scope and consuming boundary. 4. 04 ### Execution An engine acts inside its own execution context. 5. 05 ### Observation Missing or unreadable evidence remains unknown. 6. 06 ### Receipts Results retain identity, source and the measured population. This model describes responsibilities and intended handoffs. It does not establish a completed end-to-end deployment across every engine. Logical systems Current system descriptions are separate from the archived infrastructure inspection below. ## NeuroPublic Research and multi-market execution A research and execution environment covering cryptocurrencies and domestic and overseas equities. Cryptocurrency spot, perpetual futures and options use separate exchange paths; equity orders use broker-specific paths. Data readiness, product admission and execution authority remain separate gates. ## KR Rotation Independent domestic equity rotation A dedicated scheduled rotation engine for domestic stocks and ETFs, with its own execution and account boundary. Its focused mandate does not describe every trading capability available on the desktop host. ## NeuroForAll Account-scoped execution engine The reviewed source snapshot contains domestic and overseas equity workers with separate account contexts, permission checks, submission recording and reconciliation. Account separation describes an execution boundary; this source review does not establish current deployment or public service availability. ## Control Plane Coordination and shared market access A coordination and integration layer supplying state, portfolio controls, release conditions, evidence services and market-specific exchange and broker adapters. Its integrations cover cryptocurrencies, domestic and overseas equities, and domestic and overseas futures and options. Each consuming execution path retains its own permission boundary; this layer is not counted as a fourth independent execution system. Market coverage and host roles ## A host role does not limit its market coverage. ### M3 · research and execution The M3 environment combines research with cryptocurrency and domestic and overseas equity execution. Research is one responsibility of this host, rather than its entire market scope. ### Desktop · execution and market integration The desktop supports cryptocurrencies and domestic and overseas equities alongside the focused KR Rotation engine. Its Control Plane market-access layer also implements domestic and overseas futures and options order 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. The research source includes LLM routing and AVA bridge clients. AVA server implementation, model residency and current distributed inference were not verified by this source review. Market coverage reflects reviewed implementation and owner-confirmed host roles. Overseas coverage follows the exchanges and products supported by each broker. Available integrations do not imply that every product is currently enabled for live execution. Shared support ## Infrastructure supports execution without granting authority. Local inference, observation, CI, storage and control services serve different roles. A compute host, a running service and an execution permission are separate facts. The unified path across all engines remains under verification. A process being present does not establish that every intended handoff is complete. [How authority is represented →]() **Archived infrastructure observation** Inspected operating footprint ## 7 compute hosts. 1 shared storage appliance. **Compute hosts** 7 Control, execution, inference, observation and CI **Storage** 1 NAS Shared storage; counted separately from compute **Execution systems** 3 Independent logical execution boundaries **Control services** 7 Running containers on one control host Mesh registration: 9 devices, 9 online. These are network identities, not the physical operating-box count. A dedicated-fabric compute host is outside this mesh; inactive client devices are inside it. Read-only inspection of the known operating fleet. Point-in-time internal disclosure, not live telemetry or independent attestation. [System review JSON]() [SHA-256]() [Historical evidence]() This is an archived inspection, not live capacity or a current health dashboard. Neurobrick · systems, authority and evidence Last updated · 10 October 2026 [Public scope →]() [Canonical page]() > 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. [neurobrick]() [principles]() [architecture]() [capabilities]() [authority]() [observation]() [evidence]() [engineering]() [verification]() [scope]() System capabilities # Build systems that can explain their conditions for action. The capabilities below combine architectural responsibilities and specific local evidence. Each links to the scope that supports it. ## Connect distinct markets Cryptocurrency markets, domestic and overseas equities, and listed futures and options use market-specific exchange and broker paths. Coverage follows each system and supported product, rather than a single host label. Reviewed implementation scope and owner-confirmed host roles [Inspect the supporting material →]() ## Separate execution contexts Independent engines retain their own account context and permission boundary. Shared support does not create one universal execution gate. Architecture and observed integration limits [Inspect the supporting material →]() ## Keep authority explicit Inference supplies proposals. Permission must be attributable, scoped and readable by the path that consumes it. Design model; selected settings have dated observations [Inspect the supporting material →]() ## Question input evidence Source linkage, observation contracts and point-in-time provenance determine whether a research input is acceptable. A dated readiness run recorded a refusal to continue [Inspect the supporting material →]() ## Make failure observable Local counterexamples exercise initialization failure, unreadable output and incomplete observations. Scoped repairs are tested; operating adoption is separate [Inspect the supporting material →]() ## Preserve provenance Reused values retain their original observation time. Missing or invalid evidence is not counted as a verified result. Local producer and consumer behavior [Inspect the supporting material →]() ## Review the actual implementation Results retain source pins, original failures and the measured population. Negative controls test whether verification can reject broken behavior. Internal technical evidence with explicit reproduction limits [Inspect the supporting material →]() A capability description is not certification of every live path. The evidence pages distinguish design, tested local behavior and natural operating observations. Neurobrick · systems, authority and evidence Last updated · 10 October 2026 [Public scope →]() [Canonical page]() > 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 · 10 October 2026 [Public scope →]() [Canonical page]() > 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. [neurobrick]() [principles]() [architecture]() [capabilities]() [authority]() [observation]() [evidence]() [engineering]() [verification]() [scope]() Observation model # An observation must survive its own uncertainty. The design preserves missing, unreadable and incomplete evidence. Observation quality is evaluated separately from the state of the system being observed. ## Presence A reachable host or running process is evidence of presence. It does not establish current permission, completed work or a healthy application. ## Interpretable state A health claim needs readable evidence with its own observation time and coverage. Unknown and unreadable observations remain visible in their populations. ## Affected component A recovery claim needs fresh evidence from the component that was affected, including domain output. A successful command does not establish restoration. Tested local behavior ## Missing output cannot quietly become a pass. Published counterexamples exercise missed initialization failures, unreadable captured output, carried observation time and unsupported recovery counts. Their local tests retain the original failures and fixed source. [Failure, repair and verification →]() The local implementation and recorded tests are present. Observer independence, full fleet coverage and natural adoption are different claims and require their own observations; a missing observation does not erase the tested behavior. Archived operating observation Scheduler results, storage mounts, available probe paths and service observations remain in the dated record. They are not presented as a live dashboard or a new recovery attestation. [Original record →]() [SHA-256 →]() Neurobrick · systems, authority and evidence Last updated · 10 October 2026 [Public scope →]() [Canonical page]() > 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. [neurobrick]() [principles]() [architecture]() [capabilities]() [authority]() [observation]() [evidence]() [engineering]() [verification]() [scope]() Technical evidence and fixed records # Evidence you can inspect. History you can identify. Public engineering results retain their source, measured population and limits. Original records stay available at their original dates; a new summary does not rewrite an earlier observation. Scoped engineering review ## Implemented paths and dated controls Control states, specific refusals and source implementations are summarized below with their original dates, environments and integrity references. [Follow summary, scope and source →]() Verification method ## The observer must preserve uncertainty Output interpretation and failure cleanup are tested on their actual paths, including negative controls that reject broken implementations. [Original record →]() [SHA-256 →]() Finding history and later observations The 2026-10-10 reconciliation links preserved findings to later source and candidate CI observations. It does not establish operating closure. [Finding summaries and current status →]() [Original reconciliation JSON →]() [File integrity SHA-256 →]() Evidence index ## Summary → scope → original record. Read what was implemented or observed, then follow the record that supports the exact claim. Different windows, environments and test populations remain separate. ### Portfolio kill-switch state Implemented and observed in the stated scope Record observed/reviewed · 1 October 2026 The inspection reported the portfolio kill switch as ARMED, separately from the approval-axis summary. Environment / scope: Control-plane state report in the original inspection. Limit: 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. [Read the original supporting JSON →]() [Verify the original file SHA-256 →]() **Evidence identity, source and integrity** **Evidence ID** neurobrick-system-review-2026-10-01 **Original JSON pointers** /observed\_states/kill\_switch **Source commits by recorded role** Not recorded in this source; no commit is inferred. **Original file SHA-256** 399267ec9e1d081ddc33d2a42f13e0144038718a62fc2fd469db621258bbe252 **Current operating coverage** Not verified by this presentation. A checksum identifies the file and does not independently reproduce its private run. ### Server-side order refusal Implemented and observed in the stated scope Record observed/reviewed · 27 September 2026 The original inspection records identified order attempts refused by the server-side risk check and the core sell block. Environment / scope: Identified primary-engine attempts in the record's stated period. Event window stated in the original: 26 September (KST). The record date above is the inspection date. Limit: 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. [Read the original supporting JSON →]() [Verify the original file SHA-256 →]() **Evidence identity, source and integrity** **Evidence ID** neurobrick-system-review-2026-09-27 **Original JSON pointers** /authority/3/detail **Source commits by recorded role** Not recorded in this source; no commit is inferred. **Original file SHA-256** b1021299dd28c133c3ffb121463722add5d6dbc3741c4a95f476a5ef7e35135b **Current operating coverage** Not verified by this presentation. A checksum identifies the file and does not independently reproduce its private run. ### Opt-in, lease and certified-trial conditions Implemented and observed in the stated scope Record observed/reviewed · 27 September 2026 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. Environment / scope: Autonomous submission attempts in the inspected half-hour. Limit: 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. [Read the original supporting JSON →]() [Verify the original file SHA-256 →]() **Evidence identity, source and integrity** **Evidence ID** neurobrick-system-review-2026-09-27 **Original JSON pointers** /capabilities/1/detail **Source commits by recorded role** Not recorded in this source; no commit is inferred. **Original file SHA-256** b1021299dd28c133c3ffb121463722add5d6dbc3741c4a95f476a5ef7e35135b **Current operating coverage** Not verified by this presentation. A checksum identifies the file and does not independently reproduce its private run. ### Kill and release event identity Implementation present; runtime effect not verified Record observed/reviewed · 30 September 2026 The source review records event identity in the kill and release producer. Environment / scope: Merged and installed source inspected in the original review. Limit: The inspected live ledger was empty and no event was triggered for that review. An actual event identifier and natural trigger/clear execution remain unknown. [Read the original supporting JSON →]() [Verify the original file SHA-256 →]() **Evidence identity, source and integrity** **Evidence ID** neurobrick-engineering-progress-2026-09-30 **Original JSON pointers** /earlier\_advances/1/detail **Source commits by recorded role** - This recorded claim: bc89dacf89680597bb1be8d833a79128be103aa8 · EmergencyKillSwitch.trigger / clear **Source symbol** EmergencyKillSwitch.trigger / clear **Original file SHA-256** f3f85024f0a1a8a03285aa27b836130c038d2b0d020057650b85cbf94d7725ee **Current operating coverage** Not verified by this presentation. A checksum identifies the file and does not independently reproduce its private run. ### Observer output and process cleanup Implementation present; runtime effect not verified Record observed/reviewed · 2 October 2026 The recorded selection passed 18 cases and rejected six defective controls. It separates actual child behavior from controlled cleanup dependencies. Environment / scope: Private isolated process-observer validation. Limit: The record does not prove descendant reaping, current installation or natural operating adoption. The core repository is private; the public checksum does not reproduce the private run. [Read the original supporting JSON →]() [Verify the original file SHA-256 →]() **Evidence identity, source and integrity** **Evidence ID** neurobrick-verification-2026-10-02 **Original JSON pointers** /verification/passed · /verification/skipped · /verification/negative\_controls\_rejected **Source commits by recorded role** - This recorded claim: d6e06a514f5bf07ad7d1d3205975c87a9d611cd9 · kill\_tree / run\_pytest\_once **Source symbol** kill\_tree / run\_pytest\_once **Original file SHA-256** f215c307fcdd340194db32b7b8791147ad8f2da1158ca91c17cb716230535ddd **Current operating coverage** Not verified by this presentation. A checksum identifies the file and does not independently reproduce its private run. ### Committed risk-verdict candidate Implementation present; runtime effect not verified Record observed/reviewed · 4 October 2026 The direct risk-verdict selection changed from 16 failures to 18 passing cases. The broader selection retained 431 existing cases and passed 433 after the patch. Environment / scope: Private isolated Guardian candidate and compatibility selection. Limit: The direct 18 cases are included in the broader 433, so they are not added together. Candidate CI is distinct from later-main compatibility, current consumer identity and natural operating effect. [Read the original supporting JSON →]() [Verify the original file SHA-256 →]() **Evidence identity, source and integrity** **Evidence ID** neurobrick-engineering-2026-10-04 **Original JSON pointers** /guardian/direct/before/failed · /guardian/direct/after/passed · /guardian/focused/after/passed · /guardian/focused/existing\_cases\_retained · /guardian/direct\_is\_subset\_of\_focused **Source commits by recorded role** - This recorded claim: e9a241aca95ffa8713fad5d56b2fc6280a0ffe75 **Original file SHA-256** 64f5a5b70d7c616cab850fd5b84c4696f027cd18cad589ae40e09fa0d9f7804d **Current operating coverage** Not verified by this presentation. A checksum identifies the file and does not independently reproduce its private run. ### Input measurement and decision identity Implementation present; runtime effect not verified Record observed/reviewed · 30 September 2026 The review covers input measurement, observation freshness and decision identity through their producer and consumer paths. Environment / scope: Frozen local source candidates with separately recorded populations. Limit: The measurement, freshness and lineage selections have different sources and may overlap. Their counts are not a whole-system total, and local validation is not natural operating adoption. [Read the original supporting JSON →]() [Verify the original file SHA-256 →]() **Evidence identity, source and integrity** **Evidence ID** neurobrick-engineering-progress-round2-2026-09-30 **Original JSON pointers** /improvements/0/tests · /improvements/1/tests · /improvements/2/tests **Source commits by recorded role** - Input measurement: f3cadaedbaf3a0c00acc34c3def18780d153169c · \_measure\_jsonl\_multi / \_assess\_input / run\_once / read\_research\_lab - Observation freshness: 1fdceaac6d4ab173b38f50ff5552457b72eac28a · build\_freshness / build\_receipt / render - Decision identity: 87400402b7839632bed2bd8fbefa4b0a2856cf82 · Node.\_\_post\_init\_\_ / Edge.\_\_post\_init\_\_ / own\_decision\_identity; R-K1 → R-K4 → BuildContext.absorb → metrics **Original file SHA-256** 3c1fe70623b60f3d325b1e7bc9359c18236bf0cb84726e98399af6c221f75d97 **Current operating coverage** Not verified by this presentation. A checksum identifies the file and does not independently reproduce its private run. ### Heartbeat, provenance and recovery observation Implementation present; runtime effect not verified Record observed/reviewed · 30 September 2026 The source selections cover heartbeat validity, retained observation time and direct affected-component recovery evidence. Environment / scope: Private focused producer-to-consumer validation. Limit: These are separately scoped internal selections. Historical publication runs also recorded skipped cases; those cases were not evaluated. No natural deployment or recovery result is created by presenting these tests. [Read the original supporting JSON →]() [Verify the original file SHA-256 →]() **Evidence identity, source and integrity** **Evidence ID** neurobrick-operational-proof-publication-2026-09-30 **Original JSON pointers** /improvements/0/independent\_test\_count · /improvements/1/independent\_test\_count · /improvements/2/independent\_test\_count **Source commits by recorded role** - Heartbeat validation: 9fa70597d98f91c850b549258bd5dbf9488caf45 · \_state\_age / run\_once\_sync / read\_daemon\_health / \_section\_daemons - Retained observation provenance: 5918e95232754e48d178f37249528526215c2dc5 · \_read\_capital\_flows / evaluate / read\_trading - Affected-target recovery observation: 3cc129f4a2675855843dc367ed8aadc5de3e20d0 · daemon\_health\_master.evaluate / \_recovery\_health\_in\_window / auto\_recovery\_effectiveness\_tracker.evaluate **Original file SHA-256** 57d41bba421bbe3fe853c78153746e183ba755e90745432de7b165133fbf2624 **Current operating coverage** Not verified by this presentation. A checksum identifies the file and does not independently reproduce its private run. 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. **Archived system inspection** Inspected operating footprint ## 7 compute hosts. 1 shared storage appliance. **Compute hosts** 7 Control, execution, inference, observation and CI **Storage** 1 NAS Shared storage; counted separately from compute **Execution systems** 3 Independent logical execution boundaries **Control services** 7 Running containers on one control host Mesh registration: 9 devices, 9 online. These are network identities, not the physical operating-box count. A dedicated-fabric compute host is outside this mesh; inactive client devices are inside it. Read-only inspection of the known operating fleet. Point-in-time internal disclosure, not live telemetry or independent attestation. [System review JSON]() [SHA-256]() [Historical evidence]() This record contains the original service, input-lineage, permission-setting and infrastructure observations. It is a fixed internal inspection, not live telemetry or an independent attestation. [Complete original record →]() [SHA-256 →]() Complete public evidence archive ## Original artifacts. Original checksums. All original files remain available. Their dates, populations, field meanings and disclosure limits are historical facts; they are not current website acceptance goals. Engineering · record 01 [Original supporting JSON]() [File integrity SHA-256]() Verification · record 02 [Original supporting JSON]() [File integrity SHA-256]() System review · record 03 [Original supporting JSON]() [File integrity SHA-256]() System review · record 04 [Original supporting JSON]() [File integrity SHA-256]() Operational proof · record 05 [Original supporting JSON]() [File integrity SHA-256]() Operational proof publication · record 06 [Original supporting JSON]() [File integrity SHA-256]() Engineering progress · record 07 [Original supporting JSON]() [File integrity SHA-256]() Engineering progress round2 · record 08 [Original supporting JSON]() [File integrity SHA-256]() System review · record 09 [Original supporting JSON]() [File integrity SHA-256]() System review · record 10 [Original supporting JSON]() [File integrity SHA-256]() Development review · record 11 [Original supporting JSON]() [File integrity SHA-256]() Current · record 12 [Original supporting JSON]() [File integrity SHA-256]() Pm receipt · record 13 [Original supporting JSON]() [File integrity SHA-256]() Am · record 14 [Original supporting JSON]() [File integrity SHA-256]() How to read the evidence A checksum identifies the public file. It does not reproduce a private run. Local tests establish the specific behavior and population recorded; deployment, natural consumer behavior and external reproduction require separate observations. [Public scope and technical limits →]() Neurobrick · systems, authority and evidence Last updated · 10 October 2026 [Public scope →]() [Canonical page]() > 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. [neurobrick]() [principles]() [architecture]() [capabilities]() [authority]() [observation]() [evidence]() [engineering]() [verification]() [scope]() Engineering progress # Repair the actual path. Keep the original failure. The examples below show specific changes to failure observation and evidence handling. Each retains its tested source and population. Local verification is separate from operating adoption. Recorded scoped candidates ## Initialization failure and committed risk verdicts. The complete before/after populations are kept on one verification page. They are examples within the wider evidence index, not the total validation scope. [Read the source, cases and runtime limits →]() [Later source and publication reconciliation →]() Earlier evidence-handling review ## Health, provenance and recovery need interpretable evidence. Local counterexamples expose false positive paths: an unreadable heartbeat, a reused report with a new apparent timestamp, and a recovery claim with no direct target observation. ### Implementation and local behavior Locally verified Pinned changes, actual producer/consumer counterexamples and separate internal source review. Required local repository checks passed on every exact revision; platform skips remain unevaluated. Draft publication does not establish operating adoption. ### Operating adoption and effect Not verified No installed-version receipt or natural-run before/after effect was obtained for these revisions. ### External reproducibility and attestation Not verified Reviewers are internal agents. Private source references and public file hashes do not constitute independent attestation. ### A file touch cannot establish operating health Dated local review **Before** A running synthetic process with a freshly touched but malformed or timestamp-less state file was classified HEALTHY. **After** Uninterpretable heartbeat evidence provides no age. A running target is UNKNOWN unless an existing degradation priority applies; unknown targets stay in the total population but outside healthy and operational numerators. Six base failures became 17 passing heartbeat tests. The internal reviewer independently repeated 17; a further isolated run of the focused and adjacent selection passed 88 tests. Existing staleness and classification priorities remain. PID presence and a parsed timestamp do not establish installed code identity or successful application work. Historical publication state: Reviewed Draft published at the pinned revision. Required local repository selection: 922 passed and 60 skipped, exit code 0. The platform-specific skips are not evaluated. No verified deployment or natural operating effect. ### Carried data keeps its original observation time Dated local review **Before** Partial unreadable input could be treated as a complete record set, while carried report values acquired a fresh apparent observation time. **After** Partial unreadable input follows the existing degraded path. Carried values retain degraded status, carry markers and their original observation time across repeated publication; legacy records acquire no fabricated provenance. The actual producer-to-dashboard base failed three cases. The final combined selection passed 109 tests, including 47 focused tests; the internal reviewer independently repeated 47. A pre-integration schema suite passed 39 tests. The tested producer and dashboard preserve degraded status, carry markers and original observation time. Arithmetic and authority behavior were unchanged; live reconciliation and operating adoption are not established. Historical publication state: Reviewed Draft published at the pinned revision. Required local repository selection: 922 passed and 60 skipped, exit code 0. The platform-specific skips are not evaluated. No verified deployment or natural operating effect. ### Recovery requires a direct observation of the affected target Dated local review **Before** A successful recovery attempt could be counted effective when no health history existed, the observation was outside the window, or only other targets were measured. **After** The producer emits untruncated direct HEALTHY targets. The consumer requires target evidence in the configured window, gives direct unhealthy observations priority, and retains unknowns outside verified and effective counts. Seven initial base failures and five further review counterexamples were reproduced. Final 69 passed, including the actual producer-to-consumer path; the internal independent reviewer repeated 69. HEALTHY remains process/log health, not proof of completed domain work or durable restoration. Naive health timestamps, malformed target evidence and legacy absence remain unknown. Historical publication state: Reviewed Draft published at the pinned revision. Required local repository selection: 922 passed and 60 skipped, exit code 0. The platform-specific skips are not evaluated. No verified deployment or natural operating effect. [Original inputs, outcomes and sources →]() [SHA-256 →]() Original field meanings and disclosure limits remain in the fixed record. This technical summary changes the presentation, not the historical result. Reproduction of the original evaluations requires access to the private source and tests. Earlier local engineering review ## Input validity and identity remain explicit. ### Incomplete input cannot become ready Dated local review **Before** Two timestamp-qualified rows plus 598 invalid timestamp rows could satisfy a 600-record readiness threshold; malformed tails were ignored and mixed naive/aware times could fail the cycle. **After** Only timestamp-qualified object rows contribute records, depth and diversity. Partial invalid evidence becomes unknown with explicit diagnostics, visible in the report and dashboard. 83 tests passed on the final frozen tree. The independent reviewer repeated 41 measurement and 3 actual dashboard-consumer tests. Base counterexamples failed before the fix. All absent inputs remain missing; partial invalid inputs become unknown. Completeness covers only listed/discovered files, and older reports acquire no invented unknown count. Freshness, PIT correctness and research quality are not certified. Historical publication state: Reviewed Draft \#4916 updated; exact-head CI was queued or running at this review. ### Unknown observations cannot inflate the clean rate Dated local review **Before** Three UNKNOWN or UNPARSED observations could produce a clean 3/3 result, presented as 100%. **After** Only evaluable states enter the rate. Unknown, unparsed and unprobed rows remain visible and excluded from both sides; no evaluable observations yield 0/0 with no rate. 302 tests and 462 subtests passed. The independent reviewer repeated 15 regressions; the base failed 8 of those cases. This rate describes an evaluable subset, not whole-fleet coverage. Original rows, states and receipt schema are preserved. Historical operating receipts were not rewritten. Historical publication state: Reviewed Draft \#1500; exact-head CI was queued or running at this review. ### Missing decision identity cannot establish lineage Dated local review **Before** Two executed orders sharing a blank native decision reference could inherit one signal and falsely count as linked: 2/2 in both executed and strict synthetic metrics. **After** Blank native decision references retain raw evidence but cannot establish counted or trace links. Both synthetic metrics become 0/2 while both orders stay in the denominators. 275 full lineage tests and 97 adjacent tests passed. The independent reviewer repeated 14 identity regressions through the real schema, deserialization, trace and rule chain. Direct nonstring native decision references are rejected. Normal opaque IDs, multiple children and content identities remain compatible. Already stringified producer IDs cannot reveal their original type; missing live DCA identities remain unresolved. Historical publication state: Reviewed Draft \#4923; exact-head CI was queued or running at this review. [Complete dated review →]() [SHA-256 →]() Historical source and operating observations Earlier identity changes, source installation observations and linkage measurements remain in the original records. Their populations are not added to the local test populations above. No new operating effect is established by this presentation. [Read the full fixed archive →]() Neurobrick · systems, authority and evidence Last updated · 10 October 2026 [Public scope →]() [Canonical page]() > 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. [neurobrick]() [principles]() [architecture]() [capabilities]() [authority]() [observation]() [evidence]() [engineering]() [verification]() [scope]() Verification standard · dated observations # A claim is only as strong as its weakest observation. We improve the system by reproducing a wrong result, repairing its actual code path and testing whether a broken implementation is rejected. Every result keeps its source, population and limits. Specific local behavior verified Operating effect unverified The unverified operating scope here belongs to the named local candidates. It does not mean trading or control implementation is absent. Other dated control observations and source selections are separate evidence families. [Control observations and wider evidence index →]() Evidence chain ## Observation → counterexample → repair → independent review. 1. 01 Preserve the original failure 2. 02 Exercise the actual code path 3. 03 Reject bad implementations 4. 04 Review the same source bytes Publication, installed code and natural operating effect require their own observations. Passing this chain for one change does not certify the whole system. Scoped engineering review ## A first failure must be visible. A collector can fail during initialization, before creating its normal state file. Its failure was recorded in a separate heartbeat file, but the detector skipped that record. The local repair makes this first failure visible for current fleet members while preserving alert routing and duplicate suppression. Specific local repair verified Operating effect unverified **Before repair** 5 of 15 cases failed Includes two actual collector initialization failures missed by the detector. **After repair** 15 of 15 cases passed The same cases, with no errors or skips. **Existing monitoring selection** 128 / 128 passed All existing cases retained. This is a scoped selection, not a full-system result. The tests call the actual collector, client constructor, state writer and detector in an isolated environment. They also cover a preserved domain cursor, one scan per daemon, cleared failures and excluded orphan heartbeats. This demonstrates a reachable code defect; it does not establish that it occurred in production. ### Risk decisions must use a committed verdict. A separate Guardian candidate was checked against a pinned main tree. Its direct selection changed from 16 failures among 18 cases to 18 passing cases. The broader selection retained all 431 existing cases and passed 433 after the patch. The 18 direct cases are included in the 433 broader cases. These populations are not added together. The candidate's required CI succeeded on its own exact head; compatibility and required CI for main 6ee6d730, observed in the 4 October 2026 at 22:24 KST record, were unverified in that record. The current reconciliation records later candidate publication checks separately. ### What this evidence still does not establish The 4 October 2026 at 22:24 KST record did not verify the actual operating checkout and execution owner, loaded consumer revision, natural consumer completion, or rollback restoration with fresh output. A current operating census was not performed in the later public-claim audit. This local review does not establish public reproduction or external attestation. [Dated engineering result and source pins →]() [SHA-256 →]() **Source, review and reproduction limits** Separate internal read-only review checked the actual source and original test records. Four malformed evidence controls were rejected by the same reader. The core repository is private; published hashes identify internal bytes and are not an independent external attestation or public reproduction package. stale\_daemon\_detector.run\_once\_sync · base 131d6b70fe3cd42d4c3f24cd910b609fb064136f Repaired source SHA-256 18aacf166bef2721b26b30dc2fb12d1cf4d75a743be9e04596cbc7ed33ce14aa Guardian candidate e9a241aca95ffa8713fad5d56b2fc6280a0ffe75 · tested main 83d3227d3cc0c491e37c9da46f702b7201396874 The earlier test-process probe below retains its own date, source and separate 18-case population. 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 →]() ### NB-CF01 · End-to-end evidence linkage **Historical observation · 2026-10-01** None of the 772 broker-accepted stock orders carries a decision identifier; no accepted order on any venue is linked to a research signal (0 of 4,466; only stock-brokerage orders have a rule that can link one); and no index rule yet records the authority behind a decision, so a governed decision cannot be counted. The research-to-authorized-execution-to-accounting path is not established. **Current status · checked 2026-10-10** UNKNOWN No new observation in this audit establishes the current operating state for this claim. The dated finding remains available; UNKNOWN is neither closure nor confirmation of a present defect. Scope: research-to-authority-to-execution-to-accounting across engines. An identified system owner must provide a commit-pinned observation for this exact scope before operating closure can be published. [Original finding →]() [Original file SHA-256 →]() ### NB-CF02 · Accepted-order decision identity **Historical observation · 2026-10-01** A daily lineage index (latest completed build 30 September) measures the path and a scheduled readiness run gates its first stage. None of the 772 broker-accepted stock orders carries a decision identifier yet, so no stock order links a decision to its accounting. A complete repeatable path is not yet established. **Current status · checked 2026-10-10** UNKNOWN No new observation in this audit establishes the current operating state for this claim. The dated finding remains available; UNKNOWN is neither closure nor confirmation of a present defect. Scope: historical accepted stock-order population. An identified system owner must provide a commit-pinned observation for this exact scope before operating closure can be published. [Original finding →]() [Original file SHA-256 →]() ### NB-CF03 · Authority-event linkage **Historical observation · 2026-10-01** Give authority events their own identifiers so a governed decision can be counted, and read the release-authority artifact beside the approval axis. **Current status · checked 2026-10-10** UNKNOWN No new observation in this audit establishes the current operating state for this claim. The dated finding remains available; UNKNOWN is neither closure nor confirmation of a present defect. Scope: decision-to-authority index linkage. An identified system owner must provide a commit-pinned observation for this exact scope before operating closure can be published. [Original finding →]() [Original file SHA-256 →]() ### NB-CF04 · DCA identity adoption **Historical observation · 2026-09-30** Merged and installed source contains identity minting. Observed live rows still lack decision IDs; runtime adoption is unresolved. **Current status · checked 2026-10-10** UNKNOWN No new observation in this audit establishes the current operating state for this claim. The dated finding remains available; UNKNOWN is neither closure nor confirmation of a present defect. Scope: DCA producer and natural consumer adoption. An identified system owner must provide a commit-pinned observation for this exact scope before operating closure can be published. [Original finding →]() [Original file SHA-256 →]() ### NB-CF05 · Research readiness input failure **Historical observation · 2026-10-01** The latest research readiness run stopped at its data-panel lineage check with 17 of 42 factor checks failing, so no research observation started. **Current status · checked 2026-10-10** UNKNOWN No new observation in this audit establishes the current operating state for this claim. The dated finding remains available; UNKNOWN is neither closure nor confirmation of a present defect. Scope: one dated research readiness run. An identified system owner must provide a commit-pinned observation for this exact scope before operating closure can be published. [Original finding →]() [Original file SHA-256 →]() ### NB-CF06 · Unread release-authority artifact **Historical observation · 2026-10-01** The release-authority artifact was not read; this review makes no claim about central live release. **Current status · checked 2026-10-10** UNKNOWN No new observation in this audit establishes the current operating state for this claim. The dated finding remains available; UNKNOWN is neither closure nor confirmation of a present defect. Scope: release-authority observation access. An identified system owner must provide a commit-pinned observation for this exact scope before operating closure can be published. [Original finding →]() [Original file SHA-256 →]() ### NB-CF07 · Approval actor and grant time **Historical observation · 2026-10-01** HTTP availability is not business readiness. The approval-axis value is a summary the health endpoint derives from the control plane's approval settings; no order is admitted or refused by reading that summary. The kill switch is reported separately. When the approval was last granted was not observed. **Current status · checked 2026-10-10** UNKNOWN No new observation in this audit establishes the current operating state for this claim. The dated finding remains available; UNKNOWN is neither closure nor confirmation of a present defect. Scope: approval-axis dated observation. An identified system owner must provide a commit-pinned observation for this exact scope before operating closure can be published. [Original finding →]() [Original file SHA-256 →]() ### NB-CF08 · Server-side risk refusal coverage **Historical observation · 2026-09-27** Independent execution engines retain their own permissions, account contexts and gates. On the primary engine the core book remained sealed: identified order attempts on 26 September (KST) were refused by the server-side risk check and the core sell block. **Current status · checked 2026-10-10** UNKNOWN No new observation in this audit establishes the current operating state for this claim. The dated finding remains available; UNKNOWN is neither closure nor confirmation of a present defect. Scope: specific refused execution context. An identified system owner must provide a commit-pinned observation for this exact scope before operating closure can be published. [Original finding →]() [Original file SHA-256 →]() ### NB-CF09 · Autonomous submission conditions **Historical observation · 2026-09-27** The operator approval that the live-execution safety gate requires is granted, so the control plane reports its approval axis as open. The two autonomous-release opt-ins are off, and in the inspected half hour every autonomous submission attempt was skipped by a further gate (opt-in contract not active, admission lease not ready, certified trial not active). The portfolio kill switch is ARMED. **Current status · checked 2026-10-10** UNKNOWN No new observation in this audit establishes the current operating state for this claim. The dated finding remains available; UNKNOWN is neither closure nor confirmation of a present defect. Scope: dated opt-in, lease and trial progression. An identified system owner must provide a commit-pinned observation for this exact scope before operating closure can be published. [Original finding →]() [Original file SHA-256 →]() ### NB-CF10 · Portfolio kill configuration versus trigger **Historical observation · 2026-10-01** ARMED **Current status · checked 2026-10-10** UNKNOWN No new observation in this audit establishes the current operating state for this claim. The dated finding remains available; UNKNOWN is neither closure nor confirmation of a present defect. Scope: reported kill configuration and natural trigger. An identified system owner must provide a commit-pinned observation for this exact scope before operating closure can be published. [Original finding →]() [Original file SHA-256 →]() ### NB-CF11 · Kill/release event identity **Historical observation · 2026-09-30** Merged and installed source contains event identity. The inspected live ledger was empty; no event was triggered for this review. **Current status · checked 2026-10-10** UNKNOWN No new observation in this audit establishes the current operating state for this claim. The dated finding remains available; UNKNOWN is neither closure nor confirmation of a present defect. Scope: trigger/clear event identity and natural execution. An identified system owner must provide a commit-pinned observation for this exact scope before operating closure can be published. [Original finding →]() [Original file SHA-256 →]() ### NB-CF12 · Portfolio target authority consumption **Historical observation · 2026-09-30** Merged and installed source contains target identity. Runtime consumption and authority linkage remain unverified. **Current status · checked 2026-10-10** UNKNOWN No new observation in this audit establishes the current operating state for this claim. The dated finding remains available; UNKNOWN is neither closure nor confirmation of a present defect. Scope: target producer and authority consumer. An identified system owner must provide a commit-pinned observation for this exact scope before operating closure can be published. [Original finding →]() [Original file SHA-256 →]() ### NB-CF13 · Read-only HTTP deployment **Historical observation · 2026-09-30** Merged source tightens signal history and raw linkage boundaries. Deployed HTTP behavior was not independently checked. **Current status · checked 2026-10-10** UNKNOWN No new observation in this audit establishes the current operating state for this claim. The dated finding remains available; UNKNOWN is neither closure nor confirmation of a present defect. Scope: deployed console HTTP behavior. An identified system owner must provide a commit-pinned observation for this exact scope before operating closure can be published. [Original finding →]() [Original file SHA-256 →]() ### NB-CF14 · Disabled inventory issuance **Historical observation · 2026-09-30** Merged implementation remains disabled by default. Runtime manifest issuance and adoption remain unverified. **Current status · checked 2026-10-10** UNKNOWN No new observation in this audit establishes the current operating state for this claim. The dated finding remains available; UNKNOWN is neither closure nor confirmation of a present defect. Scope: manifest issuance and runtime adoption. An identified system owner must provide a commit-pinned observation for this exact scope before operating closure can be published. [Original finding →]() [Original file SHA-256 →]() ### NB-CF15 · Descendant-process cleanup **Historical observation · 2026-10-02** Controlled dependencies exercise the termination branches. Actual descendant-process reaping is not established. **Current status · checked 2026-10-10** UNKNOWN No new observation in this audit establishes the current operating state for this claim. The dated finding remains available; UNKNOWN is neither closure nor confirmation of a present defect. Scope: actual descendant-process reaping. An identified system owner must provide a commit-pinned observation for this exact scope before operating closure can be published. [Original finding →]() [Original file SHA-256 →]() ### NB-CF16 · Absolute OS wall-clock bound **Historical observation · 2026-10-02** This bounds the tested cleanup read. It does not prove an absolute wall-clock bound for every operating-system interaction. **Current status · checked 2026-10-10** UNKNOWN No new observation in this audit establishes the current operating state for this claim. The dated finding remains available; UNKNOWN is neither closure nor confirmation of a present defect. Scope: all operating-system interactions. An identified system owner must provide a commit-pinned observation for this exact scope before operating closure can be published. [Original finding →]() [Original file SHA-256 →]() ### NB-CF17 · Initialization first-failure visibility **Historical observation · 2026-10-04** local\_candidate **Current status · checked 2026-10-10** OPEN\_CONFIRMED The state-file selection omission is still present in the newly inspected source revision. The dated local repair remains preserved. This confirms a source gap only; operating occurrence and installation are UNKNOWN. Scope: stale\_daemon\_detector.run\_once\_sync source before a domain state exists. An identified system owner must provide a commit-pinned observation for this exact scope before operating closure can be published. [Original finding →]() [Original file SHA-256 →]() [Later observation · NB-SOURCE-20261010-INIT →]() ### NB-CF18 · Guardian main compatibility **Historical observation · 2026-10-04** unverified **Current status · checked 2026-10-10** IMPLEMENTED\_AWAITING\_VERIFICATION The dated implementation candidate is still open and unmerged. Named exact-head lint, regression and test checks succeeded at this review. Current installation, natural execution and durable operating effect were not verified. Scope: candidate versus the separately recorded main revision. An identified system owner must provide a commit-pinned observation for this exact scope before operating closure can be published. [Original finding →]() [Original file SHA-256 →]() [Later observation · NB-PR-20261010-5084 →]() ### NB-CF19 · Operating adoption and durable rollback **Historical observation · 2026-10-04** loaded\_consumer\_revision **Current status · checked 2026-10-10** UNKNOWN No new observation in this audit establishes the current operating state for this claim. The dated finding remains available; UNKNOWN is neither closure nor confirmation of a present defect. Scope: installed revision, execution owner, natural completion and rollback. An identified system owner must provide a commit-pinned observation for this exact scope before operating closure can be published. [Original finding →]() [Original file SHA-256 →]() ### NB-CF20 · Research input measurement boundary **Historical observation · 2026-09-30** All absent inputs remain missing; partial invalid inputs become unknown. Completeness covers only listed/discovered files, and older reports acquire no invented unknown count. Freshness, PIT correctness and research quality are not certified. **Current status · checked 2026-10-10** UNKNOWN No new observation in this audit establishes the current operating state for this claim. The dated finding remains available; UNKNOWN is neither closure nor confirmation of a present defect. Scope: input timestamp measurement, not research-quality certification. An identified system owner must provide a commit-pinned observation for this exact scope before operating closure can be published. [Original finding →]() [Original file SHA-256 →]() ### NB-CF21 · UNKNOWN freshness denominator **Historical observation · 2026-09-30** Only evaluable states enter the rate. Unknown, unparsed and unprobed rows remain visible and excluded from both sides; no evaluable observations yield 0/0 with no rate. **Current status · checked 2026-10-10** UNKNOWN No new observation in this audit establishes the current operating state for this claim. The dated finding remains available; UNKNOWN is neither closure nor confirmation of a present defect. Scope: evaluable freshness states and observer coverage. An identified system owner must provide a commit-pinned observation for this exact scope before operating closure can be published. [Original finding →]() [Original file SHA-256 →]() ### NB-CF22 · Native and missing producer identities **Historical observation · 2026-09-30** Direct nonstring native decision references are rejected. Normal opaque IDs, multiple children and content identities remain compatible. Already stringified producer IDs cannot reveal their original type; missing live DCA identities remain unresolved. **Current status · checked 2026-10-10** IMPLEMENTED\_AWAITING\_VERIFICATION The dated implementation candidate is still open and unmerged. Named exact-head lint, regression and test checks succeeded at this review. Current installation, natural execution and durable operating effect were not verified. Scope: producer identity type and live DCA identities. An identified system owner must provide a commit-pinned observation for this exact scope before operating closure can be published. [Original finding →]() [Original file SHA-256 →]() [Later observation · NB-PR-20261010-4923 →]() ### NB-CF23 · Heartbeat health interpretation **Historical observation · 2026-09-30** Existing staleness and classification priorities remain. PID presence and a parsed timestamp do not establish installed code identity or successful application work. **Current status · checked 2026-10-10** IMPLEMENTED\_AWAITING\_VERIFICATION The dated implementation candidate is still open and unmerged. Named exact-head lint, regression and test checks succeeded at this review. Current installation, natural execution and durable operating effect were not verified. Scope: process heartbeat versus completed application work. An identified system owner must provide a commit-pinned observation for this exact scope before operating closure can be published. [Original finding →]() [Original file SHA-256 →]() [Later observation · NB-PR-20261010-4929 →]() ### NB-CF24 · Carried observation provenance **Historical observation · 2026-09-30** Partial unreadable input follows the existing degraded path. Carried values retain degraded status, carry markers and their original observation time across repeated publication; legacy records acquire no fabricated provenance. **Current status · checked 2026-10-10** IMPLEMENTED\_AWAITING\_VERIFICATION The dated implementation candidate is still open and unmerged. Named exact-head lint, regression and test checks succeeded at this review. Current installation, natural execution and durable operating effect were not verified. Scope: carried/degraded status and original observation time. An identified system owner must provide a commit-pinned observation for this exact scope before operating closure can be published. [Original finding →]() [Original file SHA-256 →]() [Later observation · NB-PR-20261010-4916 →]() ### NB-CF25 · Recovery domain completion **Historical observation · 2026-09-30** HEALTHY remains process/log health, not proof of completed domain work or durable restoration. Naive health timestamps, malformed target evidence and legacy absence remain unknown. **Current status · checked 2026-10-10** IMPLEMENTED\_AWAITING\_VERIFICATION The dated implementation candidate is still open and unmerged. Named exact-head lint, regression and test checks succeeded at this review. Current installation, natural execution and durable operating effect were not verified. Scope: process/log health versus durable domain restoration. An identified system owner must provide a commit-pinned observation for this exact scope before operating closure can be published. [Original finding →]() [Original file SHA-256 →]() [Later observation · NB-PR-20261010-4932 →]() ### NB-CF26 · Observer independence and coverage **Historical observation · 2026-10-01** Observer independence and complete coverage were not re-attested. Scheduled-task success alone does not establish either. **Current status · checked 2026-10-10** UNKNOWN No new observation in this audit establishes the current operating state for this claim. The dated finding remains available; UNKNOWN is neither closure nor confirmation of a present defect. Scope: observer independence and full coverage census. An identified system owner must provide a commit-pinned observation for this exact scope before operating closure can be published. [Original finding →]() [Original file SHA-256 →]() ### NB-CF27 · Fleet clean-box recovery **Historical observation · 2026-10-01** NAS mounts and running services do not establish a verified fleet-wide clean-box recovery or a reconciled formal close. **Current status · checked 2026-10-10** UNKNOWN No new observation in this audit establishes the current operating state for this claim. The dated finding remains available; UNKNOWN is neither closure nor confirmation of a present defect. Scope: fleet-wide restore and formal close. An identified system owner must provide a commit-pinned observation for this exact scope before operating closure can be published. [Original finding →]() [Original file SHA-256 →]() ### NB-CF28 · Historical transport failures **Historical observation · 2026-09-30** Name-resolution and host-key verification failures left two observation paths unavailable. Host health and external attestation were not established. **Current status · checked 2026-10-10** UNKNOWN No new observation in this audit establishes the current operating state for this claim. The dated finding remains available; UNKNOWN is neither closure nor confirmation of a present defect. Scope: two dated unavailable observation paths. An identified system owner must provide a commit-pinned observation for this exact scope before operating closure can be published. [Original finding →]() [Original file SHA-256 →]() ### NB-CF29 · Engine-specific market integration boundary **Public statement captured · 2026-10-10** Generic KIS derivative scaffold branches are sealed. Source integrations do not establish every product is currently enabled. **Current status · checked 2026-10-10** UNKNOWN No new observation in this audit establishes the current operating state for this claim. The dated finding remains available; UNKNOWN is neither closure nor confirmation of a present defect. Scope: engine-specific adapter paths and current product enablement. An identified system owner must provide a commit-pinned observation for this exact scope before operating closure can be published. [Original finding →]() ### NB-CF30 · AVA server and inference verification **Public statement captured · 2026-10-10** AVA server implementation, model residency and current distributed inference were not verified by this source review. **Current status · checked 2026-10-10** UNKNOWN No new observation in this audit establishes the current operating state for this claim. The dated finding remains available; UNKNOWN is neither closure nor confirmation of a present defect. Scope: AVA server implementation, residency and distributed inference. An identified system owner must provide a commit-pinned observation for this exact scope before operating closure can be published. [Original finding →]() ### NB-CF31 · Historical CI and publication stage **Historical observation · 2026-09-30** Reviewed Draft \#4916 updated; exact-head CI was queued or running at this review. **Current status · checked 2026-10-10** HISTORICAL\_ONLY The queued/running statement describes 30 September. On 10 October, named exact-head checks for NeuroPublic \#4916, \#4923, \#4929, \#4932 and \#5084 had completed successfully, while all five PRs remained open, Draft and unmerged. The fleet-brain \#1500 latest state was not inspected. Scope: candidate publication and named exact-head CI only. An identified system owner must provide a commit-pinned observation for this exact scope before operating closure can be published. [Original finding →]() [Original file SHA-256 →]() [Later observation · NB-PR-20261010-4916 →]() ### NB-CF32 · Historical stale ledgers **Historical observation · 2026-08-30** One domestic order ledger has no declared freshness ceiling. **Current status · checked 2026-10-10** UNKNOWN No new observation in this audit establishes the current operating state for this claim. The dated finding remains available; UNKNOWN is neither closure nor confirmation of a present defect. Scope: dated domestic ledger and rotation freshness. An identified system owner must provide a commit-pinned observation for this exact scope before operating closure can be published. [Original finding →]() [Original file SHA-256 →]() ### NB-CF33 · Replay and effect remeasurement **Historical observation · 2026-10-01** Authority-surface attribution, replay equivalence and remediation-effect totals were not re-measured. August figures remain historical evidence. **Current status · checked 2026-10-10** UNKNOWN No new observation in this audit establishes the current operating state for this claim. The dated finding remains available; UNKNOWN is neither closure nor confirmation of a present defect. Scope: authority attribution, replay and effect totals. An identified system owner must provide a commit-pinned observation for this exact scope before operating closure can be published. [Original finding →]() [Original file SHA-256 →]() ### NB-CF34 · External reproduction and attestation **Historical observation · 2026-10-02** The local result is tied to private source and test bytes. Public JSON and SHA-256 identify this disclosure; they do not independently reproduce or attest to the private execution. The website claim checks can be run from the website repository. **Current status · checked 2026-10-10** UNKNOWN No new observation in this audit establishes the current operating state for this claim. The dated finding remains available; UNKNOWN is neither closure nor confirmation of a present defect. Scope: independent reproduction of private execution. An identified system owner must provide a commit-pinned observation for this exact scope before operating closure can be published. [Original finding →]() [Original file SHA-256 →]() Original finding → implementation evidence → scoped re-verification → current status. The source finding confirms a code path at a pinned revision; it does not establish an operating incident. The 5 candidate PR observations establish named CI and publication states. They do not establish deployment, natural consumer completion, rollback or external attestation. Earlier scoped implementation ## The test observer must preserve uncertainty. The earlier local repair strengthens failure cleanup and output interpretation in the test probe. Unavailable captured output remains unverified, even when the process reports a successful exit. **Local test population** 18 / 18 0 failed · 0 errors · 0 skipped **Bad implementations rejected** 6 Controls check that verification can fail. **Review level** Separate internal review External attestation remains unverified. ### Cleanup failure stays unresolved **Before** An unsuccessful Windows tree-termination command could return without attempting the direct-child fallback. **After** A nonzero tree-termination result attempts the direct-child fallback. Cleanup failure remains an unknown outcome. Controlled dependencies exercise the termination branches. Actual descendant-process reaping is not established. ### Timeout cleanup has a finite observation window **Before** An implicit process context exit or an unbounded output read could keep the probe waiting after the execution deadline. **After** The probe retains its execution deadline and limits the post-failure output read to five seconds. Unresolved cleanup returns a timeout outcome. This bounds the tested cleanup read. It does not prove an absolute wall-clock bound for every operating-system interaction. ### Unreadable output cannot become a pass **Before** Locale-dependent text capture could lose UTF-8 output or interrupt attribution; unavailable output could also fail attribution. **After** Binary capture is decoded strictly as UTF-8. Unavailable captured output or a UTF-8 decoding failure produces an explicit unverified outcome even with a zero exit code. One isolated real child exercises UTF-8 output across a forced legacy text-decoding boundary. The other cleanup counterexamples use controlled process dependencies. This verifies capture availability and decoding, not output completeness; valid empty output retains the process exit-code result. [Dated result and source pins →]() [SHA-256 →]() [Earlier improvements →]() **Reproduction and access limits** The local result is tied to private source and test bytes. Public JSON and SHA-256 identify this disclosure; they do not independently reproduce or attest to the private execution. The website claim checks can be run from the website repository. mxroach/neuropublic · kill\_tree / run\_pytest\_once Commit d6e06a514f5bf07ad7d1d3205975c87a9d611cd9 Source SHA-256 75f6296470174813368f0c95b0bee13b2d15eec4f7c474a8de9fff0bfd15cf91 Earlier disclosures retain their own dates, populations and publication stages. This local test result does not refresh fleet observations or resolve the held full-regression candidate. Acceptance criteria ## What would justify a stronger claim. ### Operating effect Not verified The installed revision, a natural-run observation from the affected component, declared coverage and a comparison window. ### End-to-end decision evidence Not verified Research, authorization, execution and accounting records sharing consistent identifiers; missing records retained in the denominators. ### External reproducibility Not verified A sanitized runnable reproduction bundle and an observer able to check the original evidence independently. These criteria were not verified in the 2 October 2026 at 20:45 KST record. The reconciliation above distinguishes that finding from later scoped observations; it is not a current runtime census. This page covers technical claims. Internal review and public hashes do not constitute external attestation. Neurobrick · systems, authority and evidence Last updated · 10 October 2026 [Public scope →]() [Canonical page]() > 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. [neurobrick]() [principles]() [architecture]() [capabilities]() [authority]() [observation]() [evidence]() [engineering]() [verification]() [scope]() Public scope and technical limits # A precise claim. A visible boundary. Public material explains architecture, authority and specific engineering results. Each result is bounded by its source, population and observation window. Public scope ## Architecture, authority and technical evidence. Public material covers system architecture, authority boundaries and scoped technical evidence. Returns, balances and proprietary strategy parameters remain private. [Read the principles →]() Dated evidence boundary ## Local behavior, installed identity and operating effect are separate. The archived local repair records did not establish installed consumer revisions, natural completion or durable rollback with fresh output. The 1 October 2026 inspection did not establish the unified research-to-authority-to-execution evidence path across every engine. Those findings are historical observations; this publication does not substitute them for a new runtime census. Internal review and public checksums do not constitute external attestation. Archived operating observations retain their original coverage and are not refreshed by a later test result. [Read the fixed historical records →]() [Historical findings and current reconciliation →]() 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. Technical acceptance ## Evidence that can support a stronger system claim. ### Execution identity Identify the installed revision and the component that actually consumes it. Bind a natural-run receipt to that revision and state its coverage. ### Boundary enforcement Exercise the real permission-consuming path with both allowed and refused inputs. A declared policy or a health summary alone does not establish enforcement. ### Recovery behavior Observe the affected component after recovery, including fresh domain output. Process presence and a successful restart command are separate observations. ### Reproduction and review Keep the input, source revision, test population and original failure. Distinguish an internal review from an independently runnable public reproduction. These conditions are evidence requirements, not claims that they have already been met. Published local repairs retain their own adoption and reproduction limits. Neurobrick · systems, authority and evidence Last updated · 10 October 2026 [Public scope →]() [Canonical page]() > 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. [neurobrick]() [principles]() [architecture]() [capabilities]() [authority]() [observation]() [evidence]() [engineering]() [verification]() [scope]() Architectural principles · separate from runtime claims # Prediction is not the hard problem. Authority is. Models are fallible and regimes move. The durable problem is controlling what a system may do when its inference is wrong. Neurobrick treats prediction as input and authority as an explicit, auditable state. 01 ## Inference is advisory A model, rule or researcher may produce a proposal. Being right does not create permission. 02 ## Authority is explicit state Live-capital access must be represented, bounded, attributable and readable by the gate that consumes it. 03 ## Safe direction is asymmetric Automation may tighten a guardrail or reduce risk inside an envelope. Opening or expanding authority requires a different class of proof. 04 ## Evidence is scoped A passing receipt supports only its system, surface, instrument and observation window. The self-approval door ## A boundary under observation, not an absolute slogan. The intended boundary is human authority for opening or expanding live-capital access, with bounded machine authority in the safe direction. The dated system review states which observed permissions support that distinction and where actor attribution, surface coverage or effective state remains open. Scope This is a governance architecture, not a track record. Returns, balances, strategy parameters and investment performance are outside the public surface. The question here is whether authority is bounded and whether the evidence supports that claim. [system architecture →]() [authority boundary →]() Neurobrick · systems, authority and evidence Last updated · 10 October 2026 [Public scope →]() [Canonical page]()