socaity-schemas

Shared Pydantic models for APIPod services and their clients. One definition, used on both sides of the wire, so a service and a client never drift apart on field names or shapes.

The groups:

• media_files: FileModel and its typed variants (ImageFileModel, AudioFileModel, VideoFileModel, ThreeDFileModel). The wire shape of a media-toolkit file: name, content type, and content as base64 or URL.
• schemas: OpenAI-compatible request and response models (chat, completion, embedding, image, video, audio, vision, 3D) plus streaming chunks (ChatCompletionChunk).
• transport: provider job envelopes (SocaityJobResponse, RunpodJobResponse, ReplicateJobResponse), their link/metric sub-models, and the StreamingResponse sentinel.
• contract: the machine-readable interface of a deployed service (ServiceContract, Endpoint, parameter models, ServiceAddress variants). contract.specification says how the spec is written (openapi, apipod, cog); it says nothing about where the service runs.
• platform: the socaity catalog domain. AIService is the aggregate root, with Deployment (provider, region, address, contract revision) and AIModel (organization, weights, capabilities, license, benchmark scores) as separate entities. Services and models relate many-to-many through endpoints. platform.workflow is the workflow IR (WorkflowDocument, Node, Edge, constants, annotations, companion WorkflowLayout). Mutations live in socaity-workflows.

from socaity_schemas import ChatCompletionRequest, ServiceContract, AIService, AIModel
from socaity_schemas.contract import RunpodServiceAddress

The schema shape mirrors the OpenAI API so OpenAI-compatible clients work without translation. That is about the wire format only: any provider (Flux, Whisper, ElevenLabs, in-house models) that matches the shape is a valid backend.

Install

pip install socaity-schemas

MIT-licensed.