Mahmoud Mohsen
Mahmoud Mohsen Business systems

Selected work 02

JARVIS OS

Designed an AI-driven operating system that executes, verifies, and orchestrates desktop workflows through architectural verification instead of assumption-based automation.

Personal
  • Python
  • Playwright
  • Gemini
  • Claude
  • Windows Automation
  • Custom Verification Framework
Sector
Personal Productivity & AI Infrastructure
Size
Personal research and development platform
My role
Designed and Built
Period
2025–Present

Context

Existing AI assistants could generate answers but could not reliably operate a real computer. Traditional automation frameworks focused on executing commands without independently verifying whether those actions actually succeeded. The objective was to build a trustworthy operating layer capable of interacting with a real desktop while treating execution verification as a core architectural requirement.

Business problem

Modern AI assistants can answer questions but cannot reliably operate a computer. Most automation systems assume success instead of verifying it, making them unsuitable for operational workflows where execution integrity matters.

Constraints

Had to operate on a real Windows desktop rather than a simulated environment. Browser, file system, and desktop actions required independent verification. False success reports were unacceptable. The system had to remain local-first. Every executable action needed an associated verification mechanism. Automation had to prioritize correctness over speed.

The decision

Instead of building another conversational assistant, I designed JARVIS as an operating layer where every mutation is structurally coupled with an independent verifier. The system never reports success unless the resulting system state confirms it.

Solution

Built an AI operating system capable of orchestrating desktop automation, browser control, file management, and system operations while enforcing architectural verification before confirming successful execution.

Highlights

  • AI Operating System
  • Desktop orchestration
  • Browser automation
  • Verify-before-success architecture
  • Structural verification contracts
  • Custom action registry

Decision spread

What exists

Desktop action orchestration · Browser automation · File system operations · Action registry · Structural verification framework · Multi-engine reasoning · Local-first execution · Diagnostic execution pipeline

Deliberately not built

Autonomous self-modifying behavior · Blind execution · Assumption-based success reporting · Cloud-dependent execution · Fully autonomous decision making without user approval

The tradeoff accepted

Every action incurs additional verification overhead before completion. The system sacrifices execution speed in exchange for deterministic and trustworthy results.

Evidence

Verified execution pipeline demonstrating how desktop actions are executed, independently verified, and only then reported as successful.

JARVIS OS — execution and verification architecture A user request enters an action registry, which dispatches to the execution engine. The engine's effect is not reported directly: system state is validated independently, an independent verifier reads that state, and only a confirmed result is reported as success. Execution and verification are separate paths. Action execution Structural verification — independent confirms — or the action does not report success 01 User request 02 Action registry 03 Execution engine 04 Independent verifier 05 System state validation 06 Verified result reported only after state confirms
JARVIS execution architecture illustrating the separation between action execution and structural verification.
Runtime log at startup: the action registry reports 18 registered actions, then names the five mutations that cannot self-verify and why. Local paths and addresses are redacted.
Runtime log at startup: the action registry reports 18 registered actions, then names the five mutations that cannot self-verify and why. Local paths and addresses are redacted.
  1. 01 User request
  2. 02 Action registry
  3. 03 Execution engine
  4. 04 Independent verifier
  5. 05 System state validation
  6. 06 Verified result

Technical

Creating an operating layer that guarantees execution integrity through structural verification rather than relying on optimistic automation assumptions.