The model proposes, it does not manage the repository
The architecture assumes the model prepares plans and proposed changes without direct write access to the target repository.
Zerium by Selemitor · Project in development
AI proposes. Zerium controls execution.
I am building an AI orchestrator whose goal is to turn requirements into verified software changes. Zerium is designed to separate the model’s work from the permission to execute changes: the model prepares a proposal, and the orchestrator is responsible for checking it, applying it under control and recording how the process went.
In active development
A public version of the product is not available yet.
- Stage
- active development of the architecture and verification mechanisms
- Model integration
- Claude API — planned
- Availability
- no public version yet
The problem
From generated code to controlled execution.
A proposal generated by AI should not automatically become a change in a project. It needs a process that defines what was proposed, which checks were run and on what basis the change was accepted. I am building Zerium around this separation of responsibilities.
The model handles reasoning and prepares proposals. The orchestrator manages permissions, verification and execution.
Who it is for
I am designing Zerium for software builders and teams who want to work with AI agents without handing them uncontrolled access to the target repository.
Architecture
How it is designed to work.
The model is responsible only for the proposal. Whether a change is applied is decided by checks and the orchestrator’s rules.
-
01
Task
A requirement together with its acceptance criteria.
-
02
AI proposal
An AI model prepares a plan and a proposed change, with no write access to the repository.
-
03
Persisted and hash-linked
The proposal is recorded and linked to the task.
-
04
Isolated verification
Defined checks in an isolated environment.
-
05
Controlled application
Changes reach the project only once the conditions are met.
Diagram
How a single requirement moves through Zerium.
Every task follows the same path. The next step is decided by the result of the checks, not by what the model claims.
InputRequirementgoal and acceptance criteria
PlanTask plansplit into small, bounded tasks
Task Asame path
Task Bexample below
Task Csame path
01AI proposalan AI model prepares a proposed change
02Persisted and hash-linkedintegrity check of the proposal
03Isolated verificationdefined checks in a staging environment
Are the required conditions met?
NoBounded fixreturns to the proposal stage
YesControlled applicationthe orchestrator applies changes
Needs a decisionHuman decisionthe operator settles the case
Run recordkept for later review, then the next task in the plan
A conceptual diagram of the designed flow. It does not show an interface or results produced by the system.
Architecture principles
Verification before application
Proposed changes are meant to pass checks in an isolated staging environment. Only the verification result and the orchestrator’s rules decide whether execution continues.
An artifact-based trail
The designed mechanisms include persisting proposals, linking them with hashes and recording check results, so the course of a specific run can be reviewed.
This describes the design principles of a system in development. The implemented scope and available features will be updated as the work progresses.
Example
An example of planned use.
The scenario illustrates the intended way of use, not a demonstration of a publicly available feature.
Task
Add input validation and tests to an existing module.
The model prepares a proposed change. Zerium persists the proposed artifacts, routes them to an isolated environment and runs the defined checks. If the required conditions are met, the orchestrator can apply the changes to the target project. The course of the process stays recorded for later review.
Current stage
A project in active development.
I am working on the orchestrator’s architecture, on controlling how changes are executed and on the mechanisms that verify them. Implementation details and working materials remain private for now.
This page presents the direction and design principles of the system. I will publish availability information as the work progresses.
A public version of the product is not available yet.
Claude in the project
While developing Zerium, I use Claude through a paid subscription, for architecture design and programming work.
A direct integration of the Claude API with the orchestrator is planned. The model is meant to prepare proposed changes, while Zerium controls their verification and execution.
Progress map
What I have built and what lies ahead.
The stages of work on Zerium in plain language, without implementation details or test results. I update the map as the work progresses.
Completing individual elements does not mean the whole system is ready. The map separates design work, implementation and the integration of the full process.
Last updated: October 2026
-
Trading automation
The project started as a tool for controlled automation of trading decisions. Zerium grew out of it.
-
Orchestrator baseline
A cleaned-up, reviewed starting point from which I am developing the orchestrator’s architecture.
-
Development plan
A written plan in which every stage has a defined goal and completion criteria. Correctness and recovery from failures come first, convenience and scale later.
-
Control foundations
The layer the rest of the system is built on:
- durable state and a history that can be replayed step by step
- backups, restore and migration rehearsals on copies of the data
- exact assignment of a model to a task, with no silent switch to another model
- resuming after a failure without calling the model again for the same step
- an isolated check environment, among other things without network access or secrets
- verification against a fixed list of checks, not the model’s claims
- changes applied only after the required checks and approvals
-
The full task cycle
I am connecting the foundations into one cycle: preparing a task for the model, isolated execution, automated verification, an independent review of the result, fixes with a retry limit and human decisions. The first work package of this stage is closed.
-
Resilience of the whole cycle
Checking behaviour after restarts and failures across the whole cycle: no false check results, no blind retries and no change applied twice.
-
Operator panel
A view of projects, history, decisions and costs based on recorded data. Where something cannot be measured, the panel is meant to say so plainly.
-
From idea to finished product
In the long term, Zerium is meant to take a project from requirements to product, with control at every stage.
“Next” items show the direction from the development plan, without dates. Their order and scope may change.
Questions
Frequently asked questions about Zerium.
Short answers about what the project is, what it is not and what stage it is at.
Can I use Zerium yet?
Not yet. Zerium is in active development and there is no public version or demo. I will publish availability information on this page. If you are interested in the project, write to [email protected].
How is Zerium different from an AI coding assistant?
I am designing Zerium around separating the model’s proposal from the permission to execute changes. Its job is to manage the process: persisting the proposal, running defined checks, applying or stopping the changes and recording how it went.
Can the model decide on its own that a task is finished?
No. A model saying that something is done or that the tests passed grants no permissions. The outcome is decided by checks the orchestrator runs from a fixed list and by the required approvals. The model also cannot skip checks or raise the retry limit on its own.
What happens when a check fails?
The task goes back for a bounded fix with a retry limit. Every attempt is recorded separately, so the history of earlier attempts is kept. When the limit runs out or the case needs judgement, a person makes the decision.
What are the hashes for?
For integrity checks and linking data: they make it possible to verify that a recorded proposal and its check results have not been changed and which task they belong to. A hash is not proof that the code is correct or secure.
What if work stops halfway through?
State and history are meant to be stored durably, so that after a failure or restart work can resume without losing history. If it is unclear whether a step was executed, the system is meant to resolve that instead of blindly calling the model again.
Which AI models does Zerium use?
While developing the project, I use Claude through a paid subscription. A direct integration of the Claude API with the orchestrator is planned. The architecture assumes that every model call will be assigned to a specific task and role, and that if the required model is unavailable, the task will stop instead of silently switching to another model.
Is Zerium a trading bot?
The project grew out of trading automation. The target product, however, is the orchestrator itself: a system that controls work done by AI models. I am developing Zerium for many kinds of software projects, not only trading use cases.
Who is building Zerium?
I am building it on my own, under the Selemitor brand. In my work I use AI tools, including Claude through a paid subscription.
Contact
Zerium by Selemitor
An independently developed technology project under the Selemitor brand.
Interested in using Zerium in a specific software development process? Write about the problem you want to solve and which requirements for controlling execution matter most to you.
Po polsku
Orkiestrator AI w rozwoju.
Orkiestrator AI, który oddziela propozycje modelu od kontrolowanego wykonania. Pełny opis jest dostępny po polsku.