To keep AI under human control

Vision

Vision

YonerAI's vision is to make AI powerful without making it uncontrollable.

AI is becoming part of operating systems, development environments, businesses, education, creative work, infrastructure, and personal workflows. It will not stay inside one chat box. It will not be served by one model, or used through one interface. People will use AI from browsers, desktops, mobile devices, command lines, APIs, developer tools, and interfaces that do not exist yet.

That future requires more than intelligence. It requires structure.

Without structure, powerful AI becomes a black box. Without permissions, it cannot be safely connected to real systems. Without records, nobody can tell what happened. Without approval, automation crosses boundaries too quickly. Without deployment flexibility, users end up bound to one provider, one cloud, one screen.

The future YonerAI is built for is one where AI adapts to the user's environment — not one where every user is forced into the same environment. Cloud AI should be easy. Local AI should be practical. Self-hosting should be a realistic choice. Hybrid should be possible. Nobody should have to choose between capability and control.

And YonerAI is built from Japan, Japanese-first. In the AI world, languages other than English are often second-class citizens. YonerAI's CLI can be operated in Japanese, inspected in Japanese, governed in Japanese — an experience designed in Japanese, not translated into it. The principle of the same experience applies not only to environments, but to languages.

Principles

Principles

These principles are not decoration. Each one corresponds to a mechanism that already runs. So that this page can be told apart from documents that only state ideals, each principle is followed by its current, working form in YonerAI.

01Governance before intelligence

More capable AI is not automatically better AI. A system that can write code, operate tools, access files, and change environments must be governed before it is made more powerful.

Boundaries come before automation. Permissions come before tool access. Approval comes before execution. Logging comes before autonomy. Review comes before self-improvement. A capability that cannot be audited does not belong in the core.

TODAYYonerAI's installer verifies the SHA-256 hash of what it downloads before running it; on mismatch, it refuses to run. Fail-closed — closing on failure instead of opening — is the default.

02Human approval at meaningful transitions

Not every action requires the same weight of approval. Drafting is different from sending. Reading a file is different from modifying it. Suggesting code is different from deploying it.

When risk is low, AI should help fast. But when an action changes files, sends data outward, touches infrastructure, or changes what is public — that transition is governed, and visible. Human approval is not a feature bolted on afterward. It is part of the operating layer.

TODAYThe CLI ships graduated approval profiles, from read-only to ask-before-risky. Users set their own risk tolerance themselves.

03Least authority by default

AI should not start with unlimited authority. Reading does not imply writing. Drafting does not imply publishing. Testing does not imply deploying. Suggesting does not imply executing.

Permissions are separated by action, environment, tool, and risk level. The goal is not to make AI weak. It is to make AI powerful inside clear boundaries.

TODAYThe agent's default mode is plan-and-read only. Execution authority activates only when explicitly switched on.

04Traceability by default

AI that affects real work must be traceable. When AI reads information, calls a tool, changes a file, or recommends an action, a record of what happened exists. Traceability is what makes trust possible. A system that cannot be inspected cannot be trusted with important work.

But recording is not surveillance. What is kept is what was done — not what you wrote. Actions stay traceable; content stays unread. Holding both at once is a design requirement, not a contradiction.

TODAYEvery run is recorded in a run ledger, while file contents, secrets, and tokens are excluded or hashed at the moment of recording, so they never reach the logs.

05The same experience, in every environment

AI should not be locked into one place. Whether it runs in the cloud, on a model inside your own PC, or on a private server, it should run under the same contract, the same boundaries, the same experience.

The screen can change. So can the device, the model, the provider, the environment. But the structure of governance stays coherent. The ability to switch, at any time, is itself power on the user's side.

TODAYLocal LLMs — Ollama or any OpenAI-compatible server — connect under the same execution contract as cloud models, starting loopback-only. Local safety boundaries are taken as seriously as cloud ones.

06What runs locally is free locally

Most services charge not for the work their servers do, but for the structure itself. Yet document processing, coding assistance, transcription — much of it can run on the user's own machine.

YonerAI places as few restrictions as possible on work that completes on your PC. If it runs locally, it is free to use locally. You pay for the cloud when you need the cloud — sync, teams, official infrastructure, guarantees. We are not selling the right to run AI. We are returning the freedom to use AI to the user's side.

07Self-evolution stays inside governance

AI systems should improve over time — learning from usage, finding problems, detecting gaps, drafting improvements. But ungoverned self-evolution is dangerous. A system that changes itself without review becomes unpredictable; a system that ships changes without approval causes real damage.

YonerAI's self-evolution loop — observe, analyze, propose, score value and risk, request approval, assist implementation, assist release — runs entirely inside approval and audit. A proposal stops at being a proposal. Decision stays with people.

TODAYThe implemented self-evolution loop is proposal-only. Proposals enter an approval queue carrying a scorecard of impact, risk, and implementation cost — and merging or deploying without approval is impossible at the code level.

