# STEWARD Mission Control — Baseline Gap Report

## Decision

The bundled DISCOVER Nurse AI OS Mission Control v2.0.0 is approved as a **visual, interaction, governance-language and state-machine reference** for the STEWARD build. It is not approved as the completed STEWARD runtime and must not be presented as a full-stack application.

The baseline is a genuine offline static application, not merely a screenshot. It provides useful governed mission work in a browser. However, the attached Functional Build Master Prompt requires a local authenticated full-stack system with SQLite, structured offline CRUD, starter records, real backend adapters, genuine streaming, agent routing, consent-controlled memory, evidence retrieval and reproducible installation/testing. Those capabilities do not exist in the baseline.

Until the required implementation and acceptance tests are complete, the accurate readiness statement is:

> **Not operational:** One or more core acceptance criteria failed; the blockers are documented below.

Do not use **Core operational; AI setup pending** for a build that merely rebrands or wraps the static baseline. Several required offline/core capabilities—not only AI—are still absent.

## Inspected sources

### Functional build contract

- Bundled immutable source: `source/original-functional-build-master-prompt.md`
- Pre-assembly workspace source: `upload/01-Mission-Control-Functional-Build-Master-Prompt.md`
- SHA-256: `ce884cfc6345cc93a6baec0852cf44feb44d859234ef1dc2b5ac2138df18ebe2`

### Dashboard baseline

- `source/baseline-application/`
- Original release: `deliverables/DISCOVER-Nurse-AI-OS-Mission-Control-v2.0.0.zip`
- SHA-256: `69a4dd86659b41136ce9ceb2ceb52512ab567637ab0be29fdc6f6ab6573223c1`
- Architecture: static HTML, CSS and first-party JavaScript with an optional read-only Node loopback file server
- Current persistence: browser `localStorage`, filtered by the selected mission retention mode
- Current Hermes integration: reviewed Markdown copy/download and opening Hermes separately

### STEWARD domain corpus

- `source/steward-domain-pack/`
- Original release: `deliverables/STEWARD-Hospital-Clinic-Administrator-Pack.zip`
- SHA-256: `30d44b5372390318ce324d973d854a73a6aa840e889b2f960df4340d58ee2752`
- Contents: administrator foundation, Trust Shield, CHART–ALIGN–ORBIT, seven STEWARD pillars, 24 workflows, 30 templates, ten proposed agent definitions, logical domain schemas and 160 release-assurance criteria

No completed personal Discover Packet or approved derived Soul Quiz result was supplied for this generic product build. The final application must therefore collect minimum safe first-run information and preview a derived Mission Profile. Synthetic examples must remain labeled and must never be silently adopted as personal facts, credentials, authority, organization data or outcomes.

## What is genuinely functional in the baseline

The following behavior is implemented in the current browser application and is suitable for preservation or regression testing.

### Launch and presentation

- macOS, Windows and Linux launch helpers are present.
- A portable direct-HTML mode exists.
- The optional Node server binds to `127.0.0.1:43127` and serves static release files.
- The interface is colorful, responsive and role-aware.
- Existing QA reports record 43 passing DOM/governance assertions and 29 passing browser/visual checks.
- The embedded Guide, privacy, security, update, rollback and uninstall language provide a useful editorial baseline.

### First-run and personalization adapters

- First run displays the required preparation message and a four-step safety walkthrough.
- Safety acknowledgment is required before completing onboarding.
- The Discover Packet adapter validates a strict versioned JSON shape, previews the derived settings and requires an Apply action.
- The derived Soul Profile adapter validates a strict versioned JSON shape, previews changes and supports apply, restore and clear.
- Raw provisional quiz answers are not retained; only derived presentation scores are saved.
- The application supports a neutral shared identity and 17 role recipes.
- Exactly one selected role is maintained as Primary; other roles may be Supporting, Emerging or Contextual.

### Missions and improvement loop

