Not a new package manager
SentinelOS continues to use Debian packages, dpkg and APT. The model adds a coherent package contract rather than introducing a competing installer.
Policy as Packages turns system intent into visible, versioned Debian components.
SentinelOS uses Debian's own package-management model to deliver the choices that define the operating system. Security defaults, desktop identity, trusted repositories, suite integration and optional AEGIS boundaries become installable components that can be inspected, updated, verified, repaired and removed.
Debian-nativeBuilt around normal packages, APT and dpkg
VersionedEvery managed policy change has an identifiable release
AuditableInstalled state can be compared with published records
RepairableManaged files and dependencies can be restored through package tools
Plain-language definition
What does “policy” mean in SentinelOS?
Policy is the documented set of technical choices that makes a general Debian installation behave as SentinelOS. It is not a legal policy and it is not an AI instruction. It is the intended system state: which trusted sources are used, which packages belong together, which defaults are applied, which services are enabled, how the desktop is presented and where optional components must remain separated.
Packaging these choices means they are treated as maintained parts of the operating system rather than as undocumented changes made once during installation.
Repository trustApproved package sources, signing keys and release channels.
Security postureManaged hardening defaults, service choices and verification rules.
Desktop identityThemes, icons, menus, login presentation and familiar desktop defaults.
Suite contractsRequired applications, dependencies, launchers and integration boundaries.
Optional AEGIS boundaryPublic AEGIS remains optional, complete and separate from private components.
Important boundary
What the model is not
Policy as Packages strengthens normal Debian administration. It does not replace it.
Not an immutable operating system
The user still has normal administrator authority. SentinelOS can detect and repair managed drift, but it does not make the filesystem permanently read-only.
Not hidden enforcement
Package names, versions, dependencies and files remain inspectable. Important changes should have a visible package owner and a documented purpose.
Not a replacement for Debian
Debian supplies the stable base, package tools and broad software ecosystem. SentinelOS supplies a focused policy layer for its own desktop and mission.
A synthesis of established system-management ideas.
The model is not copied from one operating system or project. It combines ideas that have proved useful across Debian administration, Unix system design, configuration management, policy as code, verifiable release engineering and local-first computing. SentinelOS applies those ideas through conventional Debian packaging so the result remains familiar and maintainable.
Debian package management
Debian already provides package metadata, dependency handling, checksums, upgrade paths, file ownership and removal semantics. SentinelOS treats these mechanisms as the natural place to store operating-system policy.
Unix and Linux administration
Small, explicit components are easier to understand than one opaque installer. Logs, commands, package ownership and administrator authority remain available to the person maintaining the machine.
Policy as code
Important configuration should begin as reviewable source, pass through validation and become a versioned release. This reduces the gap between what the system is meant to be and what was actually installed.
Configuration management
Managed systems compare current state with intended state, identify drift and apply focused repairs. SentinelOS adopts that discipline without requiring a separate configuration-management server.
Verifiable and repeatable delivery
Manifests, checksums, package versions and validation records make releases easier to compare and reproduce. SentinelOS does not claim perfect reproducibility until it has been demonstrated, but the model is designed to move in that direction.
Local-first computing
The local computer remains the centre of control. Policy is installed and evaluated on the machine rather than being silently imposed by a remote account or compulsory cloud service.
Why add this to Debian?
Debian's neutrality is a strength, but SentinelOS needs a defined system contract.
Debian is intentionally broad and flexible. It provides excellent mechanisms without forcing every installation to use the same desktop, security profile, local applications or assistant layer. That freedom is exactly why SentinelOS can be built on Debian.
A named operating system also needs to state what its supported configuration is. Without a package-owned policy layer, the conversion would become a collection of one-time script changes, copied files and undocumented assumptions. Those changes would be difficult to audit, upgrade, repair or reproduce.
Debian supplies the trusted mechanism. SentinelOS supplies a coherent, inspectable policy for its own system.
Consistent identity
The desktop, login screen, menu structure, icons and application integration can be delivered as a known set rather than as unrelated manual edits.
Security that can be maintained
Hardening choices can receive versions, updates and repair procedures instead of remaining buried in the original conversion script.
Drift detection
Verification tools can compare installed packages and managed files with the published contract and report where the machine has moved away from its baseline.
Safe optional components
Public AEGIS packages and gold branding can be conditional on the complete public suite, while base SentinelOS remains cyan and independent.
Clear upgrade paths
Changes can move through package versions and repository updates instead of repeatedly running a large conversion script over an existing system.
Supportable releases
Users and maintainers can identify the installed baseline, collect useful evidence and repair package-owned state with standard Debian tools.
Policy lifecycle
From design decision to maintainable system state
1. Define
Describe the intended behaviour, user boundary, files, dependencies and rollback expectations.
2. Package
Place the managed configuration and integration logic into a clearly named Debian package.
3. Validate
Check package structure, script syntax, dependency contracts and policy conflicts before publication.
4. Publish
Release through the signed SentinelOS repository with version records, checksums and supporting documentation.
5. Verify
Compare the installed system with the expected package baseline and report missing, unexpected or changed state.
6. Update or repair
Upgrade, reinstall, restore or remove the package using normal system tools and a documented recovery path.
Example policy layers
One model, several focused package families.
SentinelOS avoids placing every decision inside one enormous package. Focused packages and metapackages provide clearer ownership and allow changes to be tested in smaller units.
Foundation packagesSystem identity, repository trust, baseline dependencies and release markers.
Hardening packagesSecurity configuration, safe defaults and verification helpers.
Desktop packagesThemes, icons, login integration, menu layout and desktop defaults.
Suite packagesApplication groups, launch contracts and cross-application integration.
Conditional AEGIS packagesOptional public-suite tooling and its separate Navy, Grey and Gold presentation.
Honest limitations
Packages improve control, but they do not remove the need for testing and judgement.
Root can still change the system
Administrator authority remains real. A package can report or repair managed drift, but it cannot prevent every intentional local modification.
Runtime behaviour still matters
A correct package does not prove that every device, driver or application workflow will behave perfectly. Clean-machine testing remains necessary.
Signatures must be verified
Checksums detect changed files. Repository and detached signatures are separate trust controls and must be validated against the expected key.
Backups remain essential
Package repair is not a substitute for backups of personal data, local configuration and important system records.
Is Policy as Packages required for every Debian user?
No. Debian works well as a general-purpose operating system without SentinelOS. The model is necessary for SentinelOS because SentinelOS promises a specific desktop, security posture, application suite and optional AEGIS boundary that must remain identifiable and maintainable.
Does it stop users customising their system?
No. Users keep normal control. SentinelOS should distinguish between the supported baseline and intentional local changes, then explain when a custom change affects verification or upgrade behaviour.
Why not keep everything in the conversion script?
The conversion script is useful for establishing the first system state. Long-term maintenance belongs in packages because packages provide ownership, versions, dependencies, upgrades, removal and repair semantics.
Is AEGIS part of the base policy?
Only its boundary is part of the base policy. The public AEGIS suite remains optional. Gold desktop assets must appear only when the complete public AEGIS suite is installed, while private AEGIS Prime and private R.E.P.O components remain outside the public distribution.