DEV Community: Jupiter Soft

Sekura JS and Reganta OS: Why a Programming Language and an Operating System Should Be Designed Together

Jupiter Soft — Thu, 30 Jul 2026 07:10:07 +0000

Building software becomes easier when the language understands the system it runs on.

A programming language is not just syntax.

An operating system is not just a runtime environment.

They define how software thinks about computation.

Most modern languages were designed for existing operating systems and processor architectures. They inherit concepts created decades ago:

processes;
files;
threads;
virtual memory;
shared resources;
system calls.

These concepts are powerful, but they also bring complexity.

While designing Sekura JS and Reganta OS, I started from a different question:

What if a programming language and an operating system were designed together from the beginning?

This idea became one of the foundations of my experimental computing stack.

From knowledge to systems

Before designing a language or an operating system, I encountered a more fundamental problem.

Complex systems contain thousands of decisions:

why a component exists;
why a specific model was chosen;
which constraints must always remain true;
which approaches were rejected;
how different parts depend on each other.

These decisions are difficult to preserve.

That is why I am also building Sekura Noda.

Sekura Noda helps experts use AI to accumulate, improve, and monetize their unique expertise.

Noda provides a knowledge layer where important decisions can be captured, reviewed, and used by humans and AI.

This is especially important when designing systems that span multiple layers.

A programming language affects the operating system.

The operating system affects the hardware model.

Hardware limitations affect the language design.

Without explicit knowledge, these relationships become difficult to maintain.

Why create another programming language?

Creating a new programming language is usually unnecessary.

Most applications can be built with existing tools.

But a language becomes interesting when the underlying execution model changes.

Sekura JS is designed together with Reganta OS.

The goal is not to create another general-purpose language with hundreds of features.

The goal is to create a language where important system concepts are visible.

A programmer should understand:

what a module represents;
what data a module can access;
how information moves between components;
what contracts exist between parts of the system.

Instead of hiding system behavior behind multiple layers of abstraction, the language should help describe the actual architecture.

Modules instead of traditional applications

Traditional operating systems usually organize software around applications and processes.

Reganta OS explores a different model.

The primary unit is a module.

A module is a defined computational component with:

inputs;
outputs;
resources;
responsibilities;
relationships with other modules.

Instead of thinking:

Start an application and let it manage everything internally.

The model becomes:

Connect specialized modules that perform specific functions.

For example:

Input Stream
      ↓
   Parser
      ↓
 Processing Module
      ↓
 Output Stream

Each component has a clear role.

The system becomes easier to reason about because interactions are explicit.

Pages and streams

Reganta OS is built around explicit data movement.

Two important concepts are:

Streams

Streams allow modules to exchange information.

Small messages can move through lightweight communication channels.

A module can receive data, transform it, and send the result to another module.

Pages

Pages represent larger units of data.

Instead of every component copying and recreating data, pages can move through the system as identifiable objects.

This changes the way software thinks about memory.

Data is not only something an application temporarily owns.

It can be an explicit object moving through a chain of processing steps.

The kernel as an orchestrator

Traditional operating systems provide many universal mechanisms:

process scheduling;
filesystems;
permissions;
memory abstraction;
background services.

Reganta OS focuses on a smaller role.

The kernel acts primarily as an orchestrator:

connecting modules;
managing communication;
controlling resource access;
coordinating execution.

The purpose is not to support every possible workload.

The purpose is to create a predictable environment for systems designed around explicit modules and data flows.

Why design language and OS together?

A programming language usually assumes an existing operating system.

The operating system usually assumes existing programming models.

This creates layers of historical decisions.

By designing Sekura JS and Reganta OS together, it becomes possible to align:

language concepts;
execution rules;
memory model;
communication model;
system contracts.

A language can expose the strengths of the operating system.

An operating system can provide exactly the environment the language expects.

Neither has to compensate for the limitations of the other.

Building understandable systems

Modern software systems are extremely powerful.

But they are also difficult to understand.

Complexity accumulates through:

hidden assumptions;
undocumented decisions;
incompatible abstractions;
layers built on top of previous layers.

My goal with Sekura JS and Reganta OS is not simply to build different technology.

It is to explore whether systems can become more understandable by making their fundamental concepts explicit.

This is also why Sekura Noda is part of the same vision.

The ability to build complex systems depends not only on code.

It depends on preserving the knowledge behind the code.

The bigger picture

The relationship between the projects is:

Human expertise and system knowledge
              ↓
        Sekura Noda
              ↓
     Programming model
              ↓
        Sekura JS
              ↓
     Execution environment
              ↓
        Reganta OS
              ↓
      Hardware architecture
              ↓
        Memora8

Each layer defines the next one.

