Changelog

Euler publishes customer-facing API and SDK changes from the committed OpenAPI contract at openapi/euler.openapi.json. The current public contract is API v1 with OpenAPI 3.1.0 and package version 0.1.0.

October 2026

The review screen shows everything Euler stores.

• 3D tab, rebuilt. One live scene: an edge-shaded point cloud (in real colour after a 3D rebuild), the current depth as a surface, a smoothed, confidence-coloured camera path with the live video frame on the camera, experimental 3D hands, object centres, a floor grid and axes. Each part has a switch and a strength in the layers rail. Orbit, follow the camera, maximise, fullscreen, save a PNG, record a 15-second turntable.
• Depth tab. Colour ramps with a colourbar in metres, a held or per-frame range, hover distance, a two-point measure, an RGB wipe and overlay, and plain labels for relative depth.
• Sensor streams. The camera’s motion and exposure streams, plus head speed, hand presence and speed and object count, as graphs under the clip on the same playhead, with action lanes and flagged moments. Location and face streams are never shown.
• QC evidence. Every first-person output check shows its measured value against its threshold and your project’s typical band, the certificate row, and thumbnails of the flagged moments that jump the video there. The certificate and the routing decision sit side by side.
• Routing follows the certificate. An episode the certificate places in its review band now goes to Needs review instead of being auto-accepted.
• Honest numbers. Camera path length is reported smoothed, with the raw value kept; the cost preview prices each layer on the hardware it runs on and marks the rates calibrated against real runs.
• Self-serve. The session split and moving a source are in Sources; a run is confirmed with its spend; Re-derive from stored data rebuilds 3D, keeps only the wearer’s hands, cleans up tracks and re-routes review with no GPU; settings that did nothing were removed.
• Look. Light and dark themes on every screen, applied before the page paints, with a colour-blind-safe data palette.
• API. GET .../episodes?fields=summary&page=&page_size=, GET .../episodes/{episode_id}, .../telemetry, .../signals, .../frame and their signed twins, and ?part=trajectory|hands_3d|keyframes|objects on the 3D artifact. See the review routes.

September 2026

One clean clip in the review player.

• Each episode plays one clean clip, and every pose is painted on it live with the frame it belongs to, so skeletons stay on the hands.
• Rendered hand and body pose videos are no longer produced or listed, and the settings that asked for them are gone; old copies can be removed with POST /v1/projects/{id}/media/overlays/purge (a dry run by default).
• Overlay controls moved into the layers rail (switch, solo, strength per layer), which collapses to an icon strip.
• A clip that will not play says why.
• Exports: every export carries a README generated from its own files, readiness receipts and the certificate; model names are withheld; there is no loader script; the annotation bundle carries object outlines and ships embeddings only when asked.
• First-person data: certified against 27 output checks; only the camera wearer’s hands are kept; long recordings can be split into episodes.

Earlier, unversioned

Annotation, readiness, curation and copilot surfaces, live on the hosted API and in the committed contract; the package version has not been bumped.

• Annotation layer catalog. Per-project modes (in_run, on_demand, off), per-layer configuration, scoped presets and a cost preview: GET/PUT /v1/projects/{id}/annotation/settings, PUT /v1/workspaces/{id}/annotation/settings. See annotation layers and pipeline settings.
• Annotation jobs. Heavy layers run through an async queue rather than a synchronous request: POST/GET /v1/projects/{id}/annotation/jobs, an SSE progress feed at /annotation/jobs/stream, plus per-job read and cancel. The existing synchronous per-episode endpoints are unchanged. See annotation jobs.
• Job lifecycle rules. A re-queue over recordings that already carry a layer’s output returns 409 with a structured already_produced detail naming them, unless force: true is sent; partial coverage narrows the job to the recordings that need it. A queued or running job for the same project and layer is returned rather than duplicated. Cancel works from queued and running alike and retains the work already finished.
• Automated review pass. annotation_review runs as a job layer and records a graded verdict per annotation layer, with evidence, improvements and an explicit not-assessable where nothing could be judged. It has no pipeline settings tile because it produces no annotation. See automated review pass.
• Utility and proxy metrics. GET /v1/projects/{id}/utility splits readiness into integrity, semantic quality and utility and reports the proxy metrics under the semantic layer. POST /v1/projects/{id}/ablation compares raw, readiness-filtered and curated subsets by composition. GET /v1/projects/{id}/distribution-gap ranks what the dataset under-covers. None of them claim a training result without a measured probe run. See data utility.
• Project ontology summary. GET/PUT /v1/projects/{id}/ontology/summary reports the classes actually found with their property distributions, joined against what the workspace declared, and accepts renames, merges and declared-class edits.
• Model registry. The registry names what actually runs, and GET /v1/models reports the same.
• Annotation status and coverage. GET /v1/projects/{id}/annotation/status reports what ran per layer; GET /v1/projects/{id}/annotation/coverage reports per-layer, per-kind coverage and the quality signal each layer measured.
• Readiness settings. GET/PUT /v1/projects/{id}/readiness/settings serves the readiness check catalog resolved for a project and stores per-project differences from the defaults. Threshold offsets and weight overrides are clamped. See readiness.
• Curation plans. GET /v1/projects/{id}/curation/strategies, POST /curation/preview, POST /curation/apply and GET /curation/recommend replace the single-move POST /v1/projects/{id}/curate, which still works. See curation.
• Euler Copilot. POST /v1/copilot/chat streams an agentic turn as SSE, with /copilot/models, /copilot/suggestions, /copilot/support and /copilot/threads alongside it. See Euler Copilot.

0.1.0

Initial Phase 2 public integration release.

• Hosted API base: https://api.euler.sudotank.com
• OpenAPI artifact: openapi/euler.openapi.json
• Python SDK package: euler-sdk
• TypeScript SDK package: @sudotank/euler-sdk
• Docs: overview, concepts, API reference, 15-minute quickstart, MCP quickstart, changelog, and migrations

The v1 API covers tenant project/source registration, command-led run planning, episode/export reads, deterministic Ask Euler summaries, and generated SDKs. Transform recipes, chunk bridge plans, and MCP tools are documented as local package or agent surfaces until hosted REST endpoints are explicitly added to the OpenAPI contract. Search and saved slices have since been added as hosted REST endpoints; see the unreleased section above and the API reference.

SDK releases

The sdk-release workflow validates generated artifacts on tag pushes and manual runs:

• uv run python tools/sdk/generate.py --check
• cd sdks/typescript && npm ci && npm run build
• python -m compileall -q sdks/python/src

Publishing is gated by repository secrets. If NPM_TOKEN is unset, npm publish prints Skipping npm publish: NPM_TOKEN is not configured. and exits cleanly. If PYPI_API_TOKEN is unset, PyPI publish prints Skipping PyPI publish: PYPI_API_TOKEN is not configured. and exits cleanly. Non-tag workflow runs also skip publishing.

Compatibility

Euler treats the OpenAPI file as the source of truth for hosted API consumers. Within v1:

• adding optional response fields is backwards compatible;
• adding optional request fields is backwards compatible;
• changing required fields, enum values, authentication behavior, route paths, or response semantics requires a migration guide entry;
• SDK generation drift must be fixed before release.

There is no shipped v2 API yet. Future v2 work must add a dated changelog entry, a migration guide, regenerated SDKs, and release notes before the new contract is advertised.