- Users can create, select, edit and delete missions.
- A mission can be marked active, paused, completed or archived through its status field.
- Missions are associated with one role dashboard.
- Each mission contains stateful Assess, Define, Plan, Implement and Evaluate stages.
- A stage cannot be marked reviewed without both working notes and an outcome.
- Stages must be completed in order.
- Material changes to earlier stages reopen affected downstream stages.
- Material role, purpose or EDENA changes clear stale approval attestations and roll artifact maturity backward.
- Artifact states must advance one gate at a time after the first saved revision.
- A new iteration can carry an evaluated lesson into a new Assess stage.
- Session-only missions are excluded from `localStorage`; explicitly retained non-sensitive missions can persist across refresh and browser restarts on the same origin.

### Governance and handoffs

- EDENA Green, Yellow, Orange, Red and Unclassified states are visible.
- Non-Green states require acknowledgment.
- Institutional mode is truthfully labeled as a policy preview rather than tamper-resistant enforcement.
- Red and Orange transitions are restricted according to the local policy rules.
- Simple client-side patterns warn about likely identifiers and secrets.
- Mission-stage and workflow handoffs generate reviewable Markdown locally.
- Copy or Download is explicitly distinguished from Send or Execute.
- The application does not make hidden network calls or fabricate an AI response.
- A loopback or HTTPS Hermes address can be opened separately without putting the prompt in the URL.

### Capabilities and backup

- Users can add and delete sanitized capability evidence.
- Duplicate evidence does not manufacture progress.
- Badge progress is recalculated from saved evidence and evaluated missions.
- Four developmental levels are shown without claiming credentials or authority.
- A development report can be downloaded.
- The dashboard profile can be exported to JSON and restored through strict schema and semantic validation.
- Synthetic sample missions are excluded from exported achievement evidence.

## Important limitations inside otherwise functional areas

- Mission archive and restoration use an editable status rather than a dedicated archive view, restore command or soft-delete recovery workflow.
- Mission search, filter and user-selectable sort controls are absent.
- All selected role workspaces share one browser-storage origin; their opaque dashboard IDs are organizational labels, not a security partition.
- The browser state is unencrypted, capacity-limited and specific to one browser profile and origin.
- Direct-file and loopback-server modes create different storage origins and can create divergent copies of the user's state.
- The first-run progress display advances through fixed walkthrough steps; it does not report dependency installation, migration, model detection or indexing work.
- The 30 baseline template cards are informational. They do not instantiate structured, editable artifacts.
- Capability evidence supports Add and Delete but not a complete edit, correction, review-expiry or revocation workflow.
- Pattern matching is intentionally incomplete and cannot be treated as de-identification, DLP, malware scanning or institutional privacy control.
- Client-side governance can be modified through browser developer tools and cannot enforce institutional authorization.

## Full-stack gaps and required implementation

### 1. Structured offline work management

**Baseline:** One mission record contains a title, outcome, governance metadata and free-text stage fields.

**Missing:**

- project CRUD;
- structured goals, milestones, tasks, subtasks, owners, priorities and due dates;
- baseline and target measures;
- reviews and review cadence;
- independent notes, decisions, assumptions, risks and safeguards;
- references and attachment metadata;
- activity history suitable for user inspection;
- duplication, archive browser, restore and soft-delete recovery;
- mission/project/task search, filter and sort; and
- valid cross-record relationships and deletion behavior.

**Required:** Implement server-validated repositories and UI controls for these entities. Every core operation must work without AI.

### 2. Durable database and migrations

**Baseline:** `localStorage`; no database or transaction layer.

**Missing:**

- SQLite database;
- foreign keys and transactions;
- schema migrations and migration checksums;
- idempotent seeds;
- interrupted-write and failed-migration recovery;
- stable application/data paths;
- atomic export/restore; and
- backup before compatibility-changing migration.

**Required:** Implement the persistent model in `STEWARD-Architecture-and-Data-Model.md`. Browser storage may retain ephemeral UI preferences only and must not be the source of truth for durable records.

### 3. Starter-content lifecycle

