Project Input Schema
Definition
Project Input Schema is the project-managed contract for future cases. It declares the primary input architecture, optional structured-input schema, named case-material fields, and artifact families or file extensions the project accepts.
The active architectures are plain text, chat, and structured. The schema is a project singleton rather than a versioned benchmark object. When no setting exists, the default accepts one plain-text user message and no case materials or artifacts.
Fields, states, or lifecycle rules
architectureisplain_text,chat, orstructured.- Structured architecture requires a bounded
structuredInputSchema. caseMaterialSchemais a closed, flat object. Each material key has a label, optional description, required flag, type, and any accepted artifact rules.- Material keys use lowercase letters, digits, and underscores, start with a letter, and remain flat.
acceptedArtifactsdeclares project-level artifact families. Supported families are image, document, tabular, presentation, source text, and audio.- A case-material artifact rule must be a subset of the artifact families admitted at the project root.
- Saving a new schema governs future case validation. Operators should inspect existing cases before making a change that would make current content invalid.
Canonical case content
The primary case payload is content.input. Optional supporting values and artifacts live in content.case_materials. The product renders record_content.case_view so people and execution adapters can inspect the canonical content consistently; that view is a projection rather than an alternate authoring contract.
Static support passed to a Harness uses case_material_refs. An executable or queryable environment uses an optional world_instance_ref. Do not collapse static documents, images, or values into the world boundary merely because a candidate consumes them during a Run.
Worked example
Example: structured support case
A project selects structured input with question and customer_tier properties. It declares a required policy_document case material that accepts PDF documents and an optional account_history tabular material. A case is valid only when its structured input matches the schema and the required document is present in the accepted format.
Source confidence
Code-backed: the active settings route and backend validator define the input architectures, closed case-material schema, artifact families, defaults, and canonical case paths. This page explains the product contract without presenting internal handlers as a public API.