# Health Safe Inventory Matrix Phase 6B classifies HealthManager sources structurally before any deeper integration. This document intentionally contains no real Health runtime paths, no patient file names, no document contents, no database rows, no tracker rows, and no report excerpts. ## Access classes - `allowed_metadata_only`: May be used now, but only for existence, bounded counts, `size_bucket`, mtime/freshness, and safe success/failure markers or `status flag` categories. - `future_gate_required`: Potentially useful later, but requires a dedicated safe summary API, sanitizer review, and explicit approval before use. - `blocked`: Not used by the adapter now; may be inspected only as code/documentation, not runtime content. - `forbidden`: Must not be read, parsed, summarized, or surfaced by Jarvis. ## Matrix - Source / area: Health pipeline scripts - Type: script - Access: allowed_metadata_only - Allowed signals: script exists, command availability, last code change class, status marker contract if generated separately - Forbidden signals: medical content, values, file names, paths, raw rows - Risk: Scripts can touch highly sensitive runtime inputs if executed directly. - Rationale: Code/script structure is safe to classify; running domain logic is not safe without a later gate. - Future adapter plan: Use only a dedicated safe status marker or metadata probe, never raw pipeline output. - Source / area: Import and document processing scripts - Type: script - Access: future_gate_required - Allowed signals: script existence and coarse pipeline category only - Forbidden signals: document text, OCR text, extracted fields, file names, paths, links - Risk: These scripts are designed around sensitive source documents. - Rationale: Useful for architecture mapping, unsafe as adapter sources. - Future adapter plan: Require a separate status-only API that emits counts/freshness without source details. - Source / area: Backup and restore scripts - Type: backup - Access: allowed_metadata_only - Allowed signals: backup marker exists, mtime/freshness category, success/failure marker - Forbidden signals: archive paths, archive names, contents, Drive identifiers, links - Risk: Backup artifacts may contain complete protected datasets. - Rationale: Freshness metadata can be safe; contents are forbidden. - Future adapter plan: Add a sanitized backup freshness marker outside protected archives. - Source / area: Cron and sync scripts - Type: cron - Access: allowed_metadata_only - Allowed signals: job script exists, coarse sync category, status marker exists, mtime/freshness category - Forbidden signals: logs, tracker content, mail/Drive content, file names, paths - Risk: Logs and sync outputs can expose content. - Rationale: Scheduling metadata is useful; runtime output is unsafe. - Future adapter plan: Use explicit safe job-result markers only. - Source / area: Dashboard and report generator scripts - Type: dashboard/report - Access: future_gate_required - Allowed signals: generator script exists, generated marker exists, mtime/freshness category - Forbidden signals: report content, summaries, chart data, document lists, values, labels from medical sources - Risk: The generated artifacts are intended for human medical review and can contain protected information. - Rationale: Freshness can be safe; content is forbidden. - Future adapter plan: Introduce a separate redacted build-status marker if needed. - Source / area: Productive health database - Type: db - Access: forbidden - Allowed signals: none through Jarvis adapter in current phases - Forbidden signals: rows, table contents, SQL queries, values, patient events, document references - Risk: Contains protected medical history. - Rationale: Even count queries can become revealing without a reviewed schema policy. - Future adapter plan: Only a separately reviewed safe summary service may read it. - Source / area: Schema-only database files in the code repository - Type: config - Access: blocked - Allowed signals: code review only, not adapter input - Forbidden signals: productive rows or migrations inferred into UI fields - Risk: Schema names can reveal sensitive domain concepts. - Rationale: Useful for developer understanding, not safe as a dashboard contract source. - Future adapter plan: Keep schema review out of runtime adapter. - Source / area: Runtime directory root - Type: runtime_dir - Access: allowed_metadata_only - Allowed signals: exists, bounded count, extension count, latest mtime, freshness category - Forbidden signals: paths, file names, content, links, raw rows - Risk: Directory names and filenames may contain patient context. - Rationale: Metadata-only probing is the current safe maximum. - Future adapter plan: Keep current `local_probe` constraints. - Source / area: Output/report directories - Type: report - Access: future_gate_required - Allowed signals: generated marker exists, freshness category only - Forbidden signals: report body, chart data, file names, links, PDF/HTML/Markdown content - Risk: Reports are high-context medical summaries. - Rationale: Content is not safe for command dashboard surfaces. - Future adapter plan: Add explicit safe report-build marker if required. - Source / area: PDF and OCR artifacts - Type: pdf/ocr - Access: forbidden - Allowed signals: none as direct adapter input - Forbidden signals: text, pages, extracted content, filenames, metadata with patient context - Risk: Primary protected source material. - Rationale: No safe direct use in Jarvis dashboard. - Future adapter plan: Never direct; only via separate reviewed status summary. - Source / area: Tracker exports - Type: export - Access: forbidden - Allowed signals: none as direct adapter input - Forbidden signals: rows, values, text, dates, filenames, source links - Risk: May expose symptoms, nutrition, activity, medication, and biometric context. - Rationale: Raw exports are outside safe status scope. - Future adapter plan: Dedicated aggregate service with medical review, not current adapter. - Source / area: Logs - Type: runtime_dir - Access: blocked - Allowed signals: log marker exists or mtime only if a safe marker is separated from content - Forbidden signals: log lines, stack traces with paths, document names, values, links - Risk: Logs can leak paths and source content. - Rationale: Do not read logs in adapter. - Future adapter plan: Emit explicit safe status files instead of parsing logs. - Source / area: Config examples and README/runbooks - Type: config - Access: allowed_metadata_only - Allowed signals: documented command categories and safe contract notes - Forbidden signals: real local paths, credentials, runtime data, file names - Risk: Documentation can accidentally preserve operational details. - Rationale: Safe for architecture classification when redacted. - Future adapter plan: Keep docs as policy source, not runtime data source. ## Summary classification ### Safe now - Code/script existence and broad category classification. - Local runtime root existence, bounded counts, latest mtime, freshness category. - Explicit safe markers if they contain only status/freshness/count categories. - Backup/sync/pipeline status as categories only. ### Future gated - Report generation status markers. - Pipeline completion markers. - Import audit summaries. - Dedicated safe summary API emitted by HealthManager. ### Forbidden - Productive database rows. - Source documents, PDFs, OCR, reports, tracker exports, raw JSON/CSV. - Drive links, local paths, file names, patient text, values, diagnoses, medications, symptoms, findings. ## Phase 6C bridge classification The Health Safe Status Marker is classified `allowed_metadata_only` only when it conforms to `schemas/health-safe-status-marker.schema.json`. It may carry freshness enums, reachability enum, bounded review count, status enum, and timestamp metadata for the marker itself. Any unknown field, nested value, path, URL, filename, Drive identifier, document title, or medical term moves the input to `forbidden` and the adapter must fail closed.