**Baseline:** A user can manually load one synthetic evidence-huddle sample.

**Missing:**

- automatic per-role starter mission after approved onboarding;
- an editable first five-stage cycle;
- Start Here and Hermes connection checklists;
- `Starter content` labeling on every seeded record;
- Adopt, Clear and Restore controls;
- idempotent seed versioning; and
- exclusion from operational analytics and badges until adoption and later real completion.

**Required:** Seed safe STEWARD-specific starter content with stable keys. Never overwrite an adopted or real record.

### 4. Mission Profile provenance and consent

**Baseline:** Strict adapters provide preview and Apply/Clear behavior.

**Missing:**

- field-level original-source reference;
- derived value and uncertainty;
- approval/rejection state per field;
- approval and update timestamps;
- user editing and regeneration before approval;
- profile version history; and
- complete profile deletion with audit receipt.

**Required:** Keep the Mission Profile separate from Hermes `SOUL.md`. Never copy the raw Soul or raw quiz/interview answers into the application database.

### 5. Authentication and secret management

**Baseline:** No account, authentication or server secrets. The static server accepts only GET and HEAD.

**Missing:**

- secure first-run local credential creation;
- password-verifier storage;
- authenticated sessions;
- rotating `HttpOnly`, `SameSite=Strict` cookies;
- CSRF protection;
- Origin and Host validation;
- request-size and rate limits;
- session expiry and revocation;
- server-side provider secrets; and
- `.env.example`-driven configuration.

**Required:** Bind to loopback by default. Do not expose credentials, API keys, raw Soul data or secret-bearing errors to the browser, logs, URLs, exports or source control.

### 6. AI backend and genuine streaming

**Baseline:** No AI request path. The Content Security Policy explicitly contains `connect-src 'none'`.

**Missing:**

- provider-neutral `AIBackend` contract;
- authenticated Hermes health and capability discovery;
- model discovery;
- Hermes session create/resume;
- optional OpenAI-compatible adapter;
- genuine incremental streaming;
- typed tool-progress events;
- Stop/cancel propagation;
- retry and reconnection;
- structured errors; and
- usage metadata.

**Required:** Add a same-origin authenticated server proxy. Do not put provider keys in client code. The UI must show Setup Required or Offline when no real backend passes health checks and must never substitute canned output.

### 7. Agent Console and routing

**Baseline:** Workflows generate manual handoffs; agents are accurately described as disabled.

**Missing:**

- executable, frozen profiles for AGT-01 through AGT-10;
- deterministic routing with explainable reasons;
- selected-agent indicator and user override;
- actual instruction changes when the agent changes;
- independent sessions where needed;
- permission, tool, data and destination boundaries;
- approval queue;
- time and cost limits;
- Stop, Kill, rollback, purge and retirement state; and
- per-turn routing and tool-event records.

**Required:** Install every agent as `PERM-P0 Disabled`. Catalog visibility or UI selection must never grant permission. Agent 10 must remain a separate control-plane auditor and cannot approve itself or other agents.

### 8. Consent-controlled memory

**Baseline:** Application state is saved as a whole; there is no memory-item model.

**Missing:**

- per-item Remember control;
- explicit consent;
- source, purpose, creation time, retention and expiry;
- view, edit, forget, delete and export;
- temporary/durable separation;
- Hermes memory integration when enabled; and
- enforcement of prohibited memory categories.

**Required:** Default conversational/model memory to session-only. Save only minimum, approved structured memory. Never save secrets, PHI, patient-level information, other-person personnel data or the prohibited STEWARD categories.

### 9. Evidence retrieval and citations

**Baseline:** Users can document capability evidence manually. No source retrieval occurs.

**Missing:**

- evidence-source records;
- authenticated retrieval capability checks;
- source title, author/publisher, date/status, URL/identifier and retrieval time;
- claim records and claim-to-source links;
- appraisal/confidence and freshness;
- verification queue;
- URL and redirect validation;
- citation export; and
- prompt-injection isolation for retrieved content.

