{
  "schemaVersion": "1.0",
  "title": "AIP specification suite",
  "description": "Use this index to choose the authoritative document for an AIP 1.0 behavior, wire shape, compatibility mapping, connector boundary, conformance claim, or implementation-status question. It is primarily for protocol implementers and reviewer",
  "canonical": "https://getaip.org/docs/spec",
  "route": "/docs/spec",
  "source": "docs/spec/README.md",
  "protocol": "Agent Interoperability Protocol",
  "protocolVersion": "1.0",
  "section": "Protocol Standard",
  "documentType": "Documentation",
  "language": "en",
  "revision": {
    "lastReviewedRevision": "97be86e9efedf07ecf1783b03800f683f107fb04",
    "documentationSourceRevision": "9192fef3695ad294994f2712f6d156241e5e92fb",
    "basis": "frontmatter"
  },
  "downloads": {
    "md": "/docs/download/spec.md",
    "txt": "/docs/download/spec.txt",
    "json": "/docs/download/spec.json",
    "pdf": "/docs/download/spec.pdf"
  },
  "content": {
    "format": "text/markdown",
    "markdown": "---\ntitle: AIP specification suite\ndescription: Choose the authoritative protocol, schema, profile, connector, or conformance artifact\nkind: index\naudience: protocol-implementer\nappliesTo: \"1.x\"\nwritingStandard: \"aip-docs/1.0\"\nlastReviewedRevision: \"97be86e9efedf07ecf1783b03800f683f107fb04\"\n---\n\n# AIP specification suite\n\nUse this index to choose the authoritative document for an AIP 1.0 behavior,\nwire shape, compatibility mapping, connector boundary, conformance claim, or\nimplementation-status question. It is primarily for protocol implementers and\nreviewers who need to distinguish requirements from current Rust support and\nretained evidence.\n\nThe normative protocol version is `1.0`. Implementation details on these\npages are reviewed against Rust workspace version `1.0.0` at source revision\n`97be86e9efedf07ecf1783b03800f683f107fb04`. A workspace release and a\nprotocol version answer different questions.\n\n## Choose the artifact by question\n\n| Question | Read | Authority |\n|---|---|---|\n| What must an AIP 1.0 participant do? | [AIP 1.0 normative specification](AIP-1.0.md) | Normative behavioral contract |\n| Which JSON members, types, and constraints are valid on the wire? | [JSON Schemas](schemas.md) | Normative machine-readable wire contract |\n| How does MCP, A2A, a webhook, or a native binding map into AIP? | [Compatibility profiles](compatibility-profiles.md) | Supporting implementation reference; the normative boundary remains in AIP 1.0 |\n| What must a product connector preserve and implement? | [Connector contract](connector-contract.md) | Supporting boundary for the normative protocol and reviewed Rust SDK |\n| What evidence supports a conformance or qualification claim? | [Conformance and qualification](../reference/conformance.md) | Claim and evidence interpretation |\n| What does the reviewed Rust source currently implement? | [Implementation status](../reference/implementation-status.md) | Informative source and evidence status |\n\nStart with the first row when behavior is disputed. Start with schemas when\ngenerating, accepting, or validating JSON. Use implementation and evidence pages\nonly after the required behavior is clear.\n\n## Apply the two-part normative contract\n\nAn AIP 1.0 implementation must satisfy both:\n\n1. the behavioral requirements in the normative specification; and\n2. every applicable versioned JSON Schema.\n\nSchema validation establishes wire shape. It cannot fully express\nauthentication, replay decisions, authorization, legal state transitions,\nidempotency ownership, transaction consistency, route identity, or external\nside-effect rules. The reviewed implementation therefore applies both generated\nschema validation and semantic validation from the native model.\n\nThe reverse is also true: code that performs a sensible transition is not\nconforming if it accepts or emits a wire object that violates the applicable\nschema.\n\nIf a normative prose rule and a versioned schema disagree, treat the\ndisagreement as a specification defect. Do not silently invent a third\nbehavior. A conformance report should identify the exact conflicting artifact\nand rule until the suite is corrected.\n\n## Interpret each document’s authority\n\n| Artifact class | It can establish | It cannot establish alone |\n|---|---|---|\n| Normative specification | Required semantics, invariants, states, errors, security, versioning, and conformance classes | Exact implementation support or deployment readiness |\n| Versioned schemas | Accepted JSON structure, names, types, closed objects, and schema constraints | Cross-record policy or provider outcome |\n| Profile reference | The reviewed projection and endpoint behavior for one foreign or transport surface | A parallel native lifecycle or universal profile support |\n| Connector contract | The generic product boundary and reviewed SDK expectations | Qualification of a specific connector or provider |\n| Conformance evidence | Results for named artifacts, classes, procedure, and environment | Production fitness outside that scope |\n| Implementation status | Source presence and retained evidence at the named revision | A new protocol requirement or current live availability |\n\nNormative key words such as `MUST`, `SHOULD`, and `MAY` have their defined\nmeaning only in the normative specification. Similar prose on an architecture,\nguide, or implementation page explains the reviewed implementation unless that\npage explicitly quotes and links the normative rule.\n\n## Keep five version axes separate\n\n| Version axis | Reviewed value or form | What it versions |\n|---|---|---|\n| Protocol | `1.0` | Native AIP semantic contract and `Envelope.aip_version` |\n| Rust workspace release | `1.0.0` | Source packages and implementation artifacts |\n| Manifest schema | `aip-manifest/v1` | Participant manifest shape and admission contract |\n| Native message family | For example, `aip.core.v1.action` | One registered message namespace and major family |\n| Compatibility profile | For example, `aip.mcp.compat.v1` | One bounded foreign-protocol or delivery mapping |\n\nMatching the workspace release does not permit an implementation to emit a\ndifferent protocol version. Matching `aip_version` does not prove support for\nevery message family, profile, connector, or conformance class.\n\nReceivers use the envelope protocol version and registered message type\ntogether. Manifests and profile negotiation declare narrower support. A\ndeployment must reject unsupported combinations rather than infer compatibility\nfrom a shared `v1` suffix.\n\n## Follow a reading path\n\n| Goal | Recommended order | Result |\n|---|---|---|\n| Implement native AIP | AIP 1.0 scope and terminology → envelope and registry → lifecycle sections → security → conformance → schemas | A behavioral model plus exact wire validation |\n| Implement a compatibility edge | AIP 1.0 native lifecycle → compatibility section → profile reference → applicable native schemas | A bounded mapping into the same action and lifecycle model |\n| Implement a connector | AIP 1.0 capabilities, actions, errors, and security → connector contract → applicable schemas | A product adapter that preserves native authority and lifecycle boundaries |\n| Review an implementation claim | Normative requirement → conformance page → implementation status → named retained artifacts | A claim limited to its source revision, class, environment, and evidence |\n| Diagnose an artifact conflict | Identify protocol, schema, message-family, profile, and workspace versions → compare the exact rule and generated artifact | A reproducible specification or implementation defect |\n\nThe full normative specification is intentionally comprehensive. For normal\napplication integration, start with the task-oriented guides instead. Return to\nthis suite when exact behavior, interoperability, or conformance is the\nquestion.\n\n## Change the suite as one contract\n\nA public protocol change is complete only when all affected owners agree:\n\n- normative prose describes the new behavior and compatibility rule;\n- native types and semantic validation implement the same invariant;\n- versioned schemas accept exactly the intended wire shape;\n- message and profile identifiers reflect any incompatible boundary;\n- positive and negative conformance cases cover the rule; and\n- examples and supporting references use the released artifact.\n\nAn incompatible change requires a new applicable version boundary. An additive\nchange is compatible only when existing receivers can process or ignore it\nunder the normative extension rules. A documentation edit cannot redefine the\nwire contract without the matching protocol and schema changes.\n\nExact generated inventories belong to source-owned registries and release\nartifacts. This index deliberately does not copy the complete message, schema,\nfield, profile, or operation lists.\n\n## Read implementation and evidence claims narrowly\n\nSource review can establish that a type, validator, profile mapping, transport,\nor connector path exists at one revision. Conformance can establish that named\nrequirements passed a named procedure. Qualification can add topology,\nfailure, scale, or external-product evidence for exact artifacts.\n\nNone of those claims automatically establishes current production readiness.\nDeployment identity, configuration, storage, credentials, network policy,\nconnector version, provider behavior, and retained results remain part of the\nclaim.\n\n## Specification entry points\n\n- [AIP 1.0 normative specification](AIP-1.0.md)\n- [JSON Schemas](schemas.md)\n- [Compatibility profiles](compatibility-profiles.md)\n- [Connector contract](connector-contract.md)\n- [Conformance and qualification](../reference/conformance.md)\n",
    "text": "AIP specification suite\n\nUse this index to choose the authoritative document for an AIP 1.0 behavior,\nwire shape, compatibility mapping, connector boundary, conformance claim, or\nimplementation-status question. It is primarily for protocol implementers and\nreviewers who need to distinguish requirements from current Rust support and\nretained evidence.\n\nThe normative protocol version is 1.0. Implementation details on these\npages are reviewed against Rust workspace version 1.0.0 at source revision\n97be86e9efedf07ecf1783b03800f683f107fb04. A workspace release and a\nprotocol version answer different questions.\n\nChoose the artifact by question\n\n| Question | Read | Authority |\n\n| What must an AIP 1.0 participant do? | AIP 1.0 normative specification (AIP-1.0.md) | Normative behavioral contract |\n| Which JSON members, types, and constraints are valid on the wire? | JSON Schemas (schemas.md) | Normative machine-readable wire contract |\n| How does MCP, A2A, a webhook, or a native binding map into AIP? | Compatibility profiles (compatibility-profiles.md) | Supporting implementation reference; the normative boundary remains in AIP 1.0 |\n| What must a product connector preserve and implement? | Connector contract (connector-contract.md) | Supporting boundary for the normative protocol and reviewed Rust SDK |\n| What evidence supports a conformance or qualification claim? | Conformance and qualification (../reference/conformance.md) | Claim and evidence interpretation |\n| What does the reviewed Rust source currently implement? | Implementation status (../reference/implementation-status.md) | Informative source and evidence status |\n\nStart with the first row when behavior is disputed. Start with schemas when\ngenerating, accepting, or validating JSON. Use implementation and evidence pages\nonly after the required behavior is clear.\n\nApply the two-part normative contract\n\nAn AIP 1.0 implementation must satisfy both:\n1. the behavioral requirements in the normative specification; and\n2. every applicable versioned JSON Schema.\n\nSchema validation establishes wire shape. It cannot fully express\nauthentication, replay decisions, authorization, legal state transitions,\nidempotency ownership, transaction consistency, route identity, or external\nside-effect rules. The reviewed implementation therefore applies both generated\nschema validation and semantic validation from the native model.\n\nThe reverse is also true: code that performs a sensible transition is not\nconforming if it accepts or emits a wire object that violates the applicable\nschema.\n\nIf a normative prose rule and a versioned schema disagree, treat the\ndisagreement as a specification defect. Do not silently invent a third\nbehavior. A conformance report should identify the exact conflicting artifact\nand rule until the suite is corrected.\n\nInterpret each document’s authority\n\n| Artifact class | It can establish | It cannot establish alone |\n\n| Normative specification | Required semantics, invariants, states, errors, security, versioning, and conformance classes | Exact implementation support or deployment readiness |\n| Versioned schemas | Accepted JSON structure, names, types, closed objects, and schema constraints | Cross-record policy or provider outcome |\n| Profile reference | The reviewed projection and endpoint behavior for one foreign or transport surface | A parallel native lifecycle or universal profile support |\n| Connector contract | The generic product boundary and reviewed SDK expectations | Qualification of a specific connector or provider |\n| Conformance evidence | Results for named artifacts, classes, procedure, and environment | Production fitness outside that scope |\n| Implementation status | Source presence and retained evidence at the named revision | A new protocol requirement or current live availability |\n\nNormative key words such as MUST, SHOULD, and MAY have their defined\nmeaning only in the normative specification. Similar prose on an architecture,\nguide, or implementation page explains the reviewed implementation unless that\npage explicitly quotes and links the normative rule.\n\nKeep five version axes separate\n\n| Version axis | Reviewed value or form | What it versions |\n\n| Protocol | 1.0 | Native AIP semantic contract and Envelope.aipversion |\n| Rust workspace release | 1.0.0 | Source packages and implementation artifacts |\n| Manifest schema | aip-manifest/v1 | Participant manifest shape and admission contract |\n| Native message family | For example, aip.core.v1.action | One registered message namespace and major family |\n| Compatibility profile | For example, aip.mcp.compat.v1 | One bounded foreign-protocol or delivery mapping |\n\nMatching the workspace release does not permit an implementation to emit a\ndifferent protocol version. Matching aipversion does not prove support for\nevery message family, profile, connector, or conformance class.\n\nReceivers use the envelope protocol version and registered message type\ntogether. Manifests and profile negotiation declare narrower support. A\ndeployment must reject unsupported combinations rather than infer compatibility\nfrom a shared v1 suffix.\n\nFollow a reading path\n\n| Goal | Recommended order | Result |\n\n| Implement native AIP | AIP 1.0 scope and terminology → envelope and registry → lifecycle sections → security → conformance → schemas | A behavioral model plus exact wire validation |\n| Implement a compatibility edge | AIP 1.0 native lifecycle → compatibility section → profile reference → applicable native schemas | A bounded mapping into the same action and lifecycle model |\n| Implement a connector | AIP 1.0 capabilities, actions, errors, and security → connector contract → applicable schemas | A product adapter that preserves native authority and lifecycle boundaries |\n| Review an implementation claim | Normative requirement → conformance page → implementation status → named retained artifacts | A claim limited to its source revision, class, environment, and evidence |\n| Diagnose an artifact conflict | Identify protocol, schema, message-family, profile, and workspace versions → compare the exact rule and generated artifact | A reproducible specification or implementation defect |\n\nThe full normative specification is intentionally comprehensive. For normal\napplication integration, start with the task-oriented guides instead. Return to\nthis suite when exact behavior, interoperability, or conformance is the\nquestion.\n\nChange the suite as one contract\n\nA public protocol change is complete only when all affected owners agree:\n• normative prose describes the new behavior and compatibility rule;\n• native types and semantic validation implement the same invariant;\n• versioned schemas accept exactly the intended wire shape;\n• message and profile identifiers reflect any incompatible boundary;\n• positive and negative conformance cases cover the rule; and\n• examples and supporting references use the released artifact.\n\nAn incompatible change requires a new applicable version boundary. An additive\nchange is compatible only when existing receivers can process or ignore it\nunder the normative extension rules. A documentation edit cannot redefine the\nwire contract without the matching protocol and schema changes.\n\nExact generated inventories belong to source-owned registries and release\nartifacts. This index deliberately does not copy the complete message, schema,\nfield, profile, or operation lists.\n\nRead implementation and evidence claims narrowly\n\nSource review can establish that a type, validator, profile mapping, transport,\nor connector path exists at one revision. Conformance can establish that named\nrequirements passed a named procedure. Qualification can add topology,\nfailure, scale, or external-product evidence for exact artifacts.\n\nNone of those claims automatically establishes current production readiness.\nDeployment identity, configuration, storage, credentials, network policy,\nconnector version, provider behavior, and retained results remain part of the\nclaim.\n\nSpecification entry points\n• AIP 1.0 normative specification (AIP-1.0.md)\n• JSON Schemas (schemas.md)\n• Compatibility profiles (compatibility-profiles.md)\n• Connector contract (connector-contract.md)\n• Conformance and qualification (../reference/conformance.md)\n"
  },
  "integrity": {
    "algorithm": "sha256",
    "sourceDigest": "8a7a3f5bae5084a5735ce870fc831c5656f5c50cf627634cc9a88d5863d4b1f4"
  }
}