Packaging
- Python Package: Published via internal PyPI mirror; install with `pipx` or virtualenv.
- Container Image: Optional Docker image encapsulates CLI and runtime dependencies for Airflow/Kubernetes use cases.
- Versioning: Manifests embed SHA-256 digests to track which build produced each run.
Container Hardening
- Non-root runtime: Each container executes as an unprivileged user with only the binaries required to score.
- Read-only filesystem: Layers mount read-only with ephemeral scratch space, limiting drift and simplifying audits.
- Resource envelopes: Memory and CPU limits align with Snowflake Container Services quotas to prevent noisy-neighbor scenarios.
Environment Configuration
| Variable | Description | Example |
|---|---|---|
| `HCC_SCORER_URL` | Base URL for the remote Node scoring service. | `https://scoring.launchhealth.io` |
| `HCC_SCORER_API_KEY` | Bearer token passed to the remote scorer. | `env var / secrets manager` |
| `SCORING_IMAGE` | Docker image name when running local container scoring (optional). | `ghcr.io/launch/hcc-scorer:latest` |
Health & Telemetry
- Snowflake views: `SCORE_SERVICE_HEALTH()` and `SYSTEM$GET_SERVICE_STATUS()` expose container health from inside the account.
- Last run snapshots: Query `SCORE_LOG` (or surface via dashboards) to display the most recent successful execution and latency.
- HTTP endpoints: `GET /health` and `GET /info` mirror the Snowflake functions, making external monitors trivial to wire in.
Integration with Snowflake
The CLI complements existing Snowflake integrations: manifests define extraction queries executed via JDBC with pushdown filters, while scoring outputs can be written back to Launch’s Snowflake environments or exported for downstream systems.
Use the same styling, typography, and color palette as the existing scoring portal so analysts feel at home switching between UIs and the CLI documentation.