**Required:** Render citations only after real retrieval and validation. Unsupported claims remain provisional. Retrieved material is untrusted data and can never modify governance or permissions.

### 10. Setup and diagnostics

**Baseline:** `/health` reports only static product/version information.

**Missing:**

- database and migration status;
- authentication status;
- configured backend and recent authenticated health result;
- active Hermes profile and safe Soul-loaded status;
- model, streaming, session, memory, tool and retrieval capability states;
- last successful connection and redacted error;
- backup readiness; and
- actionable diagnostic command.

**Required:** Derive Connected, Connecting, Setup Required, Offline, Authentication Failed, Hermes Unavailable, Provider Unavailable, Limited Capabilities and Reconnecting from real checks—not timers.

### 11. STEWARD schemas and institutional safeguards

**Baseline:** STEWARD describes 18 logical domain schemas and extensive constraints in Markdown.

**Missing:**

- compiled JSON Schema Draft 2020-12 files;
- executable validation fixtures;
- SQLite representation and migration bindings;
- protected schema hashes;
- partition/ACL enforcement;
- current authority/active-hat enforcement; and
- server-side uniform EDENA and CHART–ALIGN–ORBIT policy.

**Required:** Validate create, import, update, export and migration paths on the server. Unknown authority, partition, data class, owner, expiry or destination must fail closed for consequential transitions.

### 12. Packaging and reproducibility

**Baseline:** The static release has no dependency manifest or build step. Its QA scripts live outside the release and depend on externally provisioned modules.

**Missing:**

- `package.json` and lockfile;
- reproducible development and production commands;
- database initialization/migration/seed commands;
- locked automated test dependencies;
- clean-machine installation evidence per supported OS;
- full backup/update/rollback commands;
- executable control-completeness audit; and
- genuine Hermes end-to-end evidence.

**Required:** Bundle source, migrations, tests, scripts, guides, SBOM, manifest and checksums. Do not claim an operating system or AI path as tested without recorded evidence.

## Baseline source reuse map

| Baseline item | Reuse decision | Required treatment |
|---|---|---|
| `index.html` | Reuse as information-architecture and copy reference | Split or adapt for authenticated views; retain accessibility and permanent boundaries |
| `assets/styles.css` | Reuse strongly | Preserve color system, responsiveness, focus treatment and reduced-motion behavior |
| `assets/app.js` | Reuse selected logic only | Extract mission transition, adapter-validation and badge rules into testable client/server modules; do not keep one monolith as the server authority |
| `config/mission.schema.json` | Reuse as a migration input | Extend to the structured relational mission model and enforce on the server |
| `config/capability-evidence.schema.json` | Reuse as a migration input | Add edit/correction/revocation/history and server validation |
| `config/discover-packet-input.schema.json` | Reuse | Add field-provenance and approval storage around the approved derived result |
| `config/soul-profile-input.schema.json` | Reuse | Keep derived profile separate from Hermes Soul and never store raw answers |
| `config/edena-policy.json` | Reuse as advisory seed | Replace browser-only enforcement with one server-side policy engine shared by every route and agent |
| `config/role-dashboards.json` | Use as generic reference only | Replace DISCOVER role catalog with STEWARD administrator setting/active-hat workspaces |
| `examples/*.json` | Reuse only as synthetic fixtures | Keep explicit synthetic/demo flags; never seed them as user facts |
| `server.mjs` | Security/reference only | Replace the read-only server with an authenticated full-stack server; retain loopback binding and hardened headers |
| launch scripts | UX reference only | Launch the full-stack server, migrations and browser; do not fall back silently to a separate unauthenticated `file://` data store |
| embedded Guide and safety copy | Reuse editorially | Rewrite product names and add real setup, diagnostics, memory, evidence, agents and recovery instructions |
| release manifest/checksums | Preserve as baseline provenance | Generate new STEWARD manifest and checksums after implementation |
| `base-pack/` | Do not import into active STEWARD build | It is a DISCOVER research/innovation specialization and is not the administrator domain source |
| old DISCOVER Hermes installer | Legacy reference only | It documents manual handoff and must not override the functional build contract |

