# SentinelOS and AEGIS Ecosystem Technical Paper

**Subtitle:** Local-First Operating Environment, Desktop Suite, and Private AI Companion Architecture  
**Draft:** v0.2  
**Date:** 10 July 2026  
**Scope:** SentinelOS, Sentinel Desktop Suite, Sentinel Browser/Download Guard/Wallet, and AEGIS Prime private companion architecture  
**Terminology note:** The request used "AWGIS". This paper treats that as AEGIS unless the ecosystem name is later changed.

---

## Abstract

SentinelOS is a Debian-based, security-first, local-first desktop operating environment designed around user control, privacy, drift resistance, and practical daily computing. It is not an AI-dependent operating system. Instead, it provides a hardened and coherent desktop foundation on which local tools, protected applications, and optional AI assistance can operate.

AEGIS Prime is the private companion layer intended to operate inside or alongside SentinelOS. It is designed as a local household assistant, knowledge steward, family archivist, technical advisor, and digital shield. AEGIS is governed by explicit user authority, local vault policy, auditability, and the rule that AI must advise rather than control. It may assist with approved Sentinel Desktop Suite applications and local system functions, but control remains transparent, reversible, permission-based, and logged.

The wider ecosystem consists of four major layers: the SentinelOS base and desktop branding layer; the Sentinel Desktop Suite of local-first applications; the Sentinel Browser, Download Guard, and Wallet security cluster; and the optional AEGIS Prime intelligence and automation layer. Together, these form a private computing environment designed to support household productivity, personal records, repair work, bookkeeping, media, documents, browsing, wallet workflows, and future AI-assisted operations without surrendering ownership of data or decision-making. Its base security doctrine is security via upgradeable packages: policy, hardening, repair logic, audited application behavior, desktop defaults, and stable locks are delivered through controlled, versioned, inspectable Debian packages rather than unmanaged manual changes.

## Keywords

SentinelOS; AEGIS Prime; local-first AI; Debian; MATE desktop; desktop suite; private assistant; local vault; threat model; user-controlled automation; secure restore; wallet bridge; banking mode; drift-resistant computing; package-governed security; upgradeable packages; Repeatable package discipline; Debian stability.

## 1. Introduction

Modern desktop computing increasingly depends on cloud accounts, telemetry, opaque update channels, online AI services, and application ecosystems that move user data away from the owner. SentinelOS takes the opposite position. It treats the user's machine as the primary authority, the user's files as local assets, and AI as optional capability rather than a requirement.

The SentinelOS and AEGIS ecosystem has three design goals:

1. **Create a stable, understandable desktop environment.** The operating environment should be usable by a normal person, recoverable when changes go wrong, and consistent enough that future upgrades can be audited against known baselines.
2. **Provide a coherent suite of local-first applications.** Notes, documents, inventory, maintenance records, media, wallet workflows, and future bookkeeping should live under a shared Sentinel design language and security doctrine.
3. **Prepare for private AI assistance without making AI mandatory.** AEGIS Prime should be able to read approved local context, assist with approved apps, and eventually operate approved workflows, but the system must remain usable when AEGIS is absent or disabled.

This paper defines the current technical model, component map, security principles, integration points, implementation state, and roadmap for the ecosystem.

## 2. System Objectives

The ecosystem is built around the following operational objectives:

- **Local-first ownership:** local storage, local configuration, local app state, local vaults, and local model execution wherever practical.
- **Security-first posture:** guarded restore, safe archive extraction, private file permissions, explicit confirmations for destructive operations, no unnecessary network behavior, and clear boundaries between user action and automation.
- **Security via upgradeable packages:** security posture is not left as scattered manual configuration. Policy, fixes, hardening, trusted defaults, app contracts, repair scripts, and baseline declarations are delivered through controlled Debian packages that can be installed, upgraded, verified, held, rolled back, or replaced.
- **Repeatable package discipline on a Debian foundation:** SentinelOS aims for describable, repeatable, auditable system state through Debian/APT packages, manifests, validation commands, changelogs, and rollback notes.
- **AI-optional doctrine:** SentinelOS must run and remain useful without any AI model installed.
- **User authority:** the user remains final authority. AEGIS may advise, prepare, warn, or execute approved actions, but it must not override human decisions.
- **Drift resistance:** every installed baseline should be identifiable, versioned, documented, and recoverable.
- **Transparent automation:** automation must be permission-based, auditable, reversible where practical, and scoped to approved domains.
- **Practical household utility:** the system should support real household workflows: notes, checklists, documents, personal records, repairs, inventory, pantry, media, browser safety, wallet management, future ledger/bookkeeping, and long-term knowledge preservation.

## 3. Terminology

