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
• notebook version lineage so a saved review has ancestry
• account roles, shared-space access, and share links as separate access concepts
• read-only share links for notebook review
• archived and controlled documents for frozen or restricted notebook states
• 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, notebooks, 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. notebook share link

They are intentionally separate:

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

More detail is in Roles And Access.

For the external API surface specifically:

• /health is unauthenticated
• 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

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
• notebook 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 notebook 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.