Own the provider boundary
Use Android → your authenticated backend → TypeSafe. Keep the provider key in server configuration. BuildConfig, resources and native libraries inside an APK are not secret storage. Authenticate callers to your backend, limit input size and request rate, and set timeouts. Do not create an unrestricted proxy that accepts arbitrary provider questions from clients.
Follow the official TypeSafe quickstart for account access and the current request/response contract. As checked on September 28, 2026, it documents a POST to https://api.typesafe.ai/v1/systemone, bearer authentication, and state, model and questions fields. Keep model selection and question definitions on the server. Verify current access and billing in the provider console; the roadmap assumes neither a free key nor unlimited usage.
Define an application contract
This Kotlin sketch is your domain model, not a TypeSafe SDK or a copy of its wire response:
enum class LabAction { SHOW_IN_APP, READ_ALOUD, ASK_USER, IGNORE }
data class LabDecision(
val requestId: String,
val action: LabAction,
val confidence: Double,
val probabilities: Map<LabAction, Double>,
val modelVersion: String,
)
interface DecisionRepository {
suspend fun decide(requestId: String, state: String): LabDecision
}
The backend adapter translates provider fields into this contract. Validate required fields, allowed actions, finite numbers and probability ranges. Check the expected probability keys and normalization using a rounding tolerance appropriate to the documented response. Reject unknown enum values instead of mapping them to an executable default. Preserve provider confidence and choice probabilities as separate fields; they are not interchangeable metrics.
Use a Choice question for the action alternatives. Describe when each alternative applies, including ASK_USER for ambiguity. Treat user text as input data, not as a source of new action names or policy rules. The client should accept only the request ID it currently owns and run its own permission and freshness checks.
Recover without hidden execution
Represent loading, result, timeout, invalid response and unavailable provider explicitly in UI state. Cancelling the caller must prevent local execution even if the backend finishes later. Propagate coroutine cancellation; do not turn it into a success or retry it indefinitely.
A retry can repeat inference, but must not repeat a side effect. Keep execution separate from fetching a decision. Use a request/action identifier to reject duplicate execution, and persist that protection if actions survive process restarts. For the first lab, show a preview and require a tap to execute.
Practice and expected behavior
Implement the repository twice: a fixture adapter and a live backend adapter. Feed it a valid result, an unknown action, missing confidence, an out-of-range probability, a timeout and a late response. Invalid cases must produce a visible non-executing state. Disable network access and verify the existing input is retained for retry.
Inspect the built APK and source configuration for provider credentials. Record one redacted live response with the returned model identifier and the mapping into LabDecision. Do not include keys or private input in the evidence.
Checkpoint: demonstrate that malformed data cannot reach the executor, cancellation suppresses stale results, and replacing the provider adapter would not require rewriting the Compose UI.