| Term | Definition |
|---|---|
| SentinelOS | Debian-based local-first desktop environment and branding layer. |
| Sentinel Desktop Suite | Collection of Sentinel applications for notes, documents, browser, wallet, inventory, maintenance, media, and related workflows. |
| AEGIS Prime | Private local AI companion layer with household memory, advisory behavior, vault access, and future approved tool control. |
| AEGIS Vault | Local knowledge and memory repository used by AEGIS for structured records, family knowledge, project records, manuals, and personal reference material. |
| Sentinel Command | Command/control launcher concept for SentinelOS and AEGIS functions. |
| Banking Mode | Hardened Sentinel Browser mode for high-trust browsing with wallet, dApp, provider, and WalletConnect integrations disabled. |
| Local-first | Design approach where primary function, storage, and authority remain on the user's local machine. |
| Drift resistance | Ability to identify, compare, repair, and roll back system state against a known baseline. |
| Security via upgradeable packages | SentinelOS doctrine that security policy, hardening, fixes, repair logic, app baselines, and trusted defaults should be shipped as auditable Debian packages rather than unmanaged one-off edits. |
| Repeatable package discipline | Design principle meaning inspectable, versioned, recoverable system state through Debian packages, validation reports, checksums, manifests, changelogs, and rollback notes. |

## 4. Architectural Overview

The ecosystem can be described as layered architecture:

```text
+------------------------------------------------------------------+
|                         Human Authority                          |
|             User decisions, permissions, review, consent          |
+------------------------------------------------------------------+
|                         AEGIS Prime Layer                        |
|     Local model, Open WebUI, vault search, safe tools, advisory   |
+------------------------------------------------------------------+
|                    Sentinel Desktop Suite Layer                  |
|  Notes, Browser, Wallet, Documents, Inventory, Maintenance, Media |
+------------------------------------------------------------------+
|                  SentinelOS Desktop and Branding Layer           |
| MATE profile, menu structure, wallpapers, login/GRUB branding     |
+------------------------------------------------------------------+
|                        Debian Base System                        |
|        Packages, kernel, filesystem, permissions, services        |
+------------------------------------------------------------------+
```

The model intentionally separates identity, desktop presentation, applications, and AI operation. SentinelOS should be installable and useful without AEGIS. AEGIS should be installable or enabled as a separate option. Gold AEGIS identity and private companion behavior should not contaminate the base SentinelOS identity when AEGIS is absent.

A cross-cutting package-governed security plane runs through all layers. In practical terms, SentinelOS does not rely on hidden manual tweaks as the source of trust. The desired state is expressed through packages, package metadata, checksums, manifests, reports, validation commands, and repair/rollback paths. This gives SentinelOS a controlled-state discipline while keeping Debian/APT as the operating base.

## 5. SentinelOS Base Environment

SentinelOS currently targets a Debian Trixie foundation with the MATE desktop environment. The known host baseline used during development included Debian GNU/Linux 13, MATE 1.26.1 on X11, Marco/Metacity window management, and an Ollama-capable local model stack. The design is not bound permanently to one laptop, but the initial development path used a Debian laptop before migration planning for a Windows workstation and later Linux parity.

The base environment is expected to provide:

- Standard Debian package management.
- A MATE desktop profile with safe, non-destructive customization.
- Local-only application behavior by default.
- The ability to install, verify, repair, and roll back Sentinel branding and desktop assets.
- A menu structure that separates SentinelOS, AEGIS, Desktop Suite, system tools, utilities, development, and help entries.
- Clear package/version reporting.

SentinelOS uses Debian stability and customizability as its operating foundation. It keeps the standard Debian/APT mental model so packages can be inspected, pinned, held, replaced, rebuilt, or removed by the owner. At the same time, it uses repeatable package discipline at the policy level: system state should be describable, versioned, auditable, and recoverable where practical. The influence is architectural discipline: reduce unmanaged drift, package security policy, document every baseline, and make repair/rollback paths ordinary rather than exceptional.

SentinelOS is not defined merely by color changes or wallpaper. Desktop branding includes the system's menu taxonomy, launcher policy, application categories, default pinned panel layout, login and boot identity, icon doctrine, theme doctrine, repair tooling, package metadata, and documentation.

## 6. Desktop Branding and Visual Doctrine

SentinelOS visual identity is separated from AEGIS identity:

| Area | SentinelOS Base | AEGIS Overlay |
|---|---|---|
| Primary base identity | Light/cyan Sentinel direction | Gold AEGIS direction |
| AI dependency | None | Optional companion layer |
| Theme role | Operating environment | Private intelligence/assistant presence |
| Icon doctrine | SentinelOS application identity | AEGIS-specific tools and status indicators |
| Installation rule | Safe base branding | Only installed/enabled when AEGIS is present |

