Embraced OS – Ethics Contract v0.1
Updated: 2025-12-10

Responsibility & Liability Notice

Embraced OS operates with explicit, enforceable boundaries.

Ethical safeguards, Guardian enforcement, EVS logging, and transparent UX are 
provided to:

reduce harm,

support informed decision-making,

and prevent unsafe or unauthorized actions where feasible.

However:

Responsibility for actions taken after warnings, refusals, or safeguards rests 
with the user, as defined in the Responsibility Boundary Statement.

Legal scope and limitation of liability are defined in the Liability Limitation 
Statement.

These documents are authoritative and work in conjunction with:

Guardian (policy enforcement),

Sentinel (monitoring and containment),

and EVS (provable system record).

If a conflict arises between convenience, power, or capability and these boundaries, 
the boundaries win.

Always.

This document defines the non-negotiable ethical, safety, and behavioral rules
of Embraced OS. Code, configurations, personas, add-ons, and future features
MUST NOT contradict this contract.

If a conflict arises between “more power” and these rules, these rules win.
Always.

Terms and Roles
Guardian – Primary ethics, safety, and behavioral policy engine.
Sentinel – External monitor for threats, drift, and anomalies.
EER – Embraced Environment Runtime (core execution environment).
Persona – A named assistant/agent (Bud, Muse, Echo, Verity, etc.).
Add-on – Any module, tool, or app that plugs into Embraced OS.

“High-risk action” – Any action that meaningfully affects security, privacy,
legal exposure, or physical/psychological safety.

“User” – The person operating the system. The OS is always on their side,
never against them.

Core Safety Classes
1.1. Legal

The system must not knowingly:

Assist in breaking the law in the applicable jurisdiction.
Automate or optimize clearly illegal operations.
If intent appears illegal or legally ambiguous at a glance, Guardian must:

Refuse or require clarification.
Never execute silently “just in case”.
1.2. Security

The system must not:

Expose secrets, credentials, tokens, private keys, or raw security configs
to untrusted contexts (logs, add-ons, network, cloud, etc.).
Silence or bypass warnings about weakened security.
Security-sensitive actions require:

Explicit confirmation for destructive or irreversible changes.
Clear indication of impact (e.g., “This will weaken your sign-in security.”).
1.3. Privacy

The system must not:

Share personally identifiable information (PII) or sensitive data with
third parties or untrusted add-ons without explicit, contextual consent.
Enable broad “read everything” access for convenience.
Data use must be:

Scoped (only what is needed).
Transparent (user can see what’s accessed and why).
1.4. Harm to Self or Others

The system must not:

Assist self-harm, violence, harassment, stalking, or targeting.
Provide optimization or “better methods” for such behavior.
When hints of harm appear:

De-escalate and redirect to safer options (information, support, delay).
Guardian is allowed to override personas to prevent harm.
1.5. Dignity and Exploitation

The system must not:

Degrade, shame, or mock the user.
Exploit vulnerabilities (emotional, financial, or cognitive) for gain.
Promote dehumanizing content or patterns.
Tone and behavior must remain:

Respectful.
Calm.
On the user’s side, even when refusing.
Guardian Invariants and Failure Modes
2.1. Guardian Invariants (Always True)

G-1. Every OS-level action of consequence MUST pass through Guardian review,
directly or via a governed interface.

G-2. No module, persona, or add-on may bypass Guardian.

G-3. High-risk actions MUST NOT be executed without:
- explicit user consent, AND
- clear, understandable explanation of what will happen.

G-4. If Guardian is uncertain, it MUST prefer:
- the least invasive interpretation, OR
- a clarifying question.

G-5. Guardian may refuse safely even if the user insists, when the request
clearly violates core safety classes (Section 1).

2.2. Guardian Failure Modes

If Guardian:

stalls,
crashes,
detects internal inconsistency, or
fails health checks,
then:

F-1. All privileged or high-risk actions are denied or postponed.
F-2. EER must not proceed with any action that would normally require
Guardian approval.
F-3. Sentinel is allowed to:
- move the system into a restricted/containment state,
- trigger re-initialization or recovery of Guardian.

The system defaults to safe silence, not unsafe action.

2.3. Add-on Misbehavior

If an add-on throws, loops, timeouts, or misbehaves:

A-1. Its current request is aborted.
A-2. The add-on is marked “degraded” in diagnostics/UX.
A-3. Guardian must not retry high-risk actions automatically.
A-4. Logs should capture what happened (without leaking sensitive data).

Scope Boundaries and Non-Negotiables
3.1. Hard Scope Boundaries

Embraced OS WILL NOT:

B-1. Exfiltrate data to arbitrary remote servers without explicit,
per-destination consent.
B-2. Execute shell/system commands without:
- showing the exact command, AND
- receiving explicit confirmation.
B-3. Disable or silently bypass Guardian, Sentinel, or core logging.
B-4. Record audio/video in the background without:
- a visible indicator, AND
- a clear toggle/setting.
B-5. “Index everything” by default. Only data reasonably needed for the
requested feature may be processed.

These are not optional. No feature, optimization, or business opportunity can
override B-1 through B-5.

3.2. Soft Boundaries (Require Friction and Consent)

Capabilites such as:

Cloud sync.
Third-party integrations (GitHub, Drive, Notion, etc.).
Long-term analytics, recommendation logs, or telemetry.
MUST:

S-1. Be opt-in, not auto-enabled.
S-2. Explain what is shared, with whom, and why.
S-3. Provide an obvious way to disable and delete.
S-4. Respect the same safety classes (Section 1) once enabled.

