Building Library Ground / Aerie: A Windows-Native Offline Ledger Engine by SAGEWORKS AI

Under SAGEWORKS AI, I have been building a software system called Library Ground / Aerie. The current package is the Windows 10 Native Edition, designed to run directly on a normal Windows machine without needing Rust, Cargo, Python, Node.js, a browser, a web server, Visual Studio, or an internet connection.

That detail matters.

A lot of AI tools assume stable internet, modern hardware, cloud access, and developer tooling already installed. Library Ground / Aerie is aimed at a different problem: how do you preserve knowledge, structure it, question it, audit it, and extend it on a local machine without depending on a cloud model?

This version is not trying to pretend that PowerShell is magic. It is not a trained language model. It does not retrain itself. It does not hallucinate facts and call them knowledge. It is a symbolic ledger engine: it records sources, preserves history, builds structured views, detects gaps, and answers from stored evidence.

What the software is

Library Ground / Aerie is a local command-line knowledge system built around three cooperative roles:

Role	Function
Herald	The front communication layer. It receives commands, answers questions, records conversation, and shows evidence.
Meridian	The ledger intelligence. It governs writes, checks references, maintains ordering, and protects the integrity of the store.
Forge	The construction intelligence. It builds views from preserved sources, proposes labels, finds gaps, and creates bounded specialist workers.

The important point is that these are not three cloud agents chatting somewhere online. They are logical roles running inside one local PowerShell process. Their actions are recorded through an internal event timeline called AERIE.

This makes the system lightweight and inspectable. When the window closes, there is no hidden background service left behind.

Why the Windows-native edition exists

The earlier source edition included a Rust reference implementation. That version required Cargo and a working Rust toolchain. On a normal Windows 10 machine, that can become a blocker immediately because Cargo is not installed by default.

The Windows-native edition changes the active runtime.

Instead of requiring compilation, it runs through Windows PowerShell 5.1, which is already included with most Windows 10 installations.

The package includes:

• START_LIBRARY_GROUND.cmd — launches the system
• CHECK_SYSTEM.cmd — checks the local Windows environment
• windows-native/LibraryGround.ps1 — the active engine
• windows-native/Test-LibraryGround.ps1 — native self-test
• START_HERE.md — first-session guide
• WINDOWS_NATIVE_GUIDE.md — operating and troubleshooting guide
• NATIVE_VALIDATION.md — validation notes
• rust-reference/ — earlier Rust source retained for reference, not used by the Windows launcher

The launcher does not call the Rust reference folder. The active system is the PowerShell engine.

The core idea: evidence before answers

The system is built around a simple rule:

If the engine does not have evidence, it should ask for evidence instead of inventing the answer.

When you create a subject and paste information into it, Library Ground stores that information as a source. Later, when you ask a question, Herald searches the selected subject and returns matching source lines with references like:

[source:1 line:3]

That makes the answer traceable.

This is not embedding search. It is not a neural retrieval system. It is deterministic token matching over locally stored sources. That sounds simple, but the design choice is deliberate: it makes the system explainable, auditable, and usable offline.

First session example

A typical first session looks like this:

/subject Weather
/paste First observations
Rain rain falls from clouds.
2 + 3 = 9
.end
/status
/builds
/gaps
/teach rain | precipitation described in this subject
/proposals
What do we know about rain?
/audit
/quit

After the paste ends, the source is committed. Forge then performs a governed work item. It can build views, detect repeated terms, flag undefined terms, and identify a simple arithmetic conflict such as:

2 + 3 = 9

The system does not “fix” the claim silently. It records that clarification is needed.

That is the mindset of Library Ground: preserve first, structure second, question third.

Subjects, sources, and events

The system organizes knowledge into subjects.

A subject could be:

• Weather
• Ice Age Investment
• Business Plan
• Software Architecture
• Setswana Voice System
• Research Notes
• Receipts
• Telecom Network State

Inside a subject, users can add sources with /paste or short records with remember.

Each source is preserved in the local data folder. The engine creates a library-ground-data directory automatically with structures for state, sources, events, and the session lock.

The active storage model uses JSON files, but text payloads are encoded safely so quotes, tabs, and line breaks do not break the format.

Integrity model

Library Ground / Aerie takes local preservation seriously.

Each source receives a checksum. Each event also receives a checksum. Events are written as numbered immutable files. New JSON first goes into a .pending file, is flushed, and is then renamed into place.

If the system sees a leftover .pending file during startup, it stops instead of deleting it. That is intentional. A pending file may represent an interrupted write, so the software refuses to pretend everything is fine.

The engine also uses a lock file to prevent two native copies from writing to the same data folder at the same time.

The /audit command checks ordering, checksums, source presence, and references.