08No exaggeration

Say what works and what does not, separately. Never call something finished that is not.

This is not modesty; it is infrastructure. Trust is a property of the system, and exaggeration is a vulnerability. Sounding small and being true beats sounding big and being false.

TODAYThe repository carries an explicit do-not-claim document, and every release note lists what is not included with the same weight as what is. The status section on this page is part of the same discipline.

Goals

Goals

YonerAI's goals are concrete. The point is not to write a manifesto and stop. The point is to build an operating layer that makes governed AI practical.

1Build an AI operating layer across cloud, local, and self-hosted environments

The same core system should work with managed cloud, local models, private servers, and hybrid deployments. Some users want simplicity; some want privacy; some want control; some want cloud performance combined with local context. A shared layer — model routing, permissions, memory, action logs, approval flows — handles those differences.

Cloud, local, and private AI stop being isolated products, and become different execution environments connected by the same governance model.

2Create one experience across many interfaces

Web, desktop, mobile, CLI, API, developer tools — wherever you work from, the structure of your work should not be lost. The interfaces do not have to look identical; the foundation has to stay consistent. The same permissions apply, the same memory boundaries hold, the same approval model governs important actions, and the same logs keep them traceable.

That is what makes YonerAI more than a chat app: a control layer for AI-powered work.

3Make governed automation practical

Automation is one of AI's most powerful uses. It is also dangerous when it is invisible.

YonerAI makes automation usable in real work by guaranteeing five things: you can see what the AI is trying to do, you can approve or reject the actions that matter, you can inspect the steps it took, you can limit what it can reach, and you can stop it when you need to. The goal is not to slow AI down. It is to build acceleration safe enough to use.

4Build a developer-extensible foundation

YonerAI should not be a closed box. Developers should be able to connect tools, build workflows, define permissions, and create new AI experiences on top of the YonerAI layer — through APIs, SDKs, CLI tools, documentation, and safe integration patterns.

Nobody should have to rebuild memory, permissions, approval, logging, and model routing from scratch every time they build with AI. YonerAI provides those foundations as reusable parts.

5Move toward governed self-evolution

The long-term goal is a system that can help improve itself without escaping human control: observing usage, finding friction, proposing improvements, scoring value and risk, requesting approval, assisting implementation, assisting release.

What matters is not just that the system can improve. It is that improvement is governed. A self-evolving system should not be a black box. It should be a reviewed, logged, permissioned, human-controlled loop.

What YonerAI avoids

What YonerAI avoids

What this project refuses to become is decided with the same weight as what it builds. These are constraints on its future self, and promises to its users.

• It will not become a platform that locks users in. Being able to leave, at any time, is a design goal — not a defect.
• It will not hold local work hostage to a subscription. What runs on your PC is yours.
• It will not run invisible automation. If an important action happens behind the screen, that is a defect, not a feature.
• It will not put unauditable "intelligence" in the core. Decisions that cannot be explained will not be trusted with important work.
• It will not call reading your content "personalization." What gets recorded is action — not what you wrote.
• It will not call unfinished things finished. This page is not an exception.
• It will not call replacing human judgment "progress." Making judgment faster and taking judgment away are different things.

Operating modes

Operating modes

YonerAI is designed around three operating modes — because AI should adapt to the user's environment, not force every user into the same one. The three modes are the designed destination; today they are being implemented in stages.

Official Managed Cloud

For users who want YonerAI to work without managing infrastructure. This mode prioritizes simplicity, availability, sync, support, and a polished experience — the fastest way to start, as an official managed service.

Official Hybrid Private

For users who want the convenience of managed services while keeping sensitive workflows close to their own environment. Local files, local models, and internal systems connect to YonerAI under clear boundaries — so privacy and convenience stop being opposites.

Full Private Self-Host

For users and organizations that need direct control over deployment, runtime, data flow, and operational boundaries. Private deployments, local execution, custom infrastructure — the mode of maximum control.

These are not three separate visions. They are different doors into the same core system.

The plan

The plan

YonerAI's plan is to build the foundation before expanding the surface.

The first layer is control. The second is connection. The third is automation. The fourth is self-evolution.

The order matters. A system should not automate before it can be governed. It should not connect to sensitive tools before it has permissions. It should not improve itself before it can be reviewed. It should not become powerful before it becomes understandable.

For an AI-native future

For an AI-native future

AI will become part of how software is built, how organizations operate, how individuals learn, and how ideas become products.

That future should not require people to surrender control for convenience. Important automation should not run where nobody can see it. Every workflow should not centralize into one provider. Intelligence and responsibility should not be separated.

YonerAI is being built for a future where AI is powerful enough to matter and structured enough to trust. Where individuals use AI without losing control. Where developers build without being locked into one path. Where cloud, local, and self-hosted systems cooperate inside the same experience. Where automation is governed, not hidden. Where intelligence remains connected to human intent.