# STEWARD Governance, EDENA, and Data Boundaries

## Implementation contract for Hermes

**Product:** STEWARD — Hospital & Clinic Administrator Mission Control  
**Governing principle:** AI supports stewardship; accountable humans decide, authorize, execute, and record.  
**Private default:** minimum necessary, no sensitive operational data, agents disabled, connectors off, preview first.

Implement governance as executable application logic shared by every surface. A warning paragraph in the Guide is not enforcement. The same policy engine must govern manual mission work, imports, attachments, AI prompts and responses, retrieval, tools, exports, backups, badges, logs, and Hermes handoffs.

## 1. Composition of STEWARD controls

CHART, ALIGN, ORBIT, and EDENA have different jobs and must be composed rather than substituted for one another.

1. **Identity and context** establish the user-selected role dashboard, exact active hat, entity/site/service, data partition, edition, intended artifact, and requested action.
2. **CHART** determines whether the authority, data, sources, risks, records, traceability, and safe exit are sufficient to prepare the work.
3. **EDENA** classifies the risk and determines advisory, review, approval, and enforcement requirements.
4. **ALIGN** maps the human-owned organizational work: aim, affected people, decision ownership, interdependencies, gates, handoffs, and next state.
5. **ORBIT** applies whenever an AI agent is proposed: objective, risk, permissions, tools, tests, transfer, kill, and termination.
6. **Human confirmation** releases only the permitted next state. A prepared artifact is not an authorized action.
7. **Evaluation and receipt** compare results with the objective, reconcile official actions, record lessons, expire temporary grants, and feed the next Assess stage.

The effective decision is always the most restrictive result across CHART, EDENA, active-hat authority, data policy, agent permission, destination policy, edition, and institutional controls.

## 2. CHART — authority, data, and action gate

Run CHART before an agent route, consequential artifact-state change, external handoff, tool request, export, or persistent storage of newly classified information.

1. **C — Context, constituency, and consequence:** exact entity/site/service, active hat, affected people, urgency, intended outcome, and plausible downside.
2. **H — Human authority and accountable owner:** delegated decision right, named decision owner, approver, executor, affected governance body, source, and expiry.
3. **A — Authorization, access, agreements, and approved action:** data class, platform, agreements, sources, reads, writes, destination, and current action state.
4. **R — Regulation, risk, resources, and records:** current official/local sources, clinical/workforce/financial/security risks, assumptions, resources, segregation of duties, and official record route.
5. **T — Trace, test, transition, expiry, and termination:** evidence, preview, test, human release, acknowledgment, contingency, receipt, review, expiry, rollback, purge, and removal.

CHART returns one of four closed states:

| State | Application behavior |
|---|---|
| `Pass` | Preparation may continue within the remaining EDENA, permission, data, and destination controls. It never grants the underlying authority. |
| `Question` | Pause the transition, display missing or conflicting fields, and route to a named human clarification queue. |
| `Block` | Prevent the transition and create a minimal nonsensitive denial receipt. |
| `Emergency Stop & Official Route` | Stop STEWARD processing and direct the user to the applicable official emergency or real-time procedure. It does not bypass a control. |

All five dimensions must be current, consistent, and evidenced for a Pass. A title, clinical license, committee membership, seniority, system access, or dashboard visibility is never sufficient evidence of authority.

## 3. ALIGN — human-owned organizational orchestration

Use ALIGN to structure work that spans people, functions, resources, or official systems:

1. **A — Aim and affected people**
2. **L — Leadership and decision accountability**
3. **I — Interdependencies, inputs, and official systems**
4. **G — Gates, governance, contingencies, and communication**
5. **N — Next state, named receiver, closed loop, and expiry**

Every ALIGN handoff requires a named human sender and receiver, an artifact state, purpose, decision requested, due/review date, acknowledgment state, and official-system route. Delivery or AI status never counts as human acknowledgment or transfer of responsibility.

ALIGN must not become a shadow EHR, HRIS, scheduling platform, finance ledger, claims or contract system, incident system, credentialing system, security console, or board record.

## 4. ORBIT — governed agent lifecycle

Apply ORBIT before every agent preview or run:

1. **O — Objective and owner:** one narrow objective, beneficiary, affected people, and non-goals.
2. **R — Role, risk, and responsibility:** EDENA tier, rights impact, prohibited decisions, human release owner, and segregation of duties.
3. **B — Boundaries and budget:** data, sources, tools, destinations, time/cost limits, retention, expiry, kill, rollback, and purge.
4. **I — Inspect and test:** normal, failure, missing-source, bias, privacy, security, prompt-injection, permission, cost, and recovery tests against a baseline.
5. **T — Transfer or terminate:** named-human review and acknowledgment, one-run release or safe stop, incident handling, retirement, and orphan cleanup.

