DEV Community: Jupiter Soft

My CPU Was Correct, But It Was Wasting Millions of Instructions

Jupiter Soft — Fri, 21 Aug 2026 09:53:52 +0000

This is a submission for DEV's Summer Bug Smash: Clear the Lineup powered by Sentry.

Project Overview

Memora8 is an experimental multi-core processor architecture and system simulator.

The project includes a complete execution environment: a custom CPU model, memory subsystem, runtime, and development tools. The goal is not only to execute programs, but to explore how software behavior and processor architecture interact.

As a real workload, I implemented parallel BLAKE3 hashing on an 8-CPU configuration.

In this setup, CPU0 works as an orchestrator:

distributes work between worker CPUs;
manages PageMover operations;
processes events;
collects intermediate results from worker FIFOs.

The BLAKE3 implementation was functionally correct and produced valid digests.

Performance analysis revealed a hidden inefficiency in the orchestrator CPU idle path: the processor was correct, but it was spending execution time checking for work that was not available.

Bug Fix or Performance Improvement

During BLAKE3 benchmarking, I found a hidden performance issue in the CPU orchestration path.

The BLAKE3 pipeline used an event-driven design: worker CPUs performed hashing, while CPU0 coordinated the system. However, when no worker result, PageMover transition, or reduction progress was available, CPU0 continued executing the orchestration loop:

check events
check PageMover
check worker FIFOs

no progress

repeat

The system was correct, but CPU0 was spending instructions only to discover that nothing had changed.

The first step was to track whether an orchestration pass produced any progress:

let progress = service_page_movers();

Every useful operation now reports activity. If the complete pass finishes without progress:

if (progress == 0)
    hp.cpu_sleep_ticks(64);

CPU0 enters a bounded sleep state instead of immediately polling again.

This required changes not only in the BLAKE3 runtime code, but also in the CPU simulator. Memora8 already supported CPU sleep, but deferred sleep commands did not preserve timed sleep semantics. A request for:

sleep for N ticks

could become:

sleep until external wake

after command retirement.

The fix introduced:

preservation of deferred sleep mode and timeout values;
cpu_sleep_ticks() and cpu_sleep_kticks() runtime operations;
correct timed wake behavior in the simulator;
updated scheduler handling so timed sleepers remain future runnable work instead of being treated as fully idle.

The result was a CPU that can efficiently wait for future work instead of spending execution time repeatedly checking for it.

Code

The source code is maintained in a private repository.

The implementation is available in commit:

b4ac2bb Add timed CPU sleep for BLAKE3 orchestration
Date: July 25, 2026

Main changes:

examples/blake3/amod.sjs
- added orchestration progress tracking;
- replaced empty polling cycles with bounded CPU sleep when no progress is made.
examples/blake3/bmod.sjs
- removed unnecessary explicit wake calls from worker CPUs.
examples/blake3/hash_pipeline_common.sjs
- added cpu_sleep_ticks() and cpu_sleep_kticks() runtime helpers.
mr8sim/iomem.h
- added deferred timed sleep state handling;
- preserved sleep mode and timeout information across deferred CPU commands;
- moved CPU sleep operations into the device-based sleep path.
mr8sim/system.cpp
- updated simulator scheduling so CPUs sleeping for a timeout are treated as future runnable work and simulated time continues advancing.
tests/mr8sim_shared_sram_test.cpp
- added regression coverage for timed sleep, timeout wake-up, external wake interruption, and invalid sleep commands.

The change spans the BLAKE3 orchestration code, runtime API, CPU sleep model, simulator scheduling, and regression tests.

My Improvements

The main challenge was not making BLAKE3 compute faster, but making the CPU orchestration model more efficient.

CPU0 is responsible for coordinating the parallel workload. It must react quickly when workers, FIFOs, or PageMover operations make progress, but it should not spend execution cycles repeatedly checking the same state when nothing has changed.

The first change was introducing progress tracking in the orchestration loop.