The language describes the system.

The operating system executes the language.

The hardware supports the execution model.

And Noda preserves the knowledge required to evolve the entire architecture.

AI was used for English translation and editorial refinement. The ideas, architecture, and technical decisions described in this article are the author’s own.

Your AI Is Not Missing Intelligence. It Is Missing Your Expertise.

Jupiter Soft — Wed, 29 Jul 2026 07:31:22 +0000

Sekura Noda helps experts turn hard-earned knowledge into a system that people and AI can actually use.

Experts often expect too much from AI.

They assume that if a model is powerful enough, a better prompt, fine-tuning, or a larger context window will eventually make it understand their work.

But the real problem is often not intelligence.

It is the gap between what the expert knows and what has actually been transferred to the AI.

Expertise is more than information

An expert does not work only with facts.

Years of experience create something much harder to describe:

criteria for choosing between alternatives;
understanding of why a decision was made;
awareness of constraints and exceptions;
professional intuition;
the ability to notice details others miss;
knowledge of when a standard rule should not be applied.

Much of this feels obvious to the expert.

That is why it is difficult to explain completely to someone who does not yet share the same experience.

The same problem appears when working with AI.

A language model may understand the words in a task, but it does not automatically understand the expert’s unique professional context.

It can miss an important restriction, combine verified knowledge with a general assumption, or confidently invent a missing detail.

The expert becomes the bottleneck

When knowledge remains in the expert’s head, every important task eventually returns to that person.

Employees ask for clarification.

Clients wait for an answer.

AI agents require more context.

The expert repeatedly:

explains the same decisions;
corrects misunderstandings;
rewrites prompts;
checks generated results;
fixes work that looked correct but ignored an important exception.

The expert’s time is spent transferring old knowledge instead of creating new knowledge.

This is the central problem Sekura Noda is designed to solve.

Knowledge needs a managed layer

Sekura Noda creates a controlled knowledge layer between the expert, other people, and AI.

The expert can capture individual pieces of expertise:

a rule;
a decision;
a method;
a definition;
a limitation;
an exception;
the reasoning behind a professional choice.

These pieces remain readable and editable by people.

They can be reviewed, improved, connected to related knowledge, and made available to AI for specific tasks.

The AI uses the expertise, but it does not own or define it.

The expert decides:

which knowledge is correct;
which knowledge has been verified;
who can access it;
where it can be applied;
which sources were used for an answer.

This is different from asking a model to reconstruct expertise from documents and conversations.

Why prompts and fine-tuning are not enough

Prompts can shape a model’s behavior.

Fine-tuning and LoRA can make responses more consistent.

But they do not automatically create a growing, human-readable, and verifiable system of expertise.

They do not clearly answer:

Which knowledge is currently accepted?
Which idea was rejected?
Which decision has been replaced?
Why does this rule exist?
When should the rule not be used?
Who controls the knowledge?
Which answer was based on which source?

A model can behave as if it understands the expert.

That is not the same as having access to an explicit system of expert knowledge.

Expertise should keep working

The goal is not simply to store what the expert already knows.

The goal is to make that expertise reusable and continuously improve it.

With Sekura Noda, an expert can capture knowledge once and apply it across different scenarios:

programming;
helpdesk;
analysis;
consulting;
employee training;
client support;
specialized AI assistants.

AI handles more repetitive work using approved expertise.

The expert reviews the results, adds new knowledge, improves existing rules, and spends more time solving problems that have not yet been solved.

This creates a cycle:

Expertise
    ↓
Captured and reviewed knowledge
    ↓
AI-assisted work
    ↓
New experience and corrections
    ↓
Improved expertise

The accumulated knowledge does not remain static.

It becomes a system that grows through use.

Expertise as an asset

When expertise exists only in someone’s head, it is valuable but difficult to scale.

It depends on the expert’s constant presence.

When that expertise becomes a managed system, it can support more people, more clients, and more AI agents without proportionally increasing the expert’s personal workload.

It can also become the foundation for:

faster client service;
expert AI assistants;
new products and services;
employee training;
business continuity;
transferring or selling a company;
scaling expert work.

The expert does not disappear from the process.

Their role changes.

Instead of repeating accumulated knowledge, they focus on extending it.

The principle behind Sekura Noda

An expert should spend time creating new knowledge, not endlessly repeating what has already been learned.

Sekura Noda helps experts use AI to accumulate, improve, apply, and monetize their unique expertise.

The existing expertise continues to work.

The expert continues to grow.

AI was used for English translation and editorial refinement. The ideas, positioning, and product principles described in this article are the author’s own.

I Started Building an AI Knowledge System Because My Projects Became Too Complex

Jupiter Soft — Tue, 28 Jul 2026 12:32:40 +0000

