Skip to main content

​
From your user to an explainable result

The authoritative flow separates trusted host identity, short-lived participant access, immutable scoring, and internal versus public result views.
Request sequence
1

Prepare a published program

Clone or create all six definition types, validate and publish them, create a version bundle, then create and activate a program in the target environment. Treat the bundle as immutable science.
2

Sync the host user

Your authenticated server upserts a subject using the host’s external ID. The API returns an opaque subject ID; external identity stays in the encrypted vault and never belongs in later URLs.
3

Enroll and create a session

Enroll the opaque subject in the active program and create a participant session. Keep the returned token on an authenticated handoff path, preferably a URL fragment or direct in-memory transfer.
4

Collect consent and evidence

The participant client loads the exact pinned consent notice, records acceptance first, and fetches the authoritative next question. Answers, unknowns, declines, timing, and adaptive selection are append-only evidence.
5

Complete and read the right result

Automatic-release programs return a participant-safe report. Internal staff use the environment-scoped evaluation API for full provenance and EngineTrace. Review-required programs need an owner/admin release decision.
Do not expose an evaluation UUID as report authorization. Owner/admin staff create an expiring share; the viewer exchanges the shr_ token in an Authorization header, and revocation takes effect immediately.

​
Continuous evaluation

For recurring programs, use the tenant-scoped continuous-evaluation namespace to ingest host events, retrieve due questions, submit answers, read current alignment, and inspect drift. Use the organization, app, environment, program, and subject IDs from the same tenant-scoped /v1 workflow. See webhooks for completion and drift delivery.