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. Documented Core Providers
| Provider or category | Role | Current evidence limit |
|---|---|---|
| Vercel | Frontend hosting | Plan, region, contract, and log retention require account evidence |
| Railway | API, worker, PostgreSQL, and Redis hosting | Region, backup, log, and contract settings require account evidence |
| OpenAI | Answer generation, search indexing, and configured enrichment | Retention, training-sharing, residency, and account settings require account evidence |
| S3-compatible storage | Uploaded originals | Active provider, region, encryption, versioning, lifecycle, and deletion require account evidence |
2. Conditional Providers
Conditional integrations can include error monitoring, email, billing, Google Workspace, Microsoft Graph, Dropbox, image tagging, OAuth, and a malware scanner. Code support does not prove that a provider is active in a particular deployment.
3. Deployment-Specific Review
Before institutional use, the approved trust packet must identify active providers, purpose, data categories, region, account controls, contract scope, notice process, retention, and deletion behavior. Public provider documentation does not prove the MARCUS account configuration.