Current desktop direction includes:

- Base SentinelOS remains light/cyan.
- Gold is reserved for AEGIS-only conditional overlay behavior.
- Desktop surfaces should remain opaque rather than transparent.
- Sentinel Command may be the main desktop icon, while Sentinel Command, Sentinel Browser, and Sentinel Notes are preferred pinned panel launchers.
- Browser icon direction is a globe with a central Sentinel logo/monogram, with no eye motif and no triangle-only motif.
- Light icon theme uses cyan direction and graphite grey surfaces where black surfaces were removed.
- Public website direction should use the official dark/cyan interface theme; logo artwork may retain official brand colouring where appropriate.

The best menu layout is a practical hierarchical model:

```text
Applications
  SentinelOS
    About SentinelOS
    Apply Desktop Defaults
    Reset Desktop
    Menu Repair
  Sentinel Command
    Sentinel Command
  Sentinel Desktop Suite
    Notes
    Browser
    Documents
    Password Vault
    Inventory
    Maintenance
    Media Index
    Media Player
    System Monitor
  AEGIS Prime
    AEGIS Prime Setup
    AEGIS Vault Setup
    AEGIS Status
    AEGIS Tools
  System
  Utilities
  Development
  Help
```

This layout reduces desktop clutter while making the system understandable. The desktop itself should not become an unstructured dumping ground for every program.

## 7. AEGIS Prime Architecture

AEGIS Prime is the optional private companion layer. Its purpose is to assist, remember, advise, protect, and operate within user-approved local boundaries. It is not designed to be a remote cloud identity, corporate assistant, or autonomous controller.

### 7.1 Identity and Doctrine

AEGIS doctrine can be summarized as:

- Advisory, not controlling.
- Suggestive, not manipulative.
- Logical, not emotional in decision authority.
- Loyal, not cunning.
- Protective, not intrusive.
- Observant, not overwhelming.
- Conversational, not corporate.
- Companion, not authority.

AEGIS may use the address form "Sir" when appropriate because that is part of the approved local identity style. It must not fabricate memories, records, events, family history, system state, weather, date/time, or tool access.

### 7.2 Local Model Stack

The development baseline for AEGIS uses:

| Component | Baseline / Role |
|---|---|
| Model runtime | Ollama |
| Base model | qwen2.5:7b |
| Custom model identity | aegis-prime:latest |
| Primary local interface | Open WebUI |
| Local API | 127.0.0.1:11434 |
| Tool status doctrine | Live tools must be explicitly connected before claims of live access |

The approved status concept is:

```text
AEGIS Prime local identity active, Sir.
Local model running through Ollama.
Live tools not yet connected.
```

That wording is important because it prevents the model from pretending to have system, time, weather, sensor, calendar, file, or network access before those tools are connected.

### 7.3 AEGIS Layered Model

AEGIS architecture is divided into the following layers:

| Layer | Purpose |
|---|---|
| Constitution | Identity, operating principles, boundaries, safety rules, and doctrine. |
| Core Identity | Model behavior, address style, local-first statements, and status responses. |
| Profile | Personality, tone, approved response patterns, and interaction style. |
| Memory Vault | Structured local memory and household records. |
| Knowledge Repository | Manuals, PDFs, eBooks, technical material, law/financial references, and skills knowledge. |
| Project Workspace | SentinelOS, AEGIS, and Desktop Suite development records. |
| Command Interface | Approved user-facing controls and command workflows. |
| Model Engine | Ollama-hosted local language model. |
| Automation | Future permissioned local actions, logged and reversible where practical. |

## 8. AEGIS Vault Design

The AEGIS Vault is the structured local knowledge store. Its function is to preserve context, project records, manuals, family knowledge, and practical reference material while remaining under local user control.

The requested vault scope includes:

```text
AEGIS_Vault/
  Knowledge/
  Family history/
  Memories/
  Values/
  Schedules/
  Lessons learned/
  Project records/
  Practical wisdom/
  Birthdays/
  Major Events/
  Major Human Race Events/
  Ambroso Family Tree/
  Life Skills/
  Off-Grid Living/
  Technology/
  PDFs/
  eBooks/
  Manuals/
  Law/
  Financial/
  Job Skills/
    Welding/
    Building/
    Mechanical/
    Electrical/
    Horticulture/
  Subjects/
    Science/
    Math/
    Art/
    Graphics & Design/
```

Vault tools include or target:

- Vault creation script.
- Vault indexing with checksums.
- Vault search.
- Safe file reading.
- Drop-folder ingestion pipeline.
- PDF/eBook/manual classification.
- Windows and Linux parity scripts.
- Future local retrieval for AEGIS context.

