Technical Sessions

A Technical Session is the persistent boundary for a technical objective, its generated analysis, validated evidence, recommendations, workflows, revisions, and artifacts.

Create a session

POST /v1/tutor is documented as Create a Technical Session. TutorRequest requires query; its tuning fields are optional and intentionally absent from the first integration.

The response model guarantees session_id, answer, flashcards, quiz, videos, lessons_used, and hits. Technical requests can also return optional sources, technical_knowledge, technical_analysis, validated_technical_workflows, and unified_experience.

Retrieve state

• GET /v1/history lists recent sessions owned by the authenticated API-key identity. Source-derived list fields are id, query, subject, created_at, answer_preview, and artifact_count.
• GET /v1/history/{session_id} retrieves current state, validated evidence, citation warnings, available actions, latest workflows, and the unified experience.

These history operations currently lack declared response models, so treat documented fields as stable integration targets and tolerate additive fields.

Revisions and continuation

Session creation writes an initial revision. Workflow actions can write later revisions and artifacts. Firebase-only revision-reading and follow-up routes are not part of the public developer contract. Developer continuation uses Recommend and Continue through POST /v1/history/{session_id}/orchestrate.

Ownership

History and artifact routes verify session ownership using the authenticated identity. Unknown sessions return 404; a session owned by another identity returns 403.