This page is for the platform and security team evaluating Claimwell. It says what runs where, what data moves between which components, what can leave your network and under whose control, who operates what, and how the package is deployed. If a question is not answered here, ask it and we will add the answer.
Deployed from a Terraform module into an account you own. Private subnets, one TLS ingress for the workbench, no inbound access from us.
Open-weight models served by vLLM inside the VPC. Model traffic never leaves your network unless you enable a frontier route through your own provider account.
A named Claimwell team runs the agents: monitoring, evaluation on every release, incidents, model updates, statutory parameters. They reach the system through your identity provider with scoped roles, and every action they take is in your audit log. No data is exported to us and your claims are never used to train anything.
Every constraint check, model call, write, and human signature, with inputs and versions. Not editable through the API by anyone, including us.
One service identity per adapter, scoped to the endpoints that adapter needs. The Mail Room cannot write status. Nothing can write a decision without a human record.
Every managed service has an open equivalent in the compose stack. Leaving a cloud is a Terraform module, not a migration project.
Everything below runs inside your VPC. The only two arrows that can cross its boundary are marked, and both are off by default.
Scan batches, fax inbox, mailbox, portal uploads, employer feeds, call notes. Read by the Mail Room from drop points you control. Originals stay where they are.
Render, OCR, classify, extract. Page images and extraction payloads stored in your object store with your keys.
vLLM on your GPU nodes. Prompts and outputs logged to your audit store. Optional egress 1: a per-task-class route to Amazon Bedrock, Vertex AI, or Azure OpenAI through your own provider account, visible in the trace.
Temporal with Postgres persistence. One workflow per claim. Benefit engine, clock service, constraint checker. No external calls.
Reads and writes to your system of record through its API with a scoped service identity. Constraint checker in front of every write.
Read-only adapters to your census feed, plan repository, and licensed guideline table.
Write adapters to your payment rail and correspondence engine. Only from an approved benefit period or a recorded decision.
TLS ingress, your identity provider via OIDC or SAML. Examiner, nurse, and strategy owner roles. Optional egress 2: none. The workbench serves your users only.
S3-compatible, your buckets, your KMS keys, your retention policy. Audit store is append-only and versioned.
| Concern | AWS | Google Cloud | Portability rule |
|---|---|---|---|
| infrastructure as code | Terraform module, your account, your state backend | Terraform module | one module per cloud; nothing cloud-specific outside it |
| compute | EC2 or ECS for the platform; one GPU instance for model serving | Compute Engine or GKE; one GPU VM | containers everywhere; compose stack is the reference |
| object store | S3 with your KMS keys | GCS through the S3 interop API | S3-compatible API only; MinIO in development |
| database | Postgres, container or RDS | Postgres, container or Cloud SQL | plain Postgres, no extensions you cannot run elsewhere |
| secrets | SSM Parameter Store or Secrets Manager | Secret Manager | one secrets interface, adapter per cloud |
| ingress | load balancer with TLS, your certificate | load balancer with TLS | any ingress |
| identity | your IdP via OIDC or SAML | your IdP | no local accounts in production; Claimwell operators are users in your IdP with an operator role |
| model serving | vLLM on a g6-class instance; Bedrock optional | vLLM on a GPU VM; Vertex AI optional | OpenAI-compatible endpoint; swap models by config |
| observability | your CloudWatch, or the bundled Prometheus and Grafana | your Cloud Monitoring, or bundled | OpenTelemetry out; Claimwell operators read it in your account, nothing is exported |
| images | pulled from a registry you mirror; signed; SBOM published per release | no pull from the internet at runtime | |
Azure and on-premises Kubernetes modules are in progress. The Helm chart targets any conformant cluster with an S3-compatible store and a Postgres.
Short answers below. Longer ones, with evidence, in the review packet we provide during evaluation.
We'll return it with the data-flow diagram, the Terraform module, and the review packet.