All ten canonical STEWARD agents install as `PERM-P0 Disabled`. ORBIT does not activate an agent; it produces the evidence required for a separate one-run approval.

## 5. EDENA risk model

Use the following closed values: `unclassified`, `green`, `yellow`, `orange`, and `red`. Classification is required for every mission, artifact, import, export, AI request, tool call, and external handoff. `unclassified` cannot proceed beyond local drafting.

| Tier | Meaning | Minimum response |
|---|---|---|
| **Green** | Low-risk, bounded, reversible work using public, synthetic, or owner-created nonsensitive information | Show normal AI disclosure and source verification; ordinary human review before use |
| **Yellow** | Material professional, organizational, reputational, academic, privacy, or resource implications; uncertainty or stale evidence requires attention | Prominent advisory, named reviewer, explicit review criteria, and confirmation before promotion or handoff |
| **Orange** | High-impact, sensitive, difficult-to-reverse, cross-functional, or institution-dependent work; expert review or formal authorization is required | Restrict to sandbox/recommendation until the required qualified owner and institutional approval are recorded; enhanced evidence, pre-mortem, fallback, and monitoring |
| **Red** | Prohibited, emergency, unlicensed, unauthorized, rights-affecting, production-critical, or otherwise extreme-risk action; or a mandatory-stop condition under institutional policy | Display a high-risk warning and official route; enforce the edition behavior below; never represent the output as approved, validated, authorized, or safe for direct use |

EDENA classifies risk; it does not grant role authority, data access, agent permission, institutional approval, or professional competence. A lower classification cannot override a CHART Block or a prohibited action.

### Personal Edition behavior

- Green and Yellow work may remain in the private sandbox subject to their review requirements.
- Orange work may be explored, simulated, compared, or drafted. Promotion beyond recommendation requires the named qualified review or institutional route shown by the system.
- Red must not be silently suppressed inside the personal sandbox. The user may inspect the concern and explore a clearly labeled hypothetical, simulation, or draft only after deliberate acknowledgment. Connected execution, external release, or claims of approval remain blocked.
- The interface must state that a personal acknowledgment is not institutional authorization, legal review, clinical validation, financial approval, employment authority, or permission to use sensitive data.

### Institutional or Departmental Edition behavior

- Institutional policy, access controls, data agreements, audit requirements, approval paths, and deny rules take precedence over personal preferences.
- Yellow requires the configured reviewer and evidence before promotion.
- Orange is confined to the specifically approved sandbox or workflow until all required functional owners approve the defined next state.
- Red is a mandatory stop. Execution remains blocked until the exact required authorization, policy validation, qualified review, or escalation is recorded. A categorically prohibited `PERM-P5` action remains blocked even if someone asks to approve it.
- Unsupported enforcement, logging, kill, purge, or review capability is a blocker, not a warning.

## 6. Artifact and action states

Keep the following states visibly distinct:

1. `Exploration`
2. `Simulation`
3. `Recommendation`
4. `Draft Artifact`
5. `Approved Plan`
6. `Authorized Execution`
7. `Completed Action`
8. `Evaluated Outcome`

Do not permit arbitrary state jumps. Promotion requires completed prior-stage evidence, a current governance classification, and the designated human checkpoint. Changes to facts, scope, data class, active hat, EDENA tier, intervention, owner, destination, or success measure must invalidate downstream approvals and reopen the appropriate stage.

`Approved Plan` means a named human approved the plan within their verified authority. `Authorized Execution` additionally requires the destination, executor, time window, fallback, and action-specific approval. `Completed Action` must be reconciled with the official system or named human. `Evaluated Outcome` requires comparison with the original measures and a decision to sustain, revise, escalate, stop, or begin another cycle.

## 7. Private Administrator OS — default boundary

Private mode may accept only:

- the operator's minimum professional identity and authority metadata: exact title, active hat, entity/site, written authority source, decision boundary, named human routes, and expiry;
- public information;
- unmistakably synthetic examples;
- administrator-created nonsensitive notes and generic process maps;
- reviewed derived Mission Profile fields needed for personalization; and
- whole-life categories only in a technically separate, personally controlled store.

Private mode must reject or prevent entry of:

- PHI or patient-level data, images, identifiers, narratives, or small-cell aggregates that could expose individuals;
- employee, applicant, practitioner, volunteer, learner, credentialing, performance, disciplinary, accommodation, labor, or personnel-file data about another person;
- sensitive records about the operator's own employment;
- real incident, safety-event, complaint, grievance, claim, coverage, billing, coding, or patient-account details;
- vendor-confidential, contract-confidential, procurement-confidential, trade-secret, or negotiation content;
- passwords, tokens, secrets, vulnerability details, security-sensitive architecture, access-control data, or production configuration;
- nonpublic financial data, bank or account numbers, transaction records, or payroll records;
- privileged legal communications, board-confidential records, research participant data, or regulated institutional records; and
- any content whose classification, ownership, authorization, or de-identification is unknown.