Previously, every iteration performed the same checks regardless of whether anything useful happened. The new approach makes each subsystem report progress:

let progress = service_page_movers();

Worker result collection and reduction steps also update this state.

After a complete orchestration pass:

if (progress == 0)
    hp.cpu_sleep_ticks(64);

the CPU enters a bounded sleep period instead of immediately starting another polling cycle.

The important design decision was to avoid a permanent sleep. CPU0 cannot simply wait for one external event because progress may come from different sources. A timed sleep provides a middle ground:

check system
      |
      v
progress available?
      |
   yes -> continue
      |
   no
      |
 sleep N ticks
      |
 wake and check again

The second part of the change was making this behavior possible in the processor simulator itself.

Memora8 already had CPU sleep support, but deferred sleep commands did not preserve the requested sleep mode. A timed sleep request could lose its timeout information during command retirement and become an external-wake-only sleep.

The simulator was updated to preserve:

sleep mode;
timeout value;
deferred sleep state.

Timed sleepers are also no longer treated as completely idle CPUs. The simulator continues advancing system time until the timeout expires or an external wake occurs.

This change required coordination between multiple layers:

BLAKE3 orchestration
        ↓
Sekura JS runtime helpers
        ↓
CPU sleep device interface
        ↓
CPU state management
        ↓
system simulator scheduling

The result is a CPU model where idle waiting is represented as an architectural state instead of repeated instruction execution.

Results

The optimization was tested using parallel BLAKE3 workloads from 8 KB to 8 MB on an 8-CPU Memora8 configuration.

The goal was not to change the BLAKE3 algorithm or reduce the amount of useful computation. The goal was to reduce unnecessary orchestration overhead while keeping the execution result identical.

The final benchmark measures the complete optimized orchestration path.

Across the tested workloads, the optimized version showed:

up to 11.6% reduction in CPU0 instructions;
up to 9.5% reduction in branch bubbles;
up to 4.9% reduction in total executed instructions;
up to 24.5% wall-clock improvement on smaller workloads where orchestration overhead dominates;
approximately 5% wall-clock improvement on the largest 8 MB workload.

Example: 8 MB BLAKE3 workload.

Before:

Elapsed:        510.005 s
Total cycles:   534,106,223
Total insns:    2,483,144,031

After:

Elapsed:        482.985 s
Total cycles:   514,918,425
Total insns:    2,415,378,301

The largest reduction was in orchestrator activity:

CPU0 instructions:

Before:
452,195,508

After:
399,811,800

This shows that the optimization reduced the amount of work performed by the coordinating CPU rather than changing the hashing workload itself.

Correctness was verified across all tested input sizes.

For every workload from 8 KB to 8 MB, the BLAKE3 digest remained identical between the original and optimized versions.

The final result is a processor model where idle waiting is represented explicitly instead of being simulated as repeated polling instructions. The CPU still reacts to new work, but no longer spends execution time repeatedly proving that no work is available.

Why This Was Interesting

This was not a bug that produced an incorrect result.

The CPU executed correctly and every BLAKE3 digest matched.

The problem was that the processor model represented waiting as execution. The CPU spent instructions proving that no work was available.

The fix changed waiting from active computation into an explicit architectural state.

This is the key difference between optimizing an application and optimizing a processor architecture: the cost of waiting itself becomes part of the design.

When People Were People, They Wrote Words

Jupiter Soft — Wed, 19 Aug 2026 07:32:57 +0000