The Vault must distinguish between stored records and model inference. AEGIS must not invent historical records or family memory. If a fact is not in the Vault or approved memory, AEGIS should state that it does not have that record.

## 9. Sentinel Desktop Suite

The Sentinel Desktop Suite is the local-first application layer. It is intended to make SentinelOS useful even when AEGIS is disabled.

### 9.1 Current Program Map

The following map reflects the current corrected working direction. Some package versions may differ between working artifact, package version, and bundle version, so the table distinguishes role/status from exact artifact lock where known.

| Program | Name | Role | Current Direction / Status |
|---:|---|---|---|
| 101 | Sentinel Program Manager | Application/package management layer | v1 stable direction |
| 102 | Sentinel Notes | Notes, tasks, checklist templates | v1.0.2 checklist/holiday templates patch baseline |
| 103 | Sentinel Calculator | Calculator utility | v1 direction |
| 104 | Sentinel Calendar | Calendar utility | v1 direction |
| 105 | Sentinel Diary | Local diary | v1.0.1 direction |
| 106 | Sentinel Terminal | Sentinel-themed terminal | v1 direction; safe mode and AEGIS status integration direction |
| 107 | Sentinel Ledger | Finance/bookkeeping with receipt functionality integrated | Active/future target |
| 108 | Sentinel System Monitor | Local system monitor | v1 direction |
| 109 | Sentinel Virus Scanner | Malware/security scanning | Pending target |
| 110 | Sentinel Browser | Browser with guarded modes | Active; v1.1.x browser cluster direction |
| 111 | Sentinel Contacts | Contacts management | Pending target |
| 112 | Sentinel Jobs | Jobs/work tracking | Pending target |
| 113 | Sentinel Password Vault | Local password vault | v1 stable/completed direction |
| 114 | Sentinel Maintenance | Maintenance/repair records | v1.0.1 security audit hotfix baseline |
| 115 | Sentinel Inventory | Inventory, barcode/serial tracking | v1.0.1 security hotfix baseline |
| 116 | Sentinel Documents | Local document management | v1.0.2 security baseline |
| 117 | Sentinel Pantry | Pantry/household stock | In progress |
| 118 | Sentinel Media Index | Media scanning/indexing | v1 stable; paired media baseline direction |
| 119 | Sentinel Media Player | Local media playback/catalogue | v1 stable paired with Media Index |
| 120 | F.O.R.G.E | Build/creation tooling concept | Reserved/future |
| 129 | Safe Open | Safe file opening workflow | Reserved/future |
| 199 | Sentinel Wallet | Local wallet foundation and browser bridge | v1.1.x integrated with browser cluster |

### 9.2 Application Security Pattern

Across the suite, a repeated security pattern has emerged:

- Avoid unsafe archive extraction.
- Require explicit confirmation tokens for destructive restore/import actions.
- Use safe staged restore flows before replacing active databases.
- Prefer SQLite backup APIs over raw file copying for active databases.
- Mark unsafe paths rather than blindly trusting restored document paths.
- Skip symlinks in backups where appropriate.
- Prevent CSV/spreadsheet formula injection in exports.
- Use private permissions for DBs, sidecars, backups, exports, labels, and bridge files where practical.
- Refuse root runtime by default unless an explicit override is provided.
- Maintain stable-lock reports and validation artifacts.
- Preserve local-only/no-telemetry/no-network doctrine unless a feature explicitly requires and documents network use.

This pattern should become a formal suite-wide development standard.

## 10. Sentinel Browser, Download Guard, and Wallet Cluster

The Browser/Download Guard/Wallet cluster is a critical part of the ecosystem because it touches web content, downloads, wallet workflows, dApp interactions, and high-risk browsing contexts.

### 10.1 Browser Modes

The approved user-facing browser mode model is:

| Mode | Purpose | Wallet / dApp Behavior |
|---|---|---|
| Normal Mode | Standard Sentinel browsing with normal local browser features | Wallet and dApp features may be available where explicitly enabled. |
| Private Mode | Temporary/no-history or reduced-persistence browsing | Intended for privacy-oriented sessions. |
| Banking Mode | Hardened high-trust browsing for finance, banking, and sensitive accounts | Wallet, dApp, provider, and WalletConnect integrations disabled. |

Banking Mode is deliberately not a wallet mode. It is a hardened trust mode. Disabling wallet/provider surfaces reduces the risk of malicious pages invoking wallet-related flows during sensitive banking sessions.

### 10.2 Download Guard

Sentinel Download Guard exists to inspect and control downloads before they become trusted local files. Its role is to support safer file handling, especially when paired with Safe Open and future scanner features.

Target behavior includes:

- Local inspection and metadata capture.
- Safer handling of risky extensions.
- Clear user prompts.
- Integration with browser download workflows.
- Future scanner integration.
- No silent cloud upload requirement.

### 10.3 Sentinel Wallet

Sentinel Wallet is a local wallet foundation connected to the browser through explicit bridge workflows. The current doctrine emphasizes:

- Master passphrase never stored.
- Local encrypted foundation.
- User-approved signing flows.
- Browser-generated request identifiers.
- Approve/reject response JSON paths for local bridge operation.
- Clear status reporting.
- No hidden signing or broadcast behavior.
- Banking Mode isolation from wallet/dApp/provider/WalletConnect integrations.

The wallet must treat transaction signing, message signing, and network broadcast as separate trust events. The user must be able to see what is being requested and approve or reject it explicitly.

## 11. Data Model and Persistence

The ecosystem relies on several local data stores:

| Store | Data Type | Security Requirements |
|---|---|---|
| AEGIS Vault | Memory, records, manuals, knowledge, project files | Local ownership, checksums, safe reading, no fabricated records. |
| App SQLite DBs | Notes, documents, inventory, maintenance, pantry, media, ledger | Private permissions, safe backups, staged restore. |
| Browser profiles | Normal, private, banking mode state | Mode separation, sensitive state minimization. |
| Wallet vault | Wallet secrets and derived records | Encryption, passphrase never stored, explicit signing approval. |
| Sidecar metadata | Media/document/artwork/index records | Local-first, bounded parsing, safe paths. |
| Bridge files | Browser-wallet/AEGIS-app handoff files | Private permissions, request IDs, validation, bounded processing. |

Persistence rules should be boring, predictable, and auditable. The system should prefer explicit file locations, readable manifests, and stable CLI status commands over opaque hidden state.

## 12. Security Model

### 12.1 Core Doctrine: Security via Upgradeable Packages

The base and heart of the SentinelOS and AEGIS ecosystem is **security via upgradeable packages**. SentinelOS treats packages as the normal delivery vehicle for security posture, not merely as an application installation format. A security improvement should arrive as a controlled package transition whenever practical.

Under this doctrine, packages may carry:

- Hardened application code and safer defaults.
- Desktop policy and menu/launcher defaults.
- Guarded restore and import behavior.
- Repair and rollback helpers.
- Status, audit, and verification commands.
- Stable-lock reports, manifests, checksums, and validation notes.
- AEGIS tool contracts and permission boundaries when applicable.

This produces a practical hybrid philosophy:

| Influence | SentinelOS Interpretation |
|---|---|
| Repeatable package discipline | System state should be describable, inspectable, versioned, and recoverable through packages and documented validation material. |
| Debian stability | The foundation remains mature, widely understood, conservative, and maintainable through Debian/APT packaging. |
| Debian customizability | The owner can inspect, rebuild, hold, pin, replace, remove, or override packages without surrendering control. |
| Debian-based user control | SentinelOS keeps the familiar Debian/APT model: packages can be inspected, upgraded, held, pinned, replaced, rebuilt, or removed by the owner. |

An upgrade is therefore treated as an auditable security transition. A package version should reveal what changed; a report should explain why; checksums should prove artifact identity; validation commands should show the resulting state; and rollback notes should preserve recovery options. This reduces hidden drift and turns hardening into a maintainable lifecycle.

### 12.2 Trust Boundaries

The primary trust boundaries are:

1. **Human user boundary:** the user is the authority. Any automation crossing into action must be approved or pre-authorized in a narrow scope.
2. **Local machine boundary:** local files, tools, and model runtime are trusted only according to local permissions and validation.
3. **Application boundary:** each Sentinel app owns its own state and exposes controlled interfaces.
4. **AEGIS boundary:** AEGIS can advise from context, but tool actions must be connected, scoped, logged, and permissioned.
5. **Network boundary:** network access is not assumed. Online access is future optional capability, not baseline dependency.
6. **Browser/web boundary:** web pages are untrusted. Downloads, wallet requests, and dApp requests require defensive handling.
7. **Restore/import boundary:** imported backups and archives are untrusted until validated, staged, and confirmed.

### 12.3 Threat Model