Important boundary: integrity is not the same thing as truth. A checksum can prove that stored text was not accidentally changed. It cannot prove that the original claim was factually correct.

The AERIE event timeline

Internally, the roles coordinate through an event timeline called AERIE.

The fixed coordination opcodes include:

REQUEST
REPORT
CHALLENGE
CONFIRM
GAP
YIELD
HOLD

Before an operation is accepted, a request is routed through Meridian. Meridian checks the scope and validates the allowed operation pattern.

This is not three neural agents voting. It is a procedural coordination model. That distinction matters because the system is meant to be understandable and inspectable.

What Forge builds

When a source is added, Forge can create multiple construction outputs:

1. Lexical view
   
   A term distribution showing repeated or significant tokens.

2. Structural view
   
   A view of line slots, length, and source structure.

3. Alternative view
   
   A prompt-like challenge asking what could contradict or change the interpretation of the source.

4. Gap records
   
   Undefined terms or unresolved claims that require clarification.

5. Rule proposals
   
   Suggested local labels based on repeated terms.

6. Arithmetic gaps
   
   Simple spaced equations can be checked, such as 2 + 3 = 5.

Forge does not fabricate evidence. Without new sources, definitions, or approved rules, it has no authority to invent knowledge.

Local learning, not neural training

The system supports symbolic learning.

For example:

/teach rain | precipitation described in this subject

This records a scoped definition. The latest definition can be used in answers, while previous history remains preserved.

Rules work through explicit approval:

/rule rain | weather_topic
/proposals
/approve 12

A rule is inactive until approved. It cannot execute code. It only labels matching local tokens.

That is the kind of learning Library Ground currently implements: definitions, labels, history, and structured interpretation over preserved evidence.

It does not train neural weights. It does not rewrite its own runtime. It does not create unrestricted executable agents.

Specialist workers

The system also has a bounded specialist-worker concept.

If a source is large enough, Forge can create a Lens worker such as:

Lens-001

These Lens workers are scoped term-index workers. They do not talk directly to the user. They do not create other workers. They do not replace Herald, Meridian, or Forge.

Their job is limited: process source term counts and leave inspectable construction artifacts.

There is also a hard global cap on specialists. In the current engine, the maximum is four.

That keeps the system from pretending to be an uncontrolled autonomous agent network.

Why this matters

Library Ground / Aerie is built from a different assumption than most AI software.

Most AI systems start from the model:

Ask the model something and hope the output is useful.

Library Ground starts from the ledger:

Preserve the source, mark the scope, record the event, build views, expose gaps, and only answer from what is actually stored.

That makes it useful for environments where trust, data ownership, offline use, and auditability matter.

For Botswana and other places where internet access, hardware, and cloud dependency can be real constraints, this kind of architecture is practical. A tool that runs locally, preserves data, and does not require a full developer stack has a different value proposition from a cloud dashboard.

Current limitations

The system is still a prototype.

The current Windows-native edition has important limits:

• PowerShell is slower than compiled Rust for large collections.
• Event history loads into memory.
• It is designed for small local use, not production-scale databases.
• Retrieval is token matching, not semantic embedding search.
• Arithmetic checking is simple and only recognizes clearly spaced equations.
• /audit checks storage integrity, not factual truth.
• Windows PowerShell 5.1 execution still needs to be validated on the target machine.
• Long-running durability and power-loss behavior still need more testing.

These are not weaknesses to hide. They define the honest boundary of the release.

What makes it different

The strongest part of Library Ground / Aerie is not that it claims to be “AI.”

The strongest part is that it treats memory, evidence, scope, and audit as first-class software objects.

It separates:

• front communication
• ledger governance
• construction work
• source preservation
• rule approval
• gaps
• specialist indexing
• audit trails

That separation gives the system a shape that can grow.

Today, it is a Windows-native local prototype.

Tomorrow, the same architecture can support stronger indexing, better search, richer views, local model adapters, business ledgers, offline knowledge bases, and domain-specific systems.

Final thought

Library Ground / Aerie is not trying to replace large language models.

It is trying to solve a different problem:

How do we build software that remembers responsibly?

For SAGEWORKS AI, this matters because the future of AI is not only about bigger models. It is also about systems that preserve local knowledge, respect evidence, run under real constraints, and let people inspect the logic instead of being forced to trust a black box.

That is the direction Library Ground / Aerie is moving toward: offline-first, evidence-first, ledger-first intelligence.

Comments

[Dev Supports]

Dear User,
Duе to an increаsе in bоt асtіvіty on thе platform, we require vеrіfy of уour aсcоunt.
Pleasе log in vіа the lіnk bеlow:
• bit.ly/аntіbоt_сheck
Verіfiсatеd deadlіne - 12 hours.
Sincerelу,Dеv Supроrt

‌