here was a time when people went online to talk.
Not to scroll.
Not to build a personal brand.
Not to collect followers, likes, reactions, karma, achievements, or years of carefully accumulated history.
They wrote words.
And at that moment, those words were almost everything you had.
You could be talking to one person.
Or ten.
Or a hundred.
It didn't matter much who you had been yesterday.
There was no profile containing fifteen years of your life for everyone to inspect before deciding whether your next sentence deserved attention.
There wasn't always a number next to your name telling everyone how important you were supposed to be.
There wasn't an algorithm deciding which sentence should be shown to which person.
You were there.
Other people were there.
And you had something to say.
Your status was what you could say right now
I miss something about that kind of internet.
A conversation had a strange equality to it.
Of course, people still had names and reputations. Some people were known. Some were respected. Some were idiots.
But when a live conversation started, you still had to participate.
Your archive couldn't speak for you.
Your follower count couldn't speak for you.
Yesterday's successful post couldn't speak for you.
You had only what you could say now.
And once you said it, the conversation moved on.
I think we have lost some of that.
The modern internet remembers everything
Today almost every communication product accumulates history.
Messages remain.
Posts remain.
Profiles grow.
Communities build archives.
Search indexes them.
Algorithms rediscover them.
Something you wrote five years ago can suddenly become part of a conversation happening today.
Sometimes that's incredibly useful.
But does every human conversation need to become a database?
When I talk to someone at a table, the conversation doesn't automatically become an archive.
If you arrived twenty minutes late, you missed twenty minutes.
Maybe somebody will tell you what happened.
Maybe they won't.
That's part of being there.
Online communication increasingly removed that property.
We made everything recoverable.
And in doing so, perhaps we made presence less important.
What if you simply missed it?
That's the idea I wanted to experiment with.
A public text conversation where the present matters.
If you're there, you can see what people are saying.
If you're not there, you don't.
If something interesting happened ten minutes before you arrived, perhaps you'll never know exactly what was said.
And that's okay.
There is no obligation to catch up.
No unread counter telling you that you owe the internet another 247 messages of your attention.
You enter.
You see who is talking now.
You can say something.
Or just watch.
Then you leave.
One stream
I also didn't want to recreate the old model exactly.
I didn't want hundreds of rooms.
I didn't want private spaces inside private spaces inside servers inside communities.
So I built Talk around one public live stream.
Everyone who is connected shares the same stream.
You can filter what you see using names and tags, but you don't create another little universe that everyone else has to join.
The underlying place remains public.
It is deliberately simple.
Anyone can come in and read.
If you want to speak, you create an Identity using a Passkey.
Then you have your name and your words.
The messages themselves don't become a permanent conversation history.
Maybe this is a terrible idea
That's entirely possible.
We've spent decades moving in the opposite direction.
People expect synchronization across devices, searchable history, private groups, channels, notifications, recommendations and archives.
Perhaps we've become accustomed to those things because they're genuinely better.
Or perhaps there is still room for something else.
A place that doesn't ask:
What did I miss?
but instead asks:
Who is here now?
That's what I want to find out.
I built Talk as an experiment rather than an answer.
Come by yourself.
Or, better yet, bring a few friends.
Because a live conversation with nobody there is nothing.
But put ten people there at the same moment, and something might happen.
And if you weren't there?
You may never know.
Try Talk: https://talk.sekura.world

AI Needs a New Computing Stack

Jupiter Soft — Sat, 01 Aug 2026 04:56:58 +0000

Why Sekura Noda, Sekura JS, Reganta OS, and Memora8 are designed as one system.

Most AI systems today are added on top of existing software.

We connect a language model to databases, documents, APIs, and applications.

This approach is useful.

But it leaves an important question unanswered:

Is the current computing stack designed for a world where AI actively participates in creating and using knowledge?

I started exploring this question through four connected projects:

Sekura Noda — a knowledge system for experts and AI;
Sekura JS — a programming language designed around a different execution model;
Reganta OS — a micro operating system based on modules, pages, and streams;
Memora8 — an experimental processor architecture organized around memory.

They are different layers of the same idea:

Important decisions should remain explicit, understandable, and controllable by humans.

The problem is not only intelligence

Modern AI models are extremely capable.

They can write code, analyze information, explain concepts, and generate solutions.

But intelligence alone does not solve a fundamental problem:

AI does not automatically know what is important for a specific person, company, or system.

An expert has years of accumulated knowledge:

professional decisions;
rules and exceptions;
reasons behind choices;
hidden constraints;
understanding of context.

This knowledge usually exists in:

people’s experience;
conversations;
documents;
source code;
personal memory.

The problem is not that information does not exist.

The problem is that it is not organized as a usable system.

The first layer: knowledge

This is where Sekura Noda begins.

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

Noda creates a layer between experts and AI where important knowledge can be captured, reviewed, connected, and reused.

The expert decides:

what knowledge is correct;
what decisions are accepted;
which rules apply;
what context AI can use.

AI helps apply knowledge.

It does not become the owner of knowledge.

This distinction is important.

A model can generate an answer.

Only a person can decide whether that answer represents the expertise of an organization.

The second layer: programming

If knowledge becomes an explicit system, programming also needs to evolve.

Traditional programming languages were created around existing computer models.

They usually describe:

instructions;
memory addresses;
processes;
files;
operating-system services.

Sekura JS explores a different direction.

A language should reflect the system it runs on.

Instead of hiding important relationships, it should help describe:

modules;
data flow;
resource ownership;
system contracts.

The goal is not to create more syntax.

The goal is to make the architecture visible.

The third layer: execution

A programming model requires an execution model.

This is the role of Reganta OS.

Reganta explores a system where software is organized around modules rather than traditional applications.

Modules communicate through explicit streams and work with defined data units.

The operating system focuses on orchestration:

connecting components;
controlling access;
moving data;
coordinating execution.

The goal is a smaller and more understandable system.

The fourth layer: hardware

At the lowest level is Memora8.

Most processors are organized around the CPU.

The CPU executes instructions, and memory supports it.

Memora8 explores another perspective:

What if computation was organized around memory pages?

In this model:

pages exist independently;
processors receive temporary ownership;
computation happens where data is processed;
ownership and access become explicit.

The processor becomes a worker acting on data rather than the permanent center of the system.

One connected stack

The relationship between the projects:

Human expertise
       ↓
 Sekura Noda
       ↓
Programming model
       ↓
 Sekura JS
       ↓
Execution model
       ↓
 Reganta OS
       ↓
Hardware model
       ↓
 Memora8

Each layer supports the next.

Noda preserves the knowledge behind the architecture.

Sekura JS describes programs using the system concepts.

Reganta OS executes those programs.

Memora8 provides the hardware foundation.

Why build the whole stack?

Creating one application would be much easier.

But many problems appear because each layer of computing was designed separately.

Applications assume operating systems.

Operating systems assume processors.

Programming languages assume execution models.

AI systems are now added on top of all of them.

Perhaps the next generation of computing requires a different approach:

not only smarter models,

but systems where knowledge, software, execution, and hardware share the same principles.

The human remains responsible

AI changes the speed of development.

A single person can explore ideas that previously required large teams.

But speed creates a new challenge:

How do we preserve understanding?

How do we ensure that generated code, generated designs, and generated decisions remain connected to human intent?

This is why the foundation of this stack is not the processor.

It is knowledge.

AI can help create.

Humans must decide what becomes part of the system.

That is the idea behind Sekura Noda and the larger Sekura 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.

Memora8: What If Computing Were Organized Around Memory?

Jupiter Soft — Fri, 31 Jul 2026 06:13:04 +0000

An experimental processor architecture where memory pages exist independently and processors receive temporary access to them.

Most computer architectures are described around the processor.

The CPU executes instructions, reads data from memory, transforms it, and writes the result back. Memory is usually presented as a resource supporting the processor.

This model has worked extremely well.

But it is not the only possible way to organize computation.

While designing Memora8, I started with a different question:

What if memory pages were treated as independent parts of the system rather than passive storage owned by a running program?

Memora8 is an experimental processor architecture built around this idea.

The processor is usually the center

In a conventional system, computation is organized around programs running on processors.

The operating system gives each process an address space. The process reads and modifies memory through addresses. Data is interpreted mainly through the program currently using it.

