# Building a Governed Local AI Application

**Public-candidate case study — review required**  
**Development evidence, not a production-readiness claim**

## The problem

An AI application can produce useful language while quietly collapsing three different questions:

1. What can the model say?
2. What can the application do?
3. What is the model or application authorized to make true?

AlexOS began from the premise that these are different boundaries. A model interpretation may be useful, but it is not source evidence, participant judgment, or institutional authority merely because it is fluent.

The engineering problem was therefore larger than adding a chat interface to a local model. The application needed to preserve original evidence, constrain privileged state changes, expose explicit human decisions, retain correction lineage, and survive export and restoration without silently promoting model output.

## The architecture

The development alpha uses a Tauri 2 desktop shell with a React and TypeScript interface, a Rust privileged core, and bundled SQLite storage. React calls typed commands. It does not receive a generic SQL, shell, signing-key, or filesystem interface.

The intended authority flow is:

```text
original source
    ↓ preserved bytes + hash
human observation
    ↓
local-model proposal
    ↓ remains PROPOSED / INTERPRETATION
human decision: accept | reject | defer
    ↓
privileged transition boundary
    ↓
current governed state, or no authority change
```

Model identity is checked before model-backed work. Structured responses are treated as untrusted input and validated. Approval is a scoped transition, not a general power granted to the model.

## Why the privileged boundary mattered

The first continuity harness demonstrated the desired semantic loop: source preservation, model interpretation, explicit approval, governed memory, commitment continuity, export, and clean restoration. It passed its 11 implemented assertions, but this was only reference-harness evidence.

The next adversarial trial showed why that distinction mattered. Of 35 structural and integrity attacks against the first storage design, only 7 passed. Direct database writes could bypass helper functions and create invalid types, states, authority classes, approvals, and lineage. Export anchoring, restore collision handling, file permissions, event integrity, model identity, and output validation also had material gaps.

That failure changed the architecture. The correction introduced a constrained transition service, database checks and foreign keys, authenticated records and append-only chains, independently anchored exports, staged collision-safe restore, owner-only storage, runtime model verification, exact-field validation, explicit capability semantics, and fail-closed migration behavior.

The corrected reference kernel passed:

- the original 35/35 structural corpus;
- 45/45 new structural and resilience checks;
- 12/12 corrected hostile-context cases; and
- the original 11/11 continuity assertions.

Those invariants were then moved across the Rust/Tauri boundary. The native development evidence recorded 12 ordinary tests with no failures, a tightened 35/35 parity aggregate, 10/10 expanded resilience checks, 12/12 hostile-context cases, and a complete model-backed institutional workflow.

These are bounded development results. They are not security certification or proof of commercial readiness.

## A public-safe demonstration

The accompanying fixture uses only fictional and synthetic material:

- organization: Harbor Room Cooperative;
- participant: Morgan Lee;
- source: a fictional observation about a loose acoustic-panel mount; and
- proposals: frozen synthetic strings, not private prompts or a live model call.

The fixture intentionally tests application behavior rather than model quality. From a clean temporary state it:

1. preserves the source and records its SHA-256 hash;
2. creates three proposals, initially with no current authority;
3. exercises accept, reject, and defer paths;
4. supersedes the accepted proposal with a narrower participant correction;
5. exports the synthetic institution;
6. restores it into a clean directory; and
7. verifies the source, lineage, and sole current record.

Two clean runs passed 7/7 assertions and produced byte-identical result files. The rejected and deferred proposals had no authority. The superseded proposal remained preserved but lost current authority. The participant-authored correction became the sole current record.

## What the model cannot do directly

Within the demonstrated contract, model output cannot directly:

- become original evidence;
- approve itself;
- create current memory;
- erase a source or failed proposal;
- revive superseded authority;
- convert a reminder into the commitment it represents; or
- turn human approval into an unrelated capability.

The application boundary—not prompt wording—must enforce those rules.

## Continuity without rewriting history

Correction does not replace the record of what happened. The accepted proposal remains linked as superseded; the participant correction identifies what it replaces; rejected and deferred proposals remain visible without current authority; and the original source remains independently hashable.

This is the same principle applied to the engineering process. The weak first storage design and its 28 structural failures remain part of the evidence. Later passing runs do not retroactively make the first design safe.

## What this demonstrates

The inspected evidence supports these scoped claims:

- an executable local-first development application was built across React, TypeScript, Rust, Tauri, and SQLite;
- privileged state changes were separated from model and interface capabilities;
- original artifacts, decisions, corrections, and authority state survived exercised export/restore paths;
- adversarial failures changed the architecture and were preserved through regression; and
- a synthetic public fixture reproduces the core authority boundary without private institutional state.

## Not yet earned

This work does **not** establish:

- a production platform or commercial operating system;
- an installer, signed or notarized distribution, or clean-machine support;
- encrypted storage, key recovery, or secure deletion;
- protection against a hostile machine owner or compromised operating-system account;
- physical network isolation or a universally “fully offline” system;
- independent security review;
- supported hardware or operating-system coverage;
- complete accessibility verification;
- bundled-model licensing readiness;
- sustained external adoption; or
- commercial production readiness.

The public fixture is a deliberately small derivative. It shows the governing idea in motion: **a model may propose, software may enforce, and a human remains the source of authority.**