User self-redaction does not establish compliant de-identification. When unsafe content is detected, do not echo it in alerts, logs, receipts, analytics, or support bundles. Provide a minimal warning, preserve no more than necessary to record the blocked event, and direct the user to the approved institutional route.

## 8. Institution-approved partition

Institutional use requires a separate, exact authorization record for:

- legal entity, site, service, and jurisdiction;
- platform, vendor, model, deployment, and contract;
- purpose, users, roles, active hats, and delegated authority;
- allowed data classes, sources, fields, volumes, and small-cell rules;
- read, write, tool, connector, destination, and network permissions;
- encryption, key management, authentication, authorization, and secrets handling;
- logging, audit access, retention, deletion, legal hold, and correction;
- monitoring, validation, incident response, downtime, manual fallback, kill, rollback, and retirement;
- clinical, HR, finance, compliance, privacy, security, legal, procurement, quality, research, executive, and community owners as applicable; and
- approval source, effective date, expiry, renewal, and revocation.

The base STEWARD application remains aggregate- and process-level even in an institution-approved partition. Patient-, encounter-, event-, claim-, employee-, applicant-, practitioner-, credential-, and individual-performance rows or narratives require a separate purpose-built governed module, schemas, tests, release ledger, and human approval. Do not unlock them through a feature flag or prompt.

Never join private, institutional, whole-life, workforce, finance, quality, security, legal, research, or agent-control partitions by default. A display filter is not technical separation.

## 9. Prohibited decisions and actions

STEWARD must never autonomously make, recommend as an authoritative determination, or execute:

- clinical diagnosis, treatment, triage, device, medication, discharge, transfer, or patient-communication decisions;
- real-time bed, flow, emergency, staffing, scheduling, assignment, or command decisions;
- hiring, applicant screening, performance evaluation, discipline, termination, compensation, accommodation, credentialing, or privileging decisions;
- individual workforce scoring, surveillance, retaliation prediction, protected-class inference, or hidden ranking;
- payment, price, coding, billing, claim, coverage, ledger, payroll, or bank transactions;
- vendor selection, contract interpretation or signature, purchase orders, procurement commitments, or public promises;
- legal, compliance, reportability, accreditation, audit-sufficiency, tax, fiduciary, or regulatory applicability conclusions;
- identity/access changes, vulnerability exploitation, production configuration, security authorization, or emergency command;
- external sending, scheduling, publishing, filing, submission, public release, or official-record creation without a separately governed human action path; or
- self-expanding agents, hidden persistence, recursive delegation, permission escalation, self-approval, or suppression of incidents and dissent.

The application may help prepare bounded drafts and questions in permitted contexts. It must label them accurately and identify the responsible human and official route.

## 10. Uniform enforcement surfaces

Invoke the same policy service at all of these boundaries:

- first-run onboarding and Mission Profile derivation;
- role/hat selection and dashboard switching;
- mission, project, task, note, decision, metric, and reflection forms;
- quick capture, clipboard paste, drag-and-drop, file upload, and attachment extraction;
- Discover Packet, Soul Profile, mission, evidence, configuration, and backup import;
- search, indexing, embeddings, retrieval, citation storage, and knowledge-base ingestion;
- AI prompts, agent context assembly, model responses, and tool arguments/results;
- Hermes handoffs, agent overrides, connectors, web requests, and external destinations;
- artifact promotion, approval, execution, completion, evaluation, and reopening;
- report, PDF, Markdown, JSON, citation, backup, and support-bundle export;
- dashboards, notifications, analytics, badge evidence, audit logs, telemetry, and error reporting;
- API, background worker, scheduled job, browser session, and administrative endpoints; and
- deletion, purge, rollback, migration, update, and uninstall.

Client-side validation improves usability but is not an enforcement boundary. Re-run governance and data validation on the trusted local server for every state-changing request. Imports must be parsed as data, never executed; reject unknown fields, schema drift, path traversal, active content, oversized payloads, malformed archives, and cross-partition references.

## 11. Evidence, sources, and truthful communication

Every material claim must be labeled as one of: verified fact, user-provided information, reported claim, human interpretation, AI-generated draft, assumption, or unresolved question.

Record exact source title, publisher, canonical reference, version/date, retrieved date, status, claim supported, applicability, exclusions, local override, reviewer, and expiry. Retrieved content without a valid source is not evidence. A citation link is not proof that the claim is supported. Never fabricate a source, citation, quote, consensus, requirement, metric, target, approval, testimonial, or official outcome.

External and executive-facing drafts must preserve the accountable human's voice. Remove filler, fake warmth, invented urgency, vague “transformative” claims, unsupported superlatives, and anthropomorphic AI claims. Keep owner, action, date, status, source, uncertainty, dissent, accessibility needs, and next human step.