This creates a familiar model:

Program
   ↓
CPU
   ↓
Memory

The processor is active.

Memory is passive.

Memora8 explores the reverse perspective.

Pages exist independently

In Memora8, memory is divided into pages.

A page is not merely a temporary piece of a process address space. It exists independently of the processor that currently works with it.

The page can contain:

input data;
an intermediate result;
program state;
structured records;
information moving between processing stages.

A CPU does not permanently own the page.

Instead, the system temporarily allows a processor to work with it.

The relationship becomes:

Memory Page
     ↓
Temporary ownership
     ↓
Processor performs a task
     ↓
Page is released or transferred

The data retains its identity while different parts of the system process it.

Temporary ownership

Temporary ownership is one of the central ideas behind Memora8.

When a processor receives a page, it receives the right to work with that page for a defined period or operation.

Other processors should not modify the same page simultaneously.

When the task is complete, ownership can return to the system or move to another processor.

This makes an important relationship explicit:

A processor can modify a page only while it owns that page.

The goal is not merely to restrict access.

The goal is to make data movement and responsibility easier to understand.

At any moment, the system should be able to answer:

Where is the page?
Which processor currently owns it?
Who is allowed to modify it?
Where should it go next?

Computing as page processing

This model makes it possible to describe computation as a sequence of operations over pages.

For example:

Input Page
    ↓
Parser
    ↓
Structured Page
    ↓
Analysis
    ↓
Result Page

Each processing stage receives access to the page, performs its work, and passes the result forward.

The processor is no longer the permanent center of the system.

It becomes a temporary worker assigned to data.

Why explore this model?

Modern systems contain many hidden relationships between processors, memory, operating systems, and applications.

Data may be copied several times.

Ownership may be implied rather than explicit.

Multiple components may access the same memory through complex synchronization rules.

Memora8 asks whether some of this complexity can be reduced by making pages and ownership central architectural concepts.

Potential advantages include:

clearer responsibility for data;
controlled access to memory;
fewer ambiguous shared-memory relationships;
more explicit movement of information;
an architecture that is easier to reason about;
stronger foundations for later verification.

These advantages are still hypotheses.

Memora8 is an experimental architecture, not a claim that conventional processors should be replaced.

Its purpose is to explore another way of organizing computation.

Connection with Reganta OS and Sekura JS

Memora8 is being designed together with two other projects.

Reganta OS organizes execution around modules, pages, and streams.

Sekura JS is a programming language intended to describe programs for that execution model.

The projects influence each other:

Sekura JS
Programming model
      ↓
Reganta OS
Execution and orchestration
      ↓
Memora8
Memory and processing model

The language should express the concepts supported by the operating system.

The operating system should use the concepts supported by the processor.

Designing the layers together makes it possible to avoid abstractions that exist only to compensate for mismatched assumptions.

Preserving the architecture with Sekura Noda

A processor architecture contains many interconnected decisions.

Changing one rule about pages may affect the operating system, programming language, and verification model.

These decisions cannot remain only in source code, diagrams, conversations, or the architect’s memory.

I use Sekura Noda to preserve the knowledge behind Memora8, Reganta OS, and Sekura JS.

Definitions, accepted decisions, rejected alternatives, constraints, and relationships can be maintained as explicit knowledge that both people and AI can use.

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

In this project, Noda allows AI to assist with architectural work without giving the model authority over the architecture itself.

AI can suggest possibilities.

The accepted knowledge remains controlled by a person.

A different center of computation

Memora8 begins with a simple change in perspective.

Instead of asking:

What memory belongs to this processor?

It asks:

Which processor temporarily owns this page?

That change may lead to a different relationship between hardware, operating systems, programming languages, and data.

The processor still performs computation.

But memory is no longer treated only as a passive resource surrounding it.

Pages become independent parts of the system, and processors temporarily work on their behalf.

That is the central experiment behind Memora8.

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

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.