{
  "schemaVersion": "1.0",
  "title": "AIP JSON Schemas",
  "description": "Use this reference to select an AIP 1.0 schema, reproduce the committed 52-file catalog, validate data at the correct layer, and record enough provenance to identify the exact bytes you used. It is for protocol implementers and release revi",
  "canonical": "https://getaip.org/docs/spec/schemas",
  "route": "/docs/spec/schemas",
  "source": "docs/spec/schemas.md",
  "protocol": "Agent Interoperability Protocol",
  "protocolVersion": "1.0",
  "section": "Protocol Standard",
  "documentType": "Specification reference",
  "language": "en",
  "revision": {
    "lastReviewedRevision": "b598537d7ddd72c85ff1a4a47e554deaa2acf571",
    "documentationSourceRevision": "9192fef3695ad294994f2712f6d156241e5e92fb",
    "basis": "frontmatter"
  },
  "downloads": {
    "md": "/docs/download/spec/schemas.md",
    "txt": "/docs/download/spec/schemas.txt",
    "json": "/docs/download/spec/schemas.json",
    "pdf": "/docs/download/spec/schemas.pdf"
  },
  "content": {
    "format": "text/markdown",
    "markdown": "---\ntitle: AIP JSON Schemas\ndescription: Find, export, validate, and version the 52 normative AIP 1.0 JSON Schemas\nkind: reference\naudience: protocol-implementer\nappliesTo: \"1.x\"\nwritingStandard: \"aip-docs/1.0\"\nlastReviewedRevision: \"b598537d7ddd72c85ff1a4a47e554deaa2acf571\"\n---\n\n# AIP JSON Schemas\n\nUse this reference to select an AIP 1.0 schema, reproduce the committed\n52-file catalog, validate data at the correct layer, and record enough\nprovenance to identify the exact bytes you used. It is for protocol\nimplementers and release reviewers. A schema-valid document is structurally\nvalid; it is not automatically authenticated, authorized, or safe to execute.\n\n## Scope and authority\n\nThe JSON Schemas are the machine-readable half of the\n[AIP 1.0 normative contract](AIP-1.0.md). The prose specification owns\nbehavior, state transitions, security requirements, and conformance. The\nschemas own JSON shape, required members, enum values, body tagging, closed\ntyped objects, and constraints expressible in JSON Schema.\n\n| Property | Reviewed value |\n|---|---|\n| Protocol | AIP `1.0` |\n| Schema dialect | JSON Schema Draft 2020-12 |\n| Normative files | 52 |\n| Source directory | `schemas/aip/` |\n| Stable `$id` prefix | `https://getaip.org/schemas/aip/` |\n| Generated registry | 52 fixed `SchemaName` entries |\n| Reviewed implementation release | Rust workspace `2.0.0` |\n\nA release binds the specification and schema files to an exact source\nrevision. If prose and schema disagree, treat that as a specification defect;\ndo not silently choose a third wire shape. Report which revision, file, and\nrule your implementation followed.\n\nThe committed files are generated artifacts. Change the semantic type or\nregistry owner, regenerate the complete set, review the diff, and commit the\nresult together. Do not hand-edit one exported file as an isolated fix.\n\n## Browse and obtain a schema\n\nChoose the source that matches the claim you need to make.\n\n| Need | Use |\n|---|---|\n| Reproduce the reviewed implementation | `schemas/aip/<file>.schema.json` at the full reviewed commit |\n| Validate with the Rust implementation | The built-in `SchemaRegistry` entry |\n| Inspect every normative filename | [Appendix A of AIP 1.0](AIP-1.0.md#appendix-a-json-schema-registry) |\n| Prepare a release | Regenerate all 52 files and require a clean source diff |\n| Validate offline | Map each stable `$id` to the matching local committed file |\n\nThe `$id` is a logical schema identifier. It does not by itself guarantee that\nan HTTP server exists at that URL. A release or documentation bundle that\noffers downloadable schemas must publish the committed bytes without changing\nformatting, identifiers, or content.\n\nUse the full source revision when reproducibility matters. A mutable branch\nname does not identify a fixed schema set.\n\n## Schema families\n\nThe registry contains ten families. The filenames below are exhaustive for the\nreviewed AIP 1.0 set.\n\n| Family | Count | Files |\n|---|---:|---|\n| Envelope, discovery, and identity | 5 | `envelope`, `manifest`, `manifest_filter`, `capability_contract`, `identity_context` |\n| Actions and streaming | 11 | `action`, `ack`, `stream_chunk`, `action_result`, `action_status_request`, `action_status`, `action_result_request`, `action_list_request`, `action_list`, `action_events_request`, `action_events` |\n| Approvals | 6 | `approval_request`, `approval_decision`, `approval_query_request`, `approval_record_view`, `approval_list_request`, `approval_list` |\n| Sessions | 7 | `session_request`, `session_view`, `session_list_request`, `session_list`, `session_close_request`, `session_resume_request`, `session_resume` |\n| Transactions | 5 | `transaction_plan`, `transaction_request`, `transaction_result`, `transaction_query_request`, `transaction_view` |\n| Resources | 4 | `resource_list_request`, `resource_list`, `resource_read_request`, `resource_read_result` |\n| Callback delivery | 5 | `callback_delivery_policy`, `callback_delivery_query_request`, `callback_delivery_list_request`, `callback_delivery_record`, `callback_delivery_list` |\n| Delegation | 2 | `delegation_request`, `delegation_result` |\n| Receipts and audit | 3 | `receipt_query_request`, `audit_query_request`, `audit_query_result` |\n| Events and channels | 4 | `escalation`, `event`, `event_stream`, `channel_message` |\n| **Total** | **52** | Each base name has the suffix `.schema.json` |\n\nThe envelope schema embeds definitions for all 58 native message variants.\nThat does not turn every message body into a separate top-level schema file.\nThe registry exposes top-level files only for the 52 entries above.\n\n## How schemas are generated\n\nThe reviewed generator follows one deterministic ownership path:\n\n1. `SchemaName` defines the fixed registry and canonical filename for each\n   top-level schema.\n2. `SchemaRegistry::schema` derives a document from the corresponding semantic\n   Rust type with `schemars`.\n3. `annotate_schema` adds the stable `$id` and fixes the envelope\n   `aip_version` member to `1.0`.\n4. `harden_object_schemas` recursively closes typed objects that do not declare\n   an explicit `additionalProperties` policy.\n5. `SchemaRegistry::all` exports the 52 entries in a fixed order.\n6. The CLI serializes each document as pretty JSON into its canonical file.\n\nIf schema generation cannot serialize a derived document, the registry emits\na fail-closed schema containing `not: {}` and a diagnostic comment. It does not\nsilently publish a permissive replacement.\n\nThe generated registry is the code owner; `schemas/aip/` is the committed\nrelease artifact. Both must agree at a release revision.\n\n## Export from source\n\nRun export only from the source revision you intend to document or release.\nFor the reviewed revision, the direct command is:\n\n```sh\ncargo run -q -p getaip-cli -- schema export schemas/aip\n```\n\nThe workspace task runner owns the same operation:\n\n```sh\ncargo run -p xtask -- schema\ngit diff --exit-code -- schemas/aip\n```\n\nThe exporter creates the destination directory and writes every registered\nfile. It does not make an arbitrary output directory authoritative, and it does\nnot prove that no unrelated file is present. A release check must also verify:\n\n- exactly 52 regular `.schema.json` files;\n- the exact registry filenames, with no missing or extra schema;\n- valid JSON and Draft 2020-12 on every file;\n- 52 unique `$id` values with the canonical prefix;\n- byte-for-byte agreement with a fresh export;\n- a clean source diff after generation.\n\nThe reviewed continuous-integration and release workflows regenerate the\ncatalog and fail when `schemas/aip/` differs from the committed result.\n\n## Validate data\n\n### Validate a manifest from the CLI\n\nThe reviewed CLI has a manifest-specific structural validator:\n\n```sh\ncargo run -q -p getaip-cli -- manifest validate path/to/manifest.json\n```\n\nSuccess prints `manifest valid`. This command validates the JSON value against\nthe manifest schema. It does not admit capabilities, bind handlers, or prove\nthat a deployment can execute them.\n\nThe reviewed CLI exposes `schema export`; it does not expose a generic\n`schema validate` subcommand. Use a Draft 2020-12 validator or the registry API\nfor other top-level schemas.\n\n### Validate a named schema in Rust\n\nSelect the registry entry explicitly so a filename typo cannot select a\ndifferent contract.\n\n```rust\nuse aip_schema::{SchemaName, SchemaRegistry};\nuse serde_json::Value;\n\nlet value: Value = serde_json::from_slice(&bytes)?;\nSchemaRegistry::new().validate_json(SchemaName::Action, &value)?;\n```\n\n`validate_json` compiles the generated Draft 2020-12 schema and returns bounded\ndiagnostics when the instance fails.\n\n### Validate a native envelope\n\nFor a typed native envelope, use the combined registry entry point:\n\n```rust\nuse aip_core::Envelope;\nuse aip_schema::SchemaRegistry;\n\nlet envelope: Envelope = serde_json::from_slice(&bytes)?;\nSchemaRegistry::new().validate_envelope(&envelope)?;\n```\n\nThis runs core envelope invariants and then validates the serialized value\nagainst `envelope.schema.json`. A gateway still has additional admission work.\n\n### Interpret validation failures\n\n| Failure class | Meaning | Next check |\n|---|---|---|\n| JSON decode or typed decode | The input is not usable JSON or cannot map to the selected type | Encoding, member names, tags, and value types |\n| Schema compile | The schema is invalid or exceeds compiler safety limits | Dialect, recursion, node count, and text size |\n| Schema validation | The instance violates machine-readable shape | Required members, enums, closed objects, bounds, and body tags |\n| Core validation | A cross-field AIP invariant failed | Type/body match, ids, limits, transaction links, or result requirements |\n| Admission denial | Structurally valid work is not authorized or executable | Identity, replay, manifest, handler, policy, approval, and ownership |\n\nDo not retry an unchanged payload merely because a validator returned several\ndiagnostics. Correct the first owning layer, then validate again.\n\n## Structural, semantic, and admission validation\n\nValidation is layered. Passing a lower layer never skips a higher one.\n\n| Layer | Owner | Examples of what it proves | What it does not prove |\n|---|---|---|---|\n| JSON and typed decoding | JSON parser and semantic types | The payload can be decoded into the selected representation | Schema, identity, or behavior |\n| JSON Schema | `SchemaRegistry::validate_json` | Required members, enums, tags, object closure, and declared bounds | Cross-record state, authentication, or authorization |\n| Core semantic validation | `SchemaRegistry::validate_envelope` | AIP version, type/body match, message id, body-specific cross-field invariants | Trusted caller, replay ownership, or capability availability |\n| Gateway and runtime admission | Auth, discovery, policy, and runtime services | Authenticated identity, replay claim, admitted handler, input contract, idempotency, approval, and durable ownership | External provider success or qualification |\n| Connector/provider execution | Admitted connector and provider | Provider-specific result under the declared operation contract | Universal interoperability or production readiness |\n\nThe following cases require semantic or admission logic:\n\n- transaction ids must agree across the wrapper and action context;\n- a failed result must carry an error;\n- a decision must refer to the stored governed subject;\n- a caller must be authorized to read an otherwise valid resource.\n\nCapability `input_schema` and `output_schema` values are dynamic contracts from\nan admitted manifest. They are validated during action admission and result\nhandling; they are not additional files in the global 52-schema registry.\n\n## IDs, versions, and digests\n\nEvery committed schema has:\n\n- `$schema: https://json-schema.org/draft/2020-12/schema`;\n- one unique `$id` equal to the canonical prefix plus filename;\n- a stable filename owned by `SchemaName`;\n- `additionalProperties: false` at the top-level typed object.\n\nThe envelope schema additionally fixes `aip_version` to `1.0`. Other version\naxes, such as message-family majors, manifest version, and compatibility\nprofile versions, remain independent as defined by AIP 1.0.\n\nA stable `$id` is not a content digest. To identify exact bytes, record the\nfull source revision and a SHA-256 digest for each file or for a published index\nwhose ordering and encoding are defined. For example:\n\n```sh\nshasum -a 256 schemas/aip/*.schema.json\n```\n\nThe reviewed registry does not define a canonical aggregate schema-set digest\nor a documentation asset index. Do not claim one exists. If a publication\npipeline adds an index, it must name the source revision and list exactly 52\nfiles. It must also preserve each `$id`, define ordering, and derive digests\nfrom the committed bytes rather than regenerating from an unrelated working\ntree.\n\nAn incompatible wire change requires the versioning action defined by the\nnormative specification. Reusing an existing `$id` for incompatible bytes is\nnot a substitute for a protocol or message-family version change.\n\n## Closed objects and extension surfaces\n\nThe generator recursively adds `additionalProperties: false` to typed objects\nthat expose named properties and do not already declare an extension policy.\nThis makes misspelled members and accidental fields fail structural validation.\n\nClosure is not universal JSON denial. AIP deliberately carries open values in\nschema-defined places such as `extensions`, trace and security metadata,\nprofile metadata, and selected provider-neutral payload fields. Capability\n`Binding` also uses flattened profile metadata and therefore remains an\nexplicitly open object. The reviewed envelope and manifest schema graphs each\ncontain that open binding definition.\n\nUse an admitted extension field or versioned profile binding instead of adding\nan unknown sibling to a closed object. Openness changes only structural shape:\nextension content is still subject to size, security, redaction, authorization,\nand profile negotiation rules.\n\n## Compiler safety limits\n\nThe reviewed Rust validator isolates schema compilation from asynchronous\nworker stacks and applies the following implementation limits before Draft\n2020-12 compilation.\n\n| Limit | Reviewed value | Applies to |\n|---|---:|---|\n| Maximum nesting depth | 128 | Schema object and array traversal |\n| Maximum nodes | 100,000 | Aggregate object, array, and scalar nodes |\n| Maximum text | 8 MiB | Aggregate UTF-8 bytes in object keys and string values |\n| Maximum diagnostics | 1,024 | Returned instance-validation errors |\n| Compiler request queue | 64 | Pending compilation or validation requests |\n| Dedicated compiler stack | 32 MiB | Isolated compiler thread |\n\nThe diagnostic limit is a cap, not a promise to report every violation. A\ncompiler panic is converted into a compile error, and a stopped or unavailable\ncompiler fails closed.\n\nThese values describe the reviewed Rust implementation; they are not payload\nsize limits for every transport and not universal limits for every conforming\nimplementation. Each implementation must bound untrusted schemas and payloads\naccording to its deployment policy.\n\n## Formats outside the normative catalog\n\nThe following data may use JSON or JSON Schema but is not part of the 52-file\nAIP 1.0 catalog.\n\n| Format | Why it is separate |\n|---|---|\n| Connector capability input and output schemas | Versioned with an admitted connector manifest and generated capability catalog |\n| Connector release, admission, evidence, and orchestration records | Control-plane and supply-chain formats, not native AIP messages |\n| Database migrations and storage records | Persistence implementation, not a wire contract |\n| MCP, A2A, and webhook product DTOs | Owned by compatibility profiles at the gateway boundary |\n| Provider request, response, and webhook payloads | Owned by the external product and connector mapping |\n| Documentation page, navigation, and catalog schemas | Authoring and publication controls, not protocol objects |\n\nDo not add one of these formats to the normative count because it happens to be\nmachine-readable. Adding a normative top-level schema requires an explicit\nregistry entry, specification ownership, version review, generated artifact,\nand conformance coverage.\n\n## Related references\n\n- [AIP 1.0](AIP-1.0.md) owns normative behavior, message families, lifecycle,\n  security, and conformance.\n- [Compatibility profiles](compatibility-profiles.md) explains where foreign\n  protocol objects map into the native model.\n- [Native HTTP API](../reference/http-api.md) shows how validated envelopes and\n  operational objects cross the HTTP boundary.\n- [Conformance and qualification](../reference/conformance.md) explains which\n  evidence supports schema, protocol, connector, and deployment claims.\n",
    "text": "AIP JSON Schemas\n\nUse this reference to select an AIP 1.0 schema, reproduce the committed\n52-file catalog, validate data at the correct layer, and record enough\nprovenance to identify the exact bytes you used. It is for protocol\nimplementers and release reviewers. A schema-valid document is structurally\nvalid; it is not automatically authenticated, authorized, or safe to execute.\n\nScope and authority\n\nThe JSON Schemas are the machine-readable half of the\nAIP 1.0 normative contract (AIP-1.0.md). The prose specification owns\nbehavior, state transitions, security requirements, and conformance. The\nschemas own JSON shape, required members, enum values, body tagging, closed\ntyped objects, and constraints expressible in JSON Schema.\n\n| Property | Reviewed value |\n\n| Protocol | AIP 1.0 |\n| Schema dialect | JSON Schema Draft 2020-12 |\n| Normative files | 52 |\n| Source directory | schemas/aip/ |\n| Stable $id prefix | https://getaip.org/schemas/aip/ |\n| Generated registry | 52 fixed SchemaName entries |\n| Reviewed implementation release | Rust workspace 2.0.0 |\n\nA release binds the specification and schema files to an exact source\nrevision. If prose and schema disagree, treat that as a specification defect;\ndo not silently choose a third wire shape. Report which revision, file, and\nrule your implementation followed.\n\nThe committed files are generated artifacts. Change the semantic type or\nregistry owner, regenerate the complete set, review the diff, and commit the\nresult together. Do not hand-edit one exported file as an isolated fix.\n\nBrowse and obtain a schema\n\nChoose the source that matches the claim you need to make.\n\n| Need | Use |\n\n| Reproduce the reviewed implementation | schemas/aip/.schema.json at the full reviewed commit |\n| Validate with the Rust implementation | The built-in SchemaRegistry entry |\n| Inspect every normative filename | Appendix A of AIP 1.0 (AIP-1.0.md#appendix-a-json-schema-registry) |\n| Prepare a release | Regenerate all 52 files and require a clean source diff |\n| Validate offline | Map each stable $id to the matching local committed file |\n\nThe $id is a logical schema identifier. It does not by itself guarantee that\nan HTTP server exists at that URL. A release or documentation bundle that\noffers downloadable schemas must publish the committed bytes without changing\nformatting, identifiers, or content.\n\nUse the full source revision when reproducibility matters. A mutable branch\nname does not identify a fixed schema set.\n\nSchema families\n\nThe registry contains ten families. The filenames below are exhaustive for the\nreviewed AIP 1.0 set.\n\n| Family | Count | Files |\n\n| Envelope, discovery, and identity | 5 | envelope, manifest, manifestfilter, capabilitycontract, identitycontext |\n| Actions and streaming | 11 | action, ack, streamchunk, actionresult, actionstatusrequest, actionstatus, actionresultrequest, actionlistrequest, actionlist, actioneventsrequest, actionevents |\n| Approvals | 6 | approvalrequest, approvaldecision, approvalqueryrequest, approvalrecordview, approvallistrequest, approvallist |\n| Sessions | 7 | sessionrequest, sessionview, sessionlistrequest, sessionlist, sessioncloserequest, sessionresumerequest, sessionresume |\n| Transactions | 5 | transactionplan, transactionrequest, transactionresult, transactionqueryrequest, transactionview |\n| Resources | 4 | resourcelistrequest, resourcelist, resourcereadrequest, resourcereadresult |\n| Callback delivery | 5 | callbackdeliverypolicy, callbackdeliveryqueryrequest, callbackdeliverylistrequest, callbackdeliveryrecord, callbackdeliverylist |\n| Delegation | 2 | delegationrequest, delegationresult |\n| Receipts and audit | 3 | receiptqueryrequest, auditqueryrequest, auditqueryresult |\n| Events and channels | 4 | escalation, event, eventstream, channelmessage |\n| Total | 52 | Each base name has the suffix .schema.json |\n\nThe envelope schema embeds definitions for all 58 native message variants.\nThat does not turn every message body into a separate top-level schema file.\nThe registry exposes top-level files only for the 52 entries above.\n\nHow schemas are generated\n\nThe reviewed generator follows one deterministic ownership path:\n1. SchemaName defines the fixed registry and canonical filename for each\n   top-level schema.\n2. SchemaRegistry::schema derives a document from the corresponding semantic\n   Rust type with schemars.\n3. annotateschema adds the stable $id and fixes the envelope\n   aipversion member to 1.0.\n4. hardenobjectschemas recursively closes typed objects that do not declare\n   an explicit additionalProperties policy.\n5. SchemaRegistry::all exports the 52 entries in a fixed order.\n6. The CLI serializes each document as pretty JSON into its canonical file.\n\nIf schema generation cannot serialize a derived document, the registry emits\na fail-closed schema containing not: {} and a diagnostic comment. It does not\nsilently publish a permissive replacement.\n\nThe generated registry is the code owner; schemas/aip/ is the committed\nrelease artifact. Both must agree at a release revision.\n\nExport from source\n\nRun export only from the source revision you intend to document or release.\nFor the reviewed revision, the direct command is:\n\ncargo run -q -p getaip-cli -- schema export schemas/aip\n\nThe workspace task runner owns the same operation:\n\ncargo run -p xtask -- schema\ngit diff --exit-code -- schemas/aip\n\nThe exporter creates the destination directory and writes every registered\nfile. It does not make an arbitrary output directory authoritative, and it does\nnot prove that no unrelated file is present. A release check must also verify:\n• exactly 52 regular .schema.json files;\n• the exact registry filenames, with no missing or extra schema;\n• valid JSON and Draft 2020-12 on every file;\n• 52 unique $id values with the canonical prefix;\n• byte-for-byte agreement with a fresh export;\n• a clean source diff after generation.\n\nThe reviewed continuous-integration and release workflows regenerate the\ncatalog and fail when schemas/aip/ differs from the committed result.\n\nValidate data\n\nValidate a manifest from the CLI\n\nThe reviewed CLI has a manifest-specific structural validator:\n\ncargo run -q -p getaip-cli -- manifest validate path/to/manifest.json\n\nSuccess prints manifest valid. This command validates the JSON value against\nthe manifest schema. It does not admit capabilities, bind handlers, or prove\nthat a deployment can execute them.\n\nThe reviewed CLI exposes schema export; it does not expose a generic\nschema validate subcommand. Use a Draft 2020-12 validator or the registry API\nfor other top-level schemas.\n\nValidate a named schema in Rust\n\nSelect the registry entry explicitly so a filename typo cannot select a\ndifferent contract.\n\nuse aipschema::{SchemaName, SchemaRegistry};\nuse serdejson::Value;\n\nlet value: Value = serdejson::fromslice(&bytes)?;\nSchemaRegistry::new().validatejson(SchemaName::Action, &value)?;\n\nvalidatejson compiles the generated Draft 2020-12 schema and returns bounded\ndiagnostics when the instance fails.\n\nValidate a native envelope\n\nFor a typed native envelope, use the combined registry entry point:\n\nuse aipcore::Envelope;\nuse aipschema::SchemaRegistry;\n\nlet envelope: Envelope = serdejson::fromslice(&bytes)?;\nSchemaRegistry::new().validateenvelope(&envelope)?;\n\nThis runs core envelope invariants and then validates the serialized value\nagainst envelope.schema.json. A gateway still has additional admission work.\n\nInterpret validation failures\n\n| Failure class | Meaning | Next check |\n\n| JSON decode or typed decode | The input is not usable JSON or cannot map to the selected type | Encoding, member names, tags, and value types |\n| Schema compile | The schema is invalid or exceeds compiler safety limits | Dialect, recursion, node count, and text size |\n| Schema validation | The instance violates machine-readable shape | Required members, enums, closed objects, bounds, and body tags |\n| Core validation | A cross-field AIP invariant failed | Type/body match, ids, limits, transaction links, or result requirements |\n| Admission denial | Structurally valid work is not authorized or executable | Identity, replay, manifest, handler, policy, approval, and ownership |\n\nDo not retry an unchanged payload merely because a validator returned several\ndiagnostics. Correct the first owning layer, then validate again.\n\nStructural, semantic, and admission validation\n\nValidation is layered. Passing a lower layer never skips a higher one.\n\n| Layer | Owner | Examples of what it proves | What it does not prove |\n\n| JSON and typed decoding | JSON parser and semantic types | The payload can be decoded into the selected representation | Schema, identity, or behavior |\n| JSON Schema | SchemaRegistry::validatejson | Required members, enums, tags, object closure, and declared bounds | Cross-record state, authentication, or authorization |\n| Core semantic validation | SchemaRegistry::validateenvelope | AIP version, type/body match, message id, body-specific cross-field invariants | Trusted caller, replay ownership, or capability availability |\n| Gateway and runtime admission | Auth, discovery, policy, and runtime services | Authenticated identity, replay claim, admitted handler, input contract, idempotency, approval, and durable ownership | External provider success or qualification |\n| Connector/provider execution | Admitted connector and provider | Provider-specific result under the declared operation contract | Universal interoperability or production readiness |\n\nThe following cases require semantic or admission logic:\n• transaction ids must agree across the wrapper and action context;\n• a failed result must carry an error;\n• a decision must refer to the stored governed subject;\n• a caller must be authorized to read an otherwise valid resource.\n\nCapability inputschema and outputschema values are dynamic contracts from\nan admitted manifest. They are validated during action admission and result\nhandling; they are not additional files in the global 52-schema registry.\n\nIDs, versions, and digests\n\nEvery committed schema has:\n• $schema: https://json-schema.org/draft/2020-12/schema;\n• one unique $id equal to the canonical prefix plus filename;\n• a stable filename owned by SchemaName;\n• additionalProperties: false at the top-level typed object.\n\nThe envelope schema additionally fixes aipversion to 1.0. Other version\naxes, such as message-family majors, manifest version, and compatibility\nprofile versions, remain independent as defined by AIP 1.0.\n\nA stable $id is not a content digest. To identify exact bytes, record the\nfull source revision and a SHA-256 digest for each file or for a published index\nwhose ordering and encoding are defined. For example:\n\nshasum -a 256 schemas/aip/.schema.json\n\nThe reviewed registry does not define a canonical aggregate schema-set digest\nor a documentation asset index. Do not claim one exists. If a publication\npipeline adds an index, it must name the source revision and list exactly 52\nfiles. It must also preserve each $id, define ordering, and derive digests\nfrom the committed bytes rather than regenerating from an unrelated working\ntree.\n\nAn incompatible wire change requires the versioning action defined by the\nnormative specification. Reusing an existing $id for incompatible bytes is\nnot a substitute for a protocol or message-family version change.\n\nClosed objects and extension surfaces\n\nThe generator recursively adds additionalProperties: false to typed objects\nthat expose named properties and do not already declare an extension policy.\nThis makes misspelled members and accidental fields fail structural validation.\n\nClosure is not universal JSON denial. AIP deliberately carries open values in\nschema-defined places such as extensions, trace and security metadata,\nprofile metadata, and selected provider-neutral payload fields. Capability\nBinding also uses flattened profile metadata and therefore remains an\nexplicitly open object. The reviewed envelope and manifest schema graphs each\ncontain that open binding definition.\n\nUse an admitted extension field or versioned profile binding instead of adding\nan unknown sibling to a closed object. Openness changes only structural shape:\nextension content is still subject to size, security, redaction, authorization,\nand profile negotiation rules.\n\nCompiler safety limits\n\nThe reviewed Rust validator isolates schema compilation from asynchronous\nworker stacks and applies the following implementation limits before Draft\n2020-12 compilation.\n\n| Limit | Reviewed value | Applies to |\n\n| Maximum nesting depth | 128 | Schema object and array traversal |\n| Maximum nodes | 100,000 | Aggregate object, array, and scalar nodes |\n| Maximum text | 8 MiB | Aggregate UTF-8 bytes in object keys and string values |\n| Maximum diagnostics | 1,024 | Returned instance-validation errors |\n| Compiler request queue | 64 | Pending compilation or validation requests |\n| Dedicated compiler stack | 32 MiB | Isolated compiler thread |\n\nThe diagnostic limit is a cap, not a promise to report every violation. A\ncompiler panic is converted into a compile error, and a stopped or unavailable\ncompiler fails closed.\n\nThese values describe the reviewed Rust implementation; they are not payload\nsize limits for every transport and not universal limits for every conforming\nimplementation. Each implementation must bound untrusted schemas and payloads\naccording to its deployment policy.\n\nFormats outside the normative catalog\n\nThe following data may use JSON or JSON Schema but is not part of the 52-file\nAIP 1.0 catalog.\n\n| Format | Why it is separate |\n\n| Connector capability input and output schemas | Versioned with an admitted connector manifest and generated capability catalog |\n| Connector release, admission, evidence, and orchestration records | Control-plane and supply-chain formats, not native AIP messages |\n| Database migrations and storage records | Persistence implementation, not a wire contract |\n| MCP, A2A, and webhook product DTOs | Owned by compatibility profiles at the gateway boundary |\n| Provider request, response, and webhook payloads | Owned by the external product and connector mapping |\n| Documentation page, navigation, and catalog schemas | Authoring and publication controls, not protocol objects |\n\nDo not add one of these formats to the normative count because it happens to be\nmachine-readable. Adding a normative top-level schema requires an explicit\nregistry entry, specification ownership, version review, generated artifact,\nand conformance coverage.\n\nRelated references\n• AIP 1.0 (AIP-1.0.md) owns normative behavior, message families, lifecycle,\n  security, and conformance.\n• Compatibility profiles (compatibility-profiles.md) explains where foreign\n  protocol objects map into the native model.\n• Native HTTP API (../reference/http-api.md) shows how validated envelopes and\n  operational objects cross the HTTP boundary.\n• Conformance and qualification (../reference/conformance.md) explains which\n  evidence supports schema, protocol, connector, and deployment claims.\n"
  },
  "integrity": {
    "algorithm": "sha256",
    "sourceDigest": "4b7d95d6b0fb04d35da430ee32d79d6a9dc02372b98654e68935f1fe8aa6ac0b"
  }
}