JSON Schemas

Agent App publishes JSON Schemas so hosts, registries, editors, and CI jobs can validate contracts mechanically.

Public schema files

Schema	Purpose
app-manifest.schema.json	Validates manifest fields from APP.md or app.manifest.json.
app-runtime.schema.json	Validates app.runtime.yaml Agent task runtime contracts and App Server bridge profiles.
app-requirements.schema.json	Validates business requirements, MVP scope, non-goals, and acceptance criteria.
app-boundary.schema.json	Validates App / Host / Cloud / connector / external system / human responsibility boundaries.
app-integrations.schema.json	Validates host/cloud-managed external integration requirements.
app-operations.schema.json	Validates operation side effects, approvals, dry-run, and evidence contracts.
app-install.schema.json	Validates in-Lime, standalone, runtime-backed, and web-host installation contracts plus runtime distribution metadata.
app-fit-report.schema.json	Validates pre-implementation fit reports for business requirements.
app-projection.schema.json	Validates host projection output with provenance.
app-readiness.schema.json	Validates readiness output and setup findings.

When to use schemas

Use schemas in four places:

1. Authoring editors for autocomplete and validation.
2. CI checks before publishing a package.
3. Registry ingestion before accepting a release.
4. Host install flow before projection or readiness.

Schemas do not replace runtime policy. They only validate shape.

Manifest validation

The manifest schema covers fields such as:

• identity and version
• runtime targets
• SDK and capability requirements
• runtime package descriptors
• entries
• UI, storage, services, workflows
• Runtime, UI, Context, Knowledge, Skills, Tools / Connectors, Artifacts, Evidence, Policy, QC, Evals
• permissions, secrets, lifecycle, overlays
• agentRuntime shorthand for task control-plane intent
• requirements, boundary, integrations, and operations shorthands
• install shorthand for in-Lime, standalone, runtime-backed, and web-host install modes
• agentRuntime.bridge profile for App Server JSON-RPC mapping
• presentation and compatibility

Current entry kinds are page, panel, expert-chat, command, workflow, artifact, background-task, and settings.

Projection validation

Projection schema ensures that host-generated catalog objects include app summary, entries, capabilities, storage, services, workflows, requirements, boundary, integrations, operations, and provenance.

Projection should include manifestHash and packageHash so derived objects can be traced back to a release.

Readiness validation

Readiness schema ensures setup checks are machine-readable. A host should produce stable severities, kinds, keys, messages, remediation, and version fields when possible.

Local usage

npm run cli -- validate docs/examples/content-factory-app
npm run cli -- project docs/examples/content-factory-app
npm run cli -- readiness docs/examples/content-factory-app

The reference CLI does not replace a full JSON Schema validator, but it exercises the same contract from the package author's perspective.

Compatibility note

Schemas can be stricter than prose. When prose and schema conflict, treat the schema and CLI behavior as the mechanical contract, then fix the prose.

CI integration pattern

A package repository should run schema and reference checks in this order:

read APP.md
→ validate manifest shape
→ check local referenced files
→ project host catalog output
→ validate projection JSON
→ run readiness against a fixture host profile
→ publish package artifacts only if all required checks pass

The reference CLI covers the shared semantics. A production registry can add a JSON Schema validator, signature verification, malware scanning, license checks, package hash comparison, and tenant policy review.

Schema ownership

File	Owned by	Backward compatibility expectation
Manifest schema	Standard authors and host implementors.	Minor releases should add optional fields only.
Projection schema	Host implementors.	Projection output should stay deterministic for the same package and host profile.
Readiness schema	Host implementors and registry reviewers.	Findings should keep stable kind, severity, and key values.

Failure interpretation

• Schema failure means the document shape is invalid.
• Validation failure means the package cannot be accepted as-is.
• Readiness failure means the package may be valid but cannot run in the current environment.
• Warning means the package is usable for review but should not be treated as production-ready until resolved or accepted.