Models

Models live in the global registry. Tenant workflows normally use models through assignments, while platform and handler integrations use the direct model routes.

Model and version

A model stores the human-readable name, description, metadata, handlers, optional handler contracts, and status. Each model has one or more versions. Versions have their own metadata and status.

Use a new version when the runnable behavior changes but the model identity should stay stable.

Handlers

Handlers describe how training and inference execute. PIE V2 supports:

• lambda
• ecs_task — value must be <cluster>/<task_definition>, where <cluster> is the ECS cluster short name (no / in the name), and <task_definition> is the task family (or family:revision).
• in_process

Direct handler configuration is part of model registration and update. Consumers who only run assignments usually do not need to inspect handler details.

Handler contracts

Optional handler_contracts describe input and output payloads as JSON Schema Draft 2020-12 documents. When an inference input schema is present, the API can validate direct inference requests before dispatch.

Contracts also drive event-subscription staleness: changing a contract can mark related subscriptions stale so downstream automation does not silently run against incompatible data.

Training and inference

Training and inference are async. Starting either creates a durable job and returns a job_id. Poll the job route for status and output.

Event subscriptions

Event subscriptions chain model work together. A source model event triggers a target model action using either stored input or the previous job output.

Trigger	Target action	Input source	Typical use
training_complete	inference	stored	Re-run inference after retraining.
inference_complete	training	trigger_output	Feed inference output into downstream training.
training_complete	training	trigger_output	Chain training artifacts.
inference_complete	inference	stored or trigger_output	Chain inference models.