Engineer Mohanad Osama Zahran / Engineering approach

The engineering approach of Mohanad Osama Zahran

Role-specific software cells, scoped tools and inspectable memory in the ZEISMO AI Engine research programme.

Author profile ↗

Engineer Mohanad Osama Zahran and ZEISMO AI Engine

Mohanad Osama Zahran identifies ZEISMO AI Engine as his model-training and adaptation work. This page explains the engineering concepts documented in the lab’s JARVIS and System Brain materials. It connects that stated background to inspectable project evidence without assigning unrecorded model counts or performance results.

Define the role before selecting the action

The proposed role contract describes what an agent is responsible for, which tools it may use and which decisions require approval. For an illustrative purchasing task, comparing a quote is different from committing a payment. Keeping those actions separate makes the authority boundary visible and provides a place to enforce it.

Treat memory as evidence with a history

The design calls for memory to retain its source, observation time, relevant role and review state. A stored instruction may be outdated; a remembered outcome may apply only to one context. Retrieval therefore needs to preserve qualifications. Writing a new memory or appending a skill is not, by itself, evidence that a model has learned or improved.

Separate proposal, permission and execution

A useful agent can propose a course of action before it has authority to perform it. The coordination design places an evidence and permission check between recommendation and execution. Missing information can lead to a request for help; a prohibited action should stop. This is an architectural explanation, not a claim that every proposed control is deployed.

What the archived prototype tests establish

The archived prototype summary records seven software tests, 32 assertions and no failures or errors in that run. It includes checks around access, the fifteen-cell representation, a cell update and an honest failure when the AI key is absent. These checks support narrow software behaviours. They do not measure decision accuracy against human specialists or prove all proposed capabilities.

Measure changes before expanding autonomy

A change to a role, memory policy or coordinating rule should be evaluated against a fixed comparison and relevant failure cases. The follow-on decision study provides a way to examine act, ask and stop outcomes. Reporting both useful completion and unsafe decisions is more informative than counting successful demonstrations alone.

Sources and further reading

ZEISMO research practices

Evidence you can inspect.

Follow each marker to the method, record or policy behind it.

ZEISMO practice markers. Verification scope is recorded with each publication.