UMAY OS
A conceptual composition of navy modules and teal glass layers representing local intelligence and lasting knowledge.

Models change.Experience endures.Decisions remain human.

An operating layer aiming to bring local open-weight models, specialist agents and lasting knowledge together under human oversight.

An agent operating layer on Linux. Not a new kernel or distribution.

More than an answer.A way of working.

Read → analyze → advise. Humans decide.

  1. Work on your own infrastructure.

    Local operation starts in a workspace where you define tool and data boundaries. On-prem and rented self-host are different placements.

  2. Let experience outlive the model.

    Sources, reviews and canonical records endure. Replacing a model should not erase a verified history.

  3. Teachers produce. Workers execute.

    Large models produce candidates for code, skills and tests. Local models handle daily work; candidates gain no authority before evaluation.

  4. Ground explanations in evidence.

    A result comes with its source and calculation method. Competing hypotheses, gaps and uncertainty belong in the answer too.

  5. Keep authority human.

    Models do not grant permission. Software enforces policy and acceptance; humans make the final decision and promote versions.

  6. Make skills reusable.

    A skill is a method with defined inputs, outputs, versions and tests. It is more than a single successful conversation.

  7. Keep learning controlled.

    Experience starts as a candidate. Human review and independent evaluation precede versioning; production models never change silently.

  8. Expand when it serves a purpose.

    Each new specialist must address a measured need. Agent count alone is not a measure of success.

A good answer is a beginning.Verified knowledge is a traceable record.

One core. A family of specialists.

UMAY OS Core will be created through a controlled fork of AOS. Its first specialist, UMAY Scientist, will preserve the aserdargun/ai-scientist foundation. This diagram describes the target architecture, not completed runtime acceptance.

Operation

On-prem · local operation target

Human · purpose and permission

UMAY OS Core

S1 · fast choice among permitted options

S2 · planning, explanation and recovery

Application Pack · SWAPP

Core owns GUI execution · one execution owner

UMAY Scientist · first specialist

Scientific investigation · separate research S1/S2 profiles

Local knowledge

RAG · versioned skills · training data

A model is a compute resource. An agent is an execution role with defined boundaries.

Core is the single GUI owner through typed execution, policy and input ownership. Scientist conducts scientific investigation on permitted data. Model/deployment/adapter registries, knowledge/skills and GPU management will build on AOS.

Teachers propose. Models do not grant authority.

  1. 01Large model · provider / self-host
  2. 02Code, skill, test and training candidate
  3. 03Harness · safety and evaluation
  4. 04Human review and promotion
  5. 05Versioned registry · rollback

There is no direct authority path from the teacher line to the live GUI. Sensitive inputs are never sent automatically to a provider. Daily local operation is intended to continue when teacher access is unavailable.

Contracts before integration. Evidence before promotion.

  1. 01Pinned sources · controlled fork
  2. 02Core–Scientist contract
  3. 03Local synthetic GUI acceptance
  4. 04Independent evaluation
  5. 05Human promotion · rollback

Model and agent replacement requires capabilities, versioned contracts and independent evaluation. The Linux profile is an installation target, not a verified UMAY distribution. SWAPP will be accepted using local frontend/backend and synthetic or permitted examples; actual institutional acceptance comes later.

Two separate architectural workspaces for candidate production and reviewed modules. Conceptual composition.
Two workspaces, two roles. Review stands between production and use. Conceptual artwork.

First specialist: Scientist.

Between questions, evidence and calculation.

The original AI-Scientist’s Director, local model provider, sandbox, computation/evaluation and experiment ledger will be retained. Scientist research S1/S2 profiles differ from the Core decision protocol.

Conceptual example · synthetic data

1 / 6 · Question

How did past vibration change?

Consider six days of history for an anonymous rotating asset. The aim is to compare possible explanations, not to intervene in a control system.

2 / 6 · Data

Permitted data. Explicit provenance.

Six entirely synthetic samples. Time: 1–6 September 2026, daily at 12:00 UTC. Unit: mm/s RMS. These values do not come from a real facility or device.