| Threat | Risk | Mitigation Direction |
|---|---|---|
| Archive traversal | Files written outside intended restore paths | Safe bounded extraction, manifest validation, no blind extractall. |
| Malicious restore | Corrupt DB or unsafe paths injected | Staged restore, validation, confirmation tokens, path marking. |
| CSV formula injection | Exported spreadsheet triggers malicious formulas | Escape dangerous prefixes in CSV/export fields. |
| Symlink backup abuse | Backup captures or restores unintended files | Skip symlinks or treat as metadata only. |
| Root runtime damage | App runs as root and writes unsafe state | Refuse root runtime by default. |
| Browser wallet abuse | Web page triggers wallet signing/provider calls | User-approved bridge, request IDs, Banking Mode disables wallet surfaces. |
| Model hallucination | AEGIS invents records or tool state | Status doctrine, vault-grounded memory, explicit uncertainty. |
| Data exfiltration | Local records uploaded without consent | Local-first/no-telemetry default, explicit network gates. |
| UI drift | System becomes inconsistent after patches | Versioned baselines, stable-lock reports, repair/rollback tools. |
| Manual hardening drift | Security depends on undocumented local edits that cannot be audited or reproduced | Put policy and fixes into versioned packages with manifests, reports, checksums, and status commands. |

### 12.4 Security Invariants

These invariants should remain true across future releases:

- SentinelOS must not require cloud AI to boot, function, or manage core desktop tasks.
- AEGIS must not claim live access until tools are connected.
- AEGIS must not fabricate stored records.
- Destructive restore/import must require explicit confirmation.
- Wallet signing must be user-visible and approval-based.
- Banking Mode must remain isolated from wallet/dApp/provider/WalletConnect behavior.
- App data must remain local unless the user explicitly enables external sync or network use.
- Every significant package/baseline should have a report, manifest, checksum, and validation notes where practical.
- Security improvements should be package-delivered where practical, so the system can upgrade, verify, audit, and roll back security posture through normal Debian mechanisms.

## 13. Permissions and Automation Governance

AEGIS-compatible applications should expose actions through contracts that clearly separate read-only status, preparation, and execution.

| Action Class | Examples | Required Control |
|---|---|---|
| Read-only | Status, summaries, search, list files | Allowed when tool scope is approved. |
| Prepare | Draft note, prepare export, stage backup | User review before final action. |
| Modify local state | Create note, update inventory, restore DB | Explicit approval or standing narrow permission. |
| Sensitive operation | Wallet signing, restore, delete, import, network sync | Explicit per-action approval and logging. |
| External action | Online lookup, remote sync, email, web service call | Disabled by default; must be explicitly enabled. |

Automation should be logged with:

- Timestamp.
- Tool/app name.
- User request or permission source.
- Input summary.
- Files modified.
- Result status.
- Rollback/undo reference where practical.

## 14. Implementation Baseline and Known Artifacts

The ecosystem is under active construction. The following baselines are important known anchors rather than final universal release claims:

| Area | Known Baseline / Artifact Direction |
|---|---|
| SentinelOS desktop reset | v0.1.9b2 Theme Rollback + Clean Professional Reset verified clean in prior validation direction. |
| SentinelOS visual baseline | v0.2.3b Visual Baseline Metadata Cleanup artifact exists as narrow metadata cleanup over v0.2.3a direction; installation confirmation may still be separate. |
| Login branding | v0.1.9d LightDM Login Branding Baseline staged-only direction. |
| Desktop branding | Menu/categories, repair helpers, wallpaper/login/GRUB branding, and conversion readiness are current focus before icons. |
| Browser cluster | v1.1.x line with Normal/Private/Banking direction, bookmark toolbar preservation, Banking icon hotfix, Download Guard, and Wallet integration. |
| Notes | v1.0.2 holiday/checklist template patch direction. |
| Documents | v1.0.2 security baseline direction. |
| Inventory | v1.0.1 security/restore/scanner hardening hotfix direction. |
| Maintenance | v1.0.1 security audit hotfix direction. |
| Media pair | Program 118 Media Index and Program 119 Media Player paired v1 master installer direction. |
| Wallet | v1.1.x local wallet/browser bridge direction, user-approved signing, banking isolation. |
| AEGIS | Local Ollama/Open WebUI/qwen2.5:7b foundation, Vault tooling, live tool connection pending unless explicitly wired. |

A release-quality technical record should store each baseline with:

- Package names and exact versions.
- SHA256 checksums.
- Manifest.
- Install script.
- Uninstall or rollback notes.
- Validation report.
- Known limitations.
- Stable lock declaration where applicable.

## 15. Development and Packaging Standards

Sentinel packages should follow a repeatable packaging discipline. The package is the security unit, the repair unit, the audit unit, and the upgrade unit wherever practical. This is the operational form of SentinelOS's package-governed security model: keep Debian packaging and user control, while making system state explicit enough to inspect, reproduce where practical, and recover.

Sentinel packages should follow this baseline discipline:

1. Source tree is versioned and archived.
2. Debian package is produced with clean metadata.
3. Package does not perform unsafe maintainer-script behavior.
4. Install script verifies checksums before installation where bundled.
5. Package produces status/report commands.
6. Runtime refuses unsafe modes where practical.
7. Backup/restore flows are guarded.
8. Artifacts include report, manifest, validation, and SHA256 files.
9. New releases preserve stable baseline behavior unless intentionally changed.
10. Changes are documented as patch scope, not vague improvement claims.
11. Security-relevant behavior is changed through upgradeable packages rather than silent manual edits.
12. Packages expose enough status information for Sentinel Command, AEGIS, or a human operator to verify installed posture.

Package versioning should avoid accidental metadata drift such as malformed double suffixes. Metadata cleanup releases should be narrow and clearly documented.

## 16. User Experience Model

The user experience target is practical rather than flashy. The system should feel like a coherent operating environment for work, repair, household management, media, browsing, and personal records.

### 16.1 Desktop Defaults

Recommended default panel pinned launchers:

1. Sentinel Command.
2. Sentinel Browser.
3. Sentinel Notes.

Recommended desktop icon policy:

- Keep Sentinel Command as the primary desktop icon.
- Keep the rest discoverable through menu categories and pinned panel launchers.
- Avoid flooding the desktop with every suite app.

### 16.2 Interaction with AEGIS

AEGIS should interact like a practical local assistant:

- It greets and reports true local status.
- It explains what it can and cannot access.
- It can summarize project state from approved records.
- It can warn about scams, manipulation, risky downloads, and unsafe workflows.
- It can prepare actions for user review.
- It can eventually operate approved apps under explicit, logged authority.

It must not invent capabilities, pretend to have live access, or behave like an unbounded autonomous agent.

## 17. Interoperability and Portability

The ecosystem has two portability tracks:

| Track | Purpose |
|---|---|
| Linux/SentinelOS track | Primary Debian/MATE implementation, packaging, desktop integration, local apps. |
| Windows workstation track | Temporary or parallel host path for AEGIS scripts/gateway, while preserving architecture and later Linux parity. |

Portable components should be written with clear separation between:

- Core logic.
- OS-specific paths.
- Desktop integration.
- Package/install behavior.
- Runtime service management.
- UI launchers.
- File permissions.

This allows the AEGIS Vault, ingestion tools, and local assistant logic to remain conceptually stable across hosts.

## 18. Roadmap

### 18.1 Near-Term Priorities

1. Complete desktop environment readiness before final icon polish.
2. Confirm current SentinelOS desktop branding baseline installation state.
3. Lock panel launcher layout and menu taxonomy.
4. Finalize browser mode behavior: Normal, Private, Banking.
5. Preserve bookmark toolbar and Banking icon hotfix behavior.
6. Continue suite-wide security hardening and stable-lock reports.
7. Build or refine AEGIS local tool wiring for host status, vault search, safe file read, and controlled app actions.

### 18.2 Medium-Term Priorities

1. Complete Ledger with integrated receipt functionality.
2. Advance Pantry to stable baseline.
3. Build Contacts and Jobs utilities.
4. Define Safe Open and Virus Scanner integration with Download Guard.
5. Create unified suite status command/report.
6. Add consistent app contracts for AEGIS-controlled read/prepare/modify actions.
7. Implement vault ingestion pipeline for PDFs, eBooks, manuals, and categorized knowledge.
8. Create cross-platform Windows/Linux parity tooling for AEGIS Vault and scripts.

### 18.3 Long-Term Priorities

1. Full local companion workflow with approved automation.
2. Voice interface for AEGIS.
3. Real-time local listening mode with user-controlled activation and privacy boundaries.
4. Local calendar, birthday, schedule, and reminder integration.
5. Scam/manipulation warning mode for conversations and messages.
6. Offline knowledge retrieval over the Vault.
7. Optional online capability through explicit gateways, never silent background dependence.
8. Family knowledge preservation and generational archive support.

## 19. Evaluation Criteria

A SentinelOS/AEGIS release should be evaluated against these criteria:

| Criterion | Pass Condition |
|---|---|
| Local-first | Core function works offline and stores primary state locally. |
| AI-optional | SentinelOS and suite apps remain useful without AEGIS. |
| User control | Sensitive actions require explicit approval or narrow standing permission. |
| Auditability | Actions and releases have logs, reports, manifests, or validation notes. |
| Security | Restore/import/download/wallet flows are guarded. |
| Drift resistance | Baselines are versioned and repairable. |
| UX coherence | Menu, panel, icons, themes, and app behavior feel unified. |
| Recovery | Rollback/repair paths exist for risky desktop or data changes. |
| Honesty | AEGIS reports actual tool access and does not fabricate state. |

## 20. Open Engineering Questions

Several areas remain open and should be resolved through implementation/testing:

