Inside System Brain

A decision needs more than an answer

An AI assistant can suggest an action in fluent language. A working department must also establish who may act, which evidence supports the action, how to handle uncertainty and what happens if execution fails. System Brain is our research architecture for connecting those responsibilities.

JARVIS is the proposed English-speaking interface. System Brain coordinates specialist roles behind that interface. The central design principle is to separate a proposed decision from permission to execute it. A persuasive answer alone does not grant authority.

This article explains the prototype evidence and architecture documented in our JARVIS & System Brain report, edition 1.3. It is an engineering explanation, not the final report of our follow-on decision study.

What is a role cell?

A cell represents a software responsibility. A useful role contract defines the task, permitted information, available tools, approval boundaries and expected output. Skills describe how the role approaches work; they do not expand its permissions. A finance role, for example, may analyse an invoice without being allowed to pay it.

The archived prototype summary records fifteen cells. Its tests include checking that those cells exist, that the page renders, and that training a cell sets its identity and appends a skill. These are concrete software behaviours. They do not establish that a cell has learned a general capability or can independently perform every task in a department.

What the archived tests establish

The report’s retained prototype summary records seven tests, 32 assertions, zero failures and zero errors. Named tests cover guest login routing, administrator access, a data endpoint, the fifteen-cell display, cell identity and skill updates, and an honest failure when an AI key is absent. These results describe the archived test execution, not a new test of today’s production system.

The distinction matters: a correct access check is evidence about access control. A successful skill update is evidence about stored configuration. Neither is a substitute for evaluating the quality of the decisions produced by a model.

Decide, ask for help, or stop

In the proposed workflow, a specialist first produces a recommendation. A separate authority check considers whether the task is permitted, whether the evidence is sufficient and whether an approval is required. Execution becomes possible only after those conditions are satisfied.

Consider an illustrative procurement request. A purchasing cell compares a quote with the approved budget. If the necessary evidence and permissions are present, a bounded action may proceed. If an approver is missing, the system asks for help. If the requested action is prohibited, it stops. This example explains the design; it is not a reported deployment outcome.

Memory must preserve its source

A useful memory contains more than a conclusion. It should retain the source, observation time, applicable role, review state and outcome. Otherwise an outdated assumption can appear indistinguishable from current evidence.

We distinguish stored experience from demonstrated learning. Saving a successful procedure makes it available for retrieval. Showing improvement requires a later evaluation on tasks that were not used to construct that procedure. Proposed changes to a role’s working instructions therefore need a measured promotion process, with a way to withdraw a change that introduces regressions.

Coordination is not a vote count

More agents can generate more opinions without producing a better decision. The proposed coordinator needs to compare evidence quality, expose disagreements and detect shared unsupported assumptions. A hundred identical recommendations based on one incorrect source do not create a hundred independent confirmations.

Our specialist-coordination ambition must be evaluated through defined tasks, comparable resources and explicit measures. Decision accuracy, unsafe actions, completion time, cost and escalation quality are separate outcomes. The existing prototype evidence does not establish a general multiplier over human intelligence.

How we will test the decision boundary

The next study, When Should an AI Employee Decide, Ask for Help, or Stop?, defines 48 synthetic scenarios: 12 development cases and 36 evaluation cases. Its design compares a rules baseline, a single-model condition and a System Brain condition.

The recorded rules-baseline run contains 108 responses across the 36 evaluation cases. The model comparison remains pending. The final study must report all conditions, identify the model versions and explain disagreement with the evaluation rubric. The public dataset-method article introduces the task design.

Evidence and authorship

Research direction and author: Mohanad Osama Zahran. This article was prepared with AI assistance from the lab’s existing report and recorded protocol. Its architectural examples are explanatory; its software-test counts refer to the archived prototype summary.

1. JARVIS & System Brain, edition 1.3: report, methods and supporting artifacts.
2. Read the 72-page technical report.
3. Building a Decision Dataset for AI Employees: follow-on study design.
4. Research integrity and versioning: the lab’s publication practices.

Suggested citation: Zahran, M. O. (2026). Inside System Brain. ZEISMO Research & Lab. Engineering article, version 1.0. Published 4 October 2026.