3 / 6 · Calculation

Deterministic calculation. Visible method.

vibration-window-mean v1 compares arithmetic means of the first and last three samples. Percentage change = (last mean / first mean − 1) × 100. The same data produces the same result.

4 / 6 · Hypotheses

One finding. Several explanations.

Changes in load or speed, measurement conditions, or mechanical condition could explain the difference. Vibration growth alone cannot distinguish them or diagnose a fault.

5 / 6 · Answer

A sourced Advisory Packet.

The packet carries the question, source version, method, supporting and contradicting evidence, alternatives and missing data. Uncertainty remains visible.

6 / 6 · Review

Lasting Investigation. Human decision.

A human reviews the evidence and identifies the next data request. An asset-linked Investigation is intended to retain sources and review history. This page runs no record service.

Vibration · mm/s RMS
Vibration · mm/s RMSConceptual example · synthetic data. 2026-09-01T12:00:00Z — 2026-09-06T12:00:00Z. 2, 2.2, 2.1, 2.5, 3.2, 3.4 mm/s RMS.0123452.001 Sep2.202 Sep2.103 Sep2.504 Sep3.205 Sep3.406 Sep

2026 · 12:00 UTC · vibration-window-mean v1

Deterministic calculation. Visible method.

First three days
2.10 mm/s
Last three days
3.03 mm/s
Change
+44.4%

This change is not a fault diagnosis.

Source and method

synthetic-vibration-v1.csv

vibration-window-mean v1
2026-09-01 → 2026-09-06 · UTC

Alternative explanation

Load or measurement conditions may have changed. Mechanical condition cannot yet be distinguished.

Missing evidence

Speed, load, sensor calibration and maintenance records are absent.

Chart data table
Time (UTC)Vibration (mm/s RMS)
2026-09-01T12:00:00Z2.0
2026-09-02T12:00:00Z2.2
2026-09-03T12:00:00Z2.1
2026-09-04T12:00:00Z2.5
2026-09-05T12:00:00Z3.2
2026-09-06T12:00:00Z3.4

Read and advise. Writing to control systems, setpoints, start/stop and alarm-state changes are out of scope.

Models change.Knowledge keeps its history.

What endures is more than an answer: its source, review and version.

Transparent archive layers representing knowledge provenance and review history. Conceptual composition.

RAG

Knowledge tied to sources.

Documents are retrieved with their provenance, access boundary and version. Producing an answer does not turn it into verified knowledge.

Skill

A versioned, testable method.

Inputs, outputs, authority boundaries and tests are recorded together. The method can be reused under control in a new task.

Training data

Evaluated learning examples.

Fine-tuning is considered only for supported models and a measured behavioral need. RAG and skill records are not automatically training data.

  1. Candidate
  2. Human review
  3. Verified record
  4. Evaluation
  5. Version / rollback

Canonical records and review history endure. Embeddings, tokenizer outputs and LoRA adapters are not directly portable to every model.

Where do we stand today?

02

UMAY architecture decision

  • AOS-based Core and Scientist as the first specialist.
  • Separation of local operation and the teacher line.
  • Sourced Advisory Packet, lasting Investigation and human promotion.
03

Integration and acceptance pending

  • Core–Scientist integration.
  • Broker patch compatibility with the baseline.
  • SWAPP local GUI acceptance; institutional acceptance later.
  • Independent evaluation and continuous learning.
  1. 01

    Integration

    Typed contracts, policy and execution ownership.

  2. 02

    Local GUI acceptance

    Local setup with synthetic or permitted examples.

  3. 03

    Independent evaluation

    Repeatable acceptance evidence separate from source inventories.

  4. 04

    Next specialists

    Expansion based on measured need and value.

A source inventory is not a UMAY test result. Public access does not grant a license or commercial usage rights. A UMAY OS project license has not been selected.

A conceptual composition of navy modules and teal glass layers representing local intelligence and lasting knowledge.

Intelligence can change.Responsibility endures.

We are building the lasting foundation for working with models, beyond the next model itself.

Explore development on GitHub