Security And Deployment

What exists today

The product includes the following controls and workflow boundaries:

• server-side lots and snapshots instead of browser-only local state
• version lineage so saved analyses, proposals, and notebooks have ancestry
• account roles, shared-space access, and share links as separate access concepts
• read-only share links for saved-work review
• archived and controlled lifecycle states for saved work
• built-in alert rules and alert incidents evaluated after ingest
• SQL scope propagation from Analyze so the same selected population and what-if limits carry through
• an application API behind ingest, analytics, saved work, alerts, and SQL
• bearer-token authentication for API routes, including service-account API access
• fixed-window rate limiting on health, analytics, SQL, upload, and admin-sensitive routes

Access model

Three access layers matter:

1. account role
2. shared-space access
3. saved-work share link

They are intentionally separate:

• shared spaces are the working collaboration surface
• share links are read-only document access
• controlled analyses, proposals, and notebooks are immutable shareable artifacts

More detail is in Roles And Access.

For the external API surface specifically:

• /health and /health/deployment are unauthenticated at the application layer
• public API routes use bearer authentication
• service-account API keys are still used as bearer-authenticated tokens after issuance
• route access is further limited by ingest, read, or full scope

Health endpoint exposure

GET /health returns process readiness. GET /health/deployment is an unauthenticated reconciliation endpoint used by deployment checks and external monitors. On managed installations its response includes desired and running image identifiers and commit revisions for the frontend, API, worker and Python runner, plus image publication times and deployment status/failure codes. It does not return lot data, credentials or raw deployment logs. An unmanaged installation reports managed: false without component image metadata.

Anyone who can reach the managed endpoint can identify those software builds; it is not protected by an account role or API-key scope. If that metadata must not be public, restrict this route at the deployment’s ingress or network boundary, while allowing the deployment checks and monitors that need it. Such a restriction is an operator configuration, not an application default.

No bearer token is needed by the application for either health endpoint. If an installation’s proxy returns 401/403, ask its operator for the monitoring access procedure. Do not assume ordinary application credentials bypass that boundary. Health status alone does not establish which product fixes a build contains; see checking installed fixes.

Alert evaluation scope

Alert rules evaluate only the newly ingested lot. Supported conditions cover lot final yield, a test’s Cpk, or a bin percentage. Earlier lots are not pooled or used as a historical baseline, and a rule does not require consecutive breaches across a lot window.

The former Lookback lots setting had no effect and is no longer configurable. Existing rules continue to evaluate per ingest. Older clients may omit lookback_lots or send null; supplying a number in an alert-rule create or update request is rejected with an explanation. An update must include at least one supported rule field: an empty request or only {"lookback_lots": null} is rejected before writing the rule or recording an edit in the audit log. Editing a legacy rule clears its unused stored lookback value without otherwise changing its conditions.

Deployment shape

Today, Stratum is a server-side product with a small set of core services:

• application UI
• API
• background worker
• relational storage
• object storage for lot artifacts
• centralized authentication

Contact us for evaluation deployments and pilot setups.

Data and review boundaries

The product keeps engineering review state attached to the data:

• uploaded lot context is stored server-side
• snapshots pin analysis to a specific ingest state
• saved versions preserve the reviewed state over time
• controlled documents let a review become immutable
• share links are read-only rather than collaborative edit sessions

Current trust and deployment scope

A few things are intentionally not available yet:

• no public SOC or similar compliance attestation
• no public pricing page
• no broad notification-channel surface
• Stratum is not presented as a replacement for a mature yield-operations platform

What to ask during evaluation

If you are evaluating, useful trust questions are:

• where will the product be deployed for our pilot?
• what data will be stored server-side?
• who can access shared spaces and saved artifacts?
• how are read-only reviews separated from collaborative work?
• what operational workflows still need an incumbent or internal pipeline beside Stratum?

If you want the route-level summary of the current external integration surface, read API Surface.