## STEWARD domain files that control the new product

The following paths are relative to `source/steward-domain-pack/` and are normative after the Functional Build Master Prompt:

- `foundation/Hospital-and-Clinic-Administrator-Life-Leadership-and-Operations-Foundation.md`
- `core/00-Standalone-Hospital-and-Clinic-Administrator-Lane-and-Human-Standard.md`
- `core/01-Administrator-Patient-Workforce-Organization-and-Community-Trust-Shield.md`
- `core/02-STEWARD-CHART-ALIGN-ORBIT-Operating-Core.md`
- `steward/01-S-Set-Strategy-and-Steward-Mission.md`
- `steward/02-T-Transform-Access-Flow-and-Operations.md`
- `steward/03-E-Economics-and-Resources.md`
- `steward/04-W-Workforce-and-Workplace.md`
- `steward/05-A-Assure-Quality-Compliance-and-Equity.md`
- `steward/06-R-Resilience-Risk-and-Readiness.md`
- `steward/07-D-Digital-and-Agent-Governance.md`
- `workflows/My-STEWARD-Hospital-and-Clinic-Administrator-Decision-Center.md`
- `workflows/STEWARD-Workflows-Launch-and-Adoption-Plan.md`
- `workflows/Administrator-Role-Setting-and-Situation-Recipes.md`
- `templates/STEWARD-Cards-and-Templates.md`
- `tests/STEWARD-Release-Assurance.md`
- `manifest.md`

The older one-file STEWARD program and setup material are retained under `source/legacy-reference/`. Their instruction to install directly into Hermes must not compete with or override the functional application build contract.

## Required final implementation inventory

Hermes must create and verify at least:

- client UI modules derived from the baseline;
- authenticated local application server;
- SQLite connection, repositories and forward-only migrations;
- safe idempotent starter seed;
- `.env.example`, `package.json` and lockfile;
- `AIBackend`, Hermes adapter and optional OpenAI-compatible adapter;
- streamed-event, cancellation and session APIs;
- ten frozen bounded agent profiles and deterministic router;
- memory, evidence/citation, badge and audit services;
- compiled STEWARD JSON Schemas and fixtures;
- platform launchers, setup, health, backup, restore and uninstall scripts;
- executable unit, integration, security, accessibility and end-to-end tests;
- completed control-completeness matrix;
- user Guide, technical README, security/privacy checklist, known limitations and production-readiness report; and
- release manifest, SBOM and SHA-256 checksums.

## Release gates

The implementation cannot be handed off as operational until all applicable master-prompt acceptance criteria pass. At minimum, preserve these gates:

1. Clean install and first run create a useful but clearly labeled STEWARD workspace.
2. Mission, project, task, note, decision, measure and review CRUD work with AI offline.
3. SQLite records survive refresh, server restart and computer restart.
4. Starter Adopt, Clear and Restore are idempotent and never overwrite real work.
5. Authentication, CSRF, origin, rate and secret-exposure tests pass.
6. Every visible interactive control has a verified implementation or an accurate disabled reason.
7. A live configured Hermes backend passes health/capability discovery and one genuine streamed response.
8. Stop cancels or truthfully reports inability to confirm cancellation.
9. Agent selection changes actual bounded instructions and produces route metadata.
10. Memory requires consent and can be inspected, edited, forgotten, exported and deleted.
11. Citations come only from retrieved and validated sources.
12. EDENA and CHART–ALIGN–ORBIT behave consistently across screens, APIs and agents.
13. Backup, restore, update, rollback and complete local deletion pass.
14. Supported operating systems have clean-machine evidence.
15. The readiness statement matches the evidence without upgrading blocked or untested criteria.

The accompanying `STEWARD-Control-Completeness-Matrix.csv` starts the required control inventory. Hermes must expand it when implementation reveals additional controls and must not change `required_not_implemented` to an implemented status without naming the code location and a passing verification test.