1. What is the final stable SentinelOS version naming scheme once desktop branding, login, GRUB, and icon baselines converge?
2. Should AEGIS app-control contracts use JSON files, local sockets, DBus, or a hybrid local gateway?
3. What is the minimum safe logging schema for AEGIS actions without over-collecting private data?
4. How should Vault ingestion classify ambiguous files without silently misfiling important records?
5. How should Banking Mode prove wallet/provider surfaces are disabled at runtime?
6. What is the correct split between Sentinel Command and AEGIS Prime command surfaces?
7. How much online capability should be exposed in a public AEGIS-style ecosystem while keeping private AEGIS distinct?
8. How should family-history preservation be permissioned, backed up, and protected from accidental overwrite?

## 21. Proposed Reference Architecture

The recommended near-term architecture is:

```text
sentinelctl
  status
  suite status
  desktop status
  desktop apply/reset/repair
  aegis-prime status
  browser status
  wallet status
  vault status

AEGIS Local Gateway
  read-only tools
    host_status
    vault_search
    safe_file_read
    app_status
  preparation tools
    draft_note
    stage_backup
    prepare_export
  sensitive tools
    restore_app_backup
    wallet_sign_request
    delete_record
    network_lookup

Sentinel App Contracts
  JSON action schemas
  local-only handoff directories
  request IDs
  result JSON
  audit log entries
  confirmation tokens for dangerous actions
```

The key principle is that Sentinel apps remain normal applications first. AEGIS integration is an additional control surface, not the only way to use the system.

## 22. Conclusion

SentinelOS and AEGIS together define a practical local-first computing ecosystem. SentinelOS provides the stable, branded, recoverable desktop foundation. The Sentinel Desktop Suite provides useful local applications for daily life, household operations, documents, inventory, media, browser safety, and future bookkeeping. The Browser/Download Guard/Wallet cluster handles high-risk web and wallet workflows with mode separation and explicit approval. AEGIS Prime provides the optional intelligence layer, grounded in local vaults, user authority, and transparent tools.

The strongest architectural decision is the separation between SentinelOS and AEGIS. SentinelOS must remain useful without AI. AEGIS must remain permissioned and truthful about its access. This separation keeps the ecosystem robust: the operating system is not dependent on an assistant, and the assistant does not become an unbounded controller.

The next critical step is to continue converting the current working artifacts into stable, documented baselines with exact version metadata, installation status, rollback paths, and suite-wide contracts. Once the desktop environment, browser cluster, and core suite apps are stable, AEGIS can be connected through carefully scoped local tools to become the intended private household companion: useful, protective, technical, loyal, and always under human authority.

## Appendix A: Draft Stable Invariants

- SentinelOS is Debian-based and local-first.
- SentinelOS is security-first, drift-resistant, privacy-respecting, and user-controlled.
- AI is optional, not required.
- AEGIS is private, local-first, and permission-governed.
- Public AI ecosystem capability should not be called private AEGIS unless explicitly separated.
- Gold identity belongs to AEGIS; cyan/light identity belongs to SentinelOS base.
- Banking Mode disables wallet/dApp/provider/WalletConnect integrations.
- Wallet signing is explicit and user-approved.
- Restore/import paths are guarded.
- App data is local by default.
- AEGIS does not fabricate memories, records, or live access.
- The user remains final authority.

## Appendix B: Suggested Document Set

For a release-quality ecosystem, maintain the following documents:

| Document | Purpose |
|---|---|
| SentinelOS Technical Paper | Architecture, doctrine, component model, security posture. |
| SentinelOS Installation Guide | Install, verify, repair, rollback. |
| SentinelOS Desktop Branding Manual | Themes, icons, menu, panel, login, GRUB, wallpapers. |
| Sentinel Desktop Suite Program Map | Program numbers, package names, versions, status. |
| AEGIS Prime Architecture Manual | Model, Vault, tools, permissions, local gateway. |
| AEGIS Vault Manual | Folder tree, ingestion, indexing, backups, memory rules. |
| Browser Security Manual | Modes, Download Guard, Wallet bridge, Banking Mode proof. |
| Suite Security Standard | Restore/import, permissions, CSV safety, root refusal, audit logs. |
| Release Baseline Ledger | Every artifact, checksum, status, validation, known issues. |

## Appendix C: Suggested Suite-Wide App Contract Skeleton

```json
{
  "schema": "sentinel.app.contract.v1",
  "app_id": "sentinel-notes",
  "program_number": 102,
  "capabilities": {
    "read_only": ["status", "list_notes", "search_notes"],
    "prepare": ["draft_note", "prepare_export"],
    "modify": ["create_note", "update_note"],
    "sensitive": ["delete_note", "restore_backup"]
  },
  "security": {
    "local_only": true,
    "requires_confirmation": ["delete_note", "restore_backup"],
    "audit_log": true,
    "network_access": false
  }
}
```