Teammately Docs
Docs menu

reference

Project Input Schema

Define the canonical input architecture, case-material fields, and accepted artifact formats for project cases.

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

  • architecture is plain_text, chat, or structured.
  • Structured architecture requires a bounded structuredInputSchema.
  • caseMaterialSchema is 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.
  • acceptedArtifacts declares 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.

Found something unclear?

Report outdated, unsupported, or confusing docs so we can fix the source page.

Report a docs issue

Continue learning

Related docs

AI context