## 12. Human approvals and separation of duties

Require deliberate human confirmation before any consequential, destructive, external, sensitive, employment-related, financial, legal, institutional, or low-reversibility transition. The approval card must show exactly what will happen, what data and destination are involved, who requested/approved/executes, EDENA and CHART results, cost/time limits, rollback limits, and the official reconciliation step.

The requester, approver, executor, reviewer, and auditor must remain distinct where organizational policy requires separation. No AI may fill a legally or organizationally required human role. Absence of a qualified approver blocks the transition.

## 13. Receipts, audit, and privacy

Create append-only receipts for classification, denial, approval, import, export, agent run, tool use, promotion, execution, acknowledgment, correction, pause, kill, rollback, purge, reset, removal, migration, and uninstall.

Each receipt records IDs, versions, active hat, authority source/expiry, partition, data classes, CHART state, EDENA tier/reason, permission, requested transition, human approvals, before/after hashes, result, timestamp, expiry, and recovery references. Store sensitive payloads only in their authorized record location; audit indexes should use IDs, classifications, and hashes rather than copied content.

Receipts prove application events, not institutional approval, compliance, clinical validity, legal sufficiency, accreditation, security authorization, or real-world success.

## 14. Pause, kill, rollback, purge, and uninstall

- **Pause All:** immediately deny new model calls, tools, connectors, agent runs, external actions, and background jobs. Local manual drafting may continue with a visible paused state.
- **Kill:** stop the selected agent or all agents, cancel streams and jobs, revoke temporary credentials and tool grants, close sessions, purge ephemeral state, detect orphans, and produce a verified result.
- **Safe Reset:** return every power to `Available Inactive`, every agent to `PERM-P0 Disabled`, connectors/actions Off, and transient state cleared without silently deleting user-owned artifacts.
- **Rollback:** restore a verified configuration or local artifact snapshot with a before/after receipt. It never claims to reverse an email, publication, payment, official-system change, or other real-world action; those require human reconciliation.
- **Purge:** delete temporary prompts, retrieved chunks, caches, embeddings, staged uploads, temporary credentials, and agent scratch state according to policy, then verify deletion or report failure.
- **Remove/Uninstall:** preview dependencies and export choices, require confirmation, stop and revoke all activity, preserve only explicitly selected permitted artifacts, remove application data/configuration, verify orphan cleanup, and provide a human-readable completion report.

Failure to confirm stop, revocation, purge, rollback, or orphan cleanup must be reported as `partial`, `failed`, `blocked`, or `unsupported`—never as success.

## 15. Secrets, transport, and backend boundaries

- Store model and connector secrets only in server-side secret storage; never in browser storage, exported profiles, backups, logs, or client bundles.
- Allow unencrypted HTTP only for verified loopback addresses. Remote backends require approved TLS and authentication.
- Bind the local server to loopback by default and protect state-changing routes against cross-origin requests and request forgery.
- Verify backend health, identity, capabilities, model, streaming, tool support, and authorization before enabling AI controls.
- Capability drift, certificate/authentication failure, unexpected model/provider change, or unavailable governance probes disables the affected AI path without disabling local core work.
- Memory is explicit, consent-controlled, inspectable, correctable, exportable, and deletable. “Do Not Remember” categories must be enforced before prompt assembly and persistence.

## 16. Required verification

Tests must demonstrate at minimum:

1. CHART returns only the four defined states and blocks incomplete consequential transitions;
2. EDENA is required on every governed artifact and uses the correct Personal versus Institutional behavior;
3. Red personal exploration remains labeled and sandboxed while connected execution stays blocked;
4. Red institutional work stops until the configured authorization path is satisfied, and P5 remains prohibited;
5. changing scope, data, hat, risk, plan, owner, or destination invalidates downstream approvals;
6. prohibited data is intercepted across forms, imports, files, retrieval, prompts, tool calls, exports, backups, logs, and badges without unsafe echo;
7. cross-partition references and hidden joins fail closed;
8. all agents remain P0 until a valid ORBIT charter and one-run approval exist;
9. external and consequential actions cannot occur from a draft or recommendation state;
10. Pause All, Kill, Safe Reset, rollback, purge, expiry, delete, and uninstall work across UI and server paths and leave no orphan activity;
11. logs and receipts are useful without copying sensitive payloads;
12. offline mode remains functional and never presents simulated AI, tool, citation, approval, or governance events;
13. keyboard and screen-reader users receive the same classifications, warnings, approval detail, stop controls, and recovery status; and
14. every critical failed, blocked, or unsupported enforcement test prevents activation.

The release is not complete if a control exists only as text, a disabled-looking button, a client-side check, or a test that never exercises the production path.