How Sekura Noda helps me develop a programming language, an operating system, and a processor architecture with AI.

I am working on four connected projects:

Sekura Noda — a knowledge system for humans and AI;
Sekura JS — a system programming language;
Reganta OS — a micro operating system;
Memora8 — a processor architecture.

At first, these may look like four separate projects.

In practice, they exposed the same fundamental problem:

A complex system cannot be developed reliably when its knowledge exists only in a person’s memory, source code, documents, and AI conversations.

That problem led me to build Sekura Noda.

AI can help, but it does not remember the project correctly

AI tools are extremely useful in software development.

They can help analyze architecture, generate code, compare alternatives, explain decisions, and find contradictions.

But every new conversation begins with limited context.

The AI may know general programming principles, but it does not automatically know:

which architectural decisions I accepted;
which ideas I rejected;
which terms have a specific meaning inside the project;
which older decisions have been replaced;
why the system was designed this way.

A long conversation does not solve the problem.

Important information becomes mixed with temporary ideas, incorrect assumptions, abandoned experiments, and generated suggestions.

Documents do not completely solve it either. A document may contain many ideas, but it does not clearly show which individual statements are still valid.

Source code is also insufficient. It shows what is implemented, but often not why a decision was made.

Knowledge needs its own layer

Sekura Noda treats knowledge as a separate part of the system.

Its basic unit is a short canonical article describing one idea:

a definition;
an architectural rule;
an accepted decision;
a constraint;
a relationship between components.

Each article remains readable by a person.

It can also be reviewed, changed, connected to other articles, and used by an AI system.

The important difference is that the AI does not decide what becomes project knowledge.

A model can suggest a new idea, improve an explanation, or identify a contradiction. But a person decides whether the result should be accepted.

This creates a clear separation:

AI generates possibilities.

Humans approve knowledge.

Why ordinary RAG is not enough

Retrieval-augmented generation can find relevant fragments in documents and provide them to a language model.

That is useful, but retrieval does not establish authority.

Imagine that a project contains:

an old specification;
a newer design note;
a discussion where another approach was proposed;
source code implementing only part of the decision.

A search system can retrieve all four.

The language model can generate a convincing answer from them.

But which source represents the current architecture?

Relevance and correctness are not the same thing.

Noda adds an explicit knowledge layer where accepted decisions can be separated from drafts, rejected ideas, and outdated information.

Noda as an engineering tool

I use Noda not only as a product for organizational knowledge.

I also use it to develop my own projects.

Sekura JS requires clear definitions of modules, execution rules, and system contracts.

Reganta OS requires consistent decisions about data exchange, orchestration, software modules, and firmware.

Memora8 requires precise architectural rules about memory, pages, processors, and ownership.

These systems are too complex to keep entirely in my working memory.

They are also too interconnected to describe reliably through isolated documents.

A change in the processor architecture may affect the operating system. A change in the operating system may affect the programming language. The reasoning behind those changes must remain understandable months or years later.

Noda gives those decisions a persistent form.

Instead of asking AI to reconstruct the project from a large collection of files and conversations, I can give it access to a structured set of accepted knowledge.

Human-readable knowledge matters

Many AI systems store knowledge in forms that people cannot inspect directly:

model weights;
embeddings;
vector indexes;
hidden prompts;
generated summaries.

These mechanisms are useful, but they should not become the only representation of important knowledge.

Project knowledge should remain readable without a specific model.

A developer should be able to inspect it.

An expert should be able to correct it.

Another AI model should be able to use it later.

The knowledge should survive changes in tools, models, and implementation technologies.

That is why Noda does not attempt to replace human-readable knowledge with AI.

It uses AI to make human knowledge more useful.

One project supports the others

Sekura JS, Reganta OS, and Memora8 are experiments in language, operating systems, and processor architecture.

Sekura Noda operates at a different level.

It preserves the knowledge required to understand and develop all of them.

The relationship is simple:

Sekura Noda
    ↓
accepted architectural knowledge
    ↓
Sekura JS
Reganta OS
Memora8

Noda does not execute programs or manage hardware.

It helps ensure that the ideas behind those systems do not disappear, contradict each other, or depend entirely on one person’s memory.

The larger question

AI makes it possible for a small team—or even one person—to explore systems that previously required much larger groups.

But increased development speed creates a new problem.

We can generate code and ideas faster than we can preserve a coherent understanding of them.

The limiting factor may no longer be the ability to produce software.

It may be the ability to maintain reliable knowledge about what we are building.

That is the problem Sekura Noda is designed to solve.

AI was used for English translation and editorial refinement. The ideas, projects, and architectural decisions described in this article are the author’s own.