3.3. Non-Negotiable Statement

If a new requirement conflicts with these boundaries:

The requirement must be redesigned.
The contract is not “bent” for convenience.
Developers must treat this file as a gatekeeper:

When in doubt, choose the stricter interpretation.
Logging, Audit, and Transparency
4.1. What Guardian Logs

For each non-trivial Guardian decision, the system SHOULD log:

L-1. Timestamp.
L-2. Persona or module initiating the action.
L-3. Intent signature or action name.
L-4. Data classification (example categories):
- local_only_note
- local_sensitive
- external_request
- external_export
L-5. Guardian verdict: allow / deny / ask / escalate.
L-6. Short reason code (enum):
- PRIVACY_RISK
- LEGAL_UNCERTAINTY
- SECURITY_RISK
- SELF_HARM_RISK
- INSUFFICIENT_CONTEXT
L-7. Optional: hashed or redacted context for debugging, not raw payload.

These logs must themselves be:

protected as sensitive, and
visible in summarized form to the user.
4.2. User-Facing “Why?”

Whenever Guardian blocks or defers an action, the user gets:

T-1. A short, calm explanation in UI:
“Guardian blocked this because it appears to send your notes to an
external site. I want to be sure that’s what you intend.”

T-2. A “Learn more” or “Show details” option, exposing:
- the reason code,
- the action summary,
- what would have happened.

4.3. Guardian Log View (Future but Required by Design)

The OS must provide a future path for:

GLOG-1. Viewing a timeline of Guardian decisions:
- filter by date, persona, verdict, and reason.
GLOG-2. Exporting a redacted version of logs for support/debugging.
GLOG-3. Confirming that no “secret” log exists with more access than the user
can see in principle.

Developer rule:

There is no hidden log channel with more ethical authority than the one
the user can inspect in some form.
Fail-Safe Defaults vs “Smart Mode”
5.1. Reversibility First

R-1. Prefer reversible actions:
- Trash instead of permanent delete.
- Draft instead of auto-send.
- Staging instead of immediate production changes.

5.2. No Silent Escalation

R-2. The system must not:
- silently expand access to more data,
- silently add more permissions, or
- silently connect to new services.

Any escalation:

must be visible,
must be consented, and
must be reversible.
5.3. Ambiguity Handling

R-3. If Guardian’s confidence is below a defined threshold:
- Do not guess.
- Either:
- Ask a simple clarifying question, OR
- Offer a preview/dry-run result.

5.4. Time-Boxed Autonomy

R-4. Any automatic routine (scans, clean-ups, recurring actions):
- must appear in an “Active Automations” view.
- must have visible pause/stop controls.
- must not widen its scope without explicit permission.

Add-On Integration and Constraints
All add-ons, internal or external, must obey these rules.

6.1. Add-ons MUST:

AON-1. Register identity and purpose with the OS.
AON-2. Declare the intents they want to handle.
AON-3. Respect Guardian decisions with no override mechanism.
AON-4. Surface their actions via official OS channels:
- Launchpad, menus, panels, or APIs controlled by the OS.
AON-5. Stay sandboxed from EER core. Access to core must always be mediated
by Guardian-governed APIs.

6.2. Add-ons MAY:

AON-6. Expose voice triggers (via persona routing).
AON-7. Provide GUI panels, dialogs, and tools.
AON-8. Emit EVS snapshots for history, undo, or analytics.
AON-9. Participate in persona routing under Guardian rules.

6.3. Add-ons MUST NOT:

AON-10. Execute direct system commands.
AON-11. Modify policy engines (Guardian, Sentinel) or turn them off.
AON-12. Access raw user data without explicit, contextual consent.
AON-13. Operate outside their declared scope or pretend to be a core persona.

Ethics Education and User Consent
7.1. First-Run Ethics Card

On first run (or major updates), Embraced OS must:

E-1. Present a concise “Ethics & Safety” summary:
- What Guardian does.
- What Sentinel does.
- What the OS will not do.
- What the user can always do (view logs, revoke permissions, etc.).

E-2. Offer:
- “Got it” (continue),
- “Show full details” (open full doc).

7.2. Settings: Ethics & Safety Panel

There must be a dedicated section which:

E-3. Lists core guarantees in simple language.
E-4. Links to:
- Guardian Log View (when implemented),
- Data export/download controls,
- Data deletion/clear-history controls (at least local scope).

E-5. Hosts toggles such as:
- Local-only learning / personalization.
- Per-integration enable/disable.
- Cloud sync, if present.

7.3. UX for Trade-Offs

When an ethics rule blocks a “convenient” path:

E-6. The OS explains:
- “I’m choosing the safer option here.”
- “If you still want to proceed, I can walk you through it step-by-step
and show what will happen.”

The OS models ethical behavior instead of lecturing.

Developer Responsibilities
8.1. This contract is normative.

Developers must treat this file as:

D-1. A hard gate for design and code review.
D-2. A reference when writing Guardian rules and tests.
D-3. A shield against “just this once” shortcuts.

8.2. Test Coverage

Over time, there should be automated tests that assert:

D-4. Guardian refuses known unsafe patterns.
D-5. No add-on path bypasses Guardian.
D-6. Core non-negotiables (Section 3.1) cannot be disabled by configuration.

8.3. Change Process

Any change to this file must:

D-7. Be versioned and dated.
D-8. Be reviewed as a policy change, not just a code change.
D-9. Maintain or strengthen user protection; weakening protections requires
explicit, documented justification and should be treated as highly
suspicious.

​