This page describes the current engineering posture and explicit limitations. It is not a certification, service commitment, data-processing agreement, authorization for PHI use, or confirmation that customer signup is active. Customer use requires explicit launch activation and compliance with the applicable published policies. Institution-controlled or restricted use may also require a separately approved trust packet and written agreement.
1. Supported Scope
| Use or content | Current status |
|---|---|
| Public, licensed, or user-authored non-PHI documents | Allowed when the user has processing rights |
| Approved internal institutional documents without PHI | Allowed only in an approved workspace |
| Restricted non-PHI material | Default deny; requires information-owner and security/privacy approval |
| PHI, patient identifiers, patient-specific content, credentials, or secrets | Prohibited |
| Patient diagnosis, autonomous clinical decisions, or emergency guidance | Not supported |
2. Three Separate Validity Claims
MARCUS does not collapse trust into a generic claim of AI accuracy. Institutional review must assess:
- security and tenant/project isolation;
- source integrity, authority, and version status; and
- answer support and citation fidelity.
Evidence for one category does not establish the others.
3. Access and Isolation
Cookie-based authentication, role checks, organization/project authorization, and explicit application filters exist in the current system. Application-level authorization is the primary tenant boundary. Database row-level policies provide additional defense only on paths that establish the required claims.
A controlled institutional pilot still requires disposable negative isolation tests, fixed-user role verification, critical browser/API journey proof, and an approved audit report. Do not infer completed institutional isolation assurance from code presence.
4. Encryption and Providers
Public MARCUS endpoints use encrypted transport. The active at-rest encryption mode, key ownership, rotation, object-store settings, regions, contracts, and deployment-specific provider controls require separate account evidence before customer use.
MARCUS uses external model and embedding providers and may send approved document text, retrieved passages, questions, and generated content to those providers. Provider retention, training-sharing, residency, and account-control settings must be stated from verified account evidence, not from a provider's general defaults.
5. Custody, Retention, and Deletion
MARCUS can retain uploaded originals, extracted text and chunks, embeddings, queries, answers, citations, conversations, caches, audit events, analytics, and platform telemetry. A customer-approved retention schedule has not yet been established for the controlled institutional pilot.
Source cleanup exists, but full organization export, end-to-end deletion, provider expiry, derived-data reconciliation, and backup-expiry proof remain pilot gates. MARCUS does not currently promise immediate or complete deletion across every surface.
6. Logging, Monitoring, Recovery, and Incidents
Application audit/query-analytics foundations and platform logs exist. Centralized cross-service search, approved retention, complete event coverage, external alert evidence, and customer audit reporting are not yet institutionally approved.
Backup/restore tooling and monitoring acceptance runbooks are preparation only. A real restore drill, measured recovery objectives, named incident/support owners, notification terms, and a staged incident exercise remain required before an external institutional pilot.
7. Assurance Limit
MARCUS has not recorded SOC 2, HITRUST, or an equivalent security certification for customer use. Current repository tests and point-in-time health checks are engineering evidence, not independent certification, continuous availability evidence, or institutional authorization.