Manifests & Schemas

Everything PsyCloud runs is described by versioned, validated contracts. The two you'll meet most are component manifests (what a component is) and bundle artifacts (what a study is).

Component manifests

A component manifest is a JSON document (schema psycloud.componentManifest.v0.1) that fully declares a component. Manifests live under src/manifests/core/<componentId>/<version>.json and are indexed by componentId@componentVersion. A manifest declares:

• Identity — componentId, componentVersion, and a kind discriminator.
• Params — a JSON Schema (2020-12) for the component's properties, plus defaults, Studio ui hints, and examples.
• Runtime — supported surfaces (dom, canvas2d, webgl) and required capabilities.
• Telemetry — the events the component emits, and (for responses) the canonicalResponse paths to value/rt/accuracy.
• Semantics — roles (e.g. primary_stimulus, response_collector) and the measures it produces.

This is what lets Studio render a property editor, validate your inputs, and know how a component reports data — all from one declaration.

Dynamic values

Component properties aren't limited to static values. A property can be a static value, an expression, or a reference to trial/state data, described by the psycloud.dynamicValue.v0.1 schema. That's the mechanism behind bindings — e.g. a text's content set to trial.word.

Bundle artifacts

A compiled study — a bundle — is a set of artifacts that the runtime, Studio, and the CLI all read:

The design program targets schema design-program@0.1. Because the format is shared, the same artifacts run identically whether authored in Studio or code.

Validation

Manifests carry validation rules, and bundles are checked structurally (psycloud validate) and at preflight before launch. Parameter values are validated against each component's params schema, so errors surface at author time rather than during a participant's session.

Next