{
  "schemaVersion": "1.0",
  "title": "Use the Rust SDK",
  "description": "Use this guide when a Rust application needs AIP 1.0 types, validation, or an embedded protocol service. You will pin the reviewed SDK source, construct and validate one native action envelope, and then select optional modules by role. The ",
  "canonical": "https://getaip.org/docs/guides/use-rust-sdk",
  "route": "/docs/guides/use-rust-sdk",
  "source": "docs/guides/use-rust-sdk.md",
  "protocol": "Agent Interoperability Protocol",
  "protocolVersion": "1.0",
  "section": "Build with AIP",
  "documentType": "Guide",
  "language": "en",
  "revision": {
    "lastReviewedRevision": "97be86e9efedf07ecf1783b03800f683f107fb04",
    "documentationSourceRevision": "9192fef3695ad294994f2712f6d156241e5e92fb",
    "basis": "frontmatter"
  },
  "downloads": {
    "md": "/docs/download/guides/use-rust-sdk.md",
    "txt": "/docs/download/guides/use-rust-sdk.txt",
    "json": "/docs/download/guides/use-rust-sdk.json",
    "pdf": "/docs/download/guides/use-rust-sdk.pdf"
  },
  "content": {
    "format": "text/markdown",
    "markdown": "---\ntitle: Use the Rust SDK\ndescription: Select a source-backed AIP crate surface and validate a native envelope without enabling the legacy product feature group\nkind: how-to\naudience: developer\nappliesTo: \"1.x\"\nwritingStandard: \"aip-docs/1.0\"\nlastReviewedRevision: \"97be86e9efedf07ecf1783b03800f683f107fb04\"\n---\n\n# Use the Rust SDK\n\nUse this guide when a Rust application needs AIP 1.0 types, validation, or an\nembedded protocol service. You will pin the reviewed SDK source, construct and\nvalidate one native action envelope, and then select optional modules by role.\nThe procedure is for application developers who can change a Cargo manifest.\n\nAt source revision\n`97be86e9efedf07ecf1783b03800f683f107fb04`, every AIP workspace package has\n`publish = false`. Consume that revision from source or from an approved mirror;\ndo not assume that `aip = \"1\"` resolves to an AIP-owned registry release. The\nexamples and commands on this page were checked against source without building\nthe workspace or running an AIP service.\n\n## Prerequisites\n\nYou need:\n\n- Rust `1.88` or newer, matching the reviewed workspace minimum;\n- a Rust toolchain that supports edition 2024 packages;\n- access to the reviewed source revision or an approved immutable mirror of it;\n- permission to update and retain the project's `Cargo.toml` and `Cargo.lock`;\n- a decision about whether the project needs only protocol semantics or also a\n  runtime, transport, profile, or connector role.\n\nNo provider credential is required for the semantic example. Do not place\ncredentials, tenant identifiers, or deployment secrets in a Cargo feature or\nsource URL.\n\n## 1. Choose the dependency boundary\n\nThe `aip` facade is the single entry crate that re-exports the semantic core\nand feature-gated modules from role-specific crates. Start with the smallest\nboundary that owns the API you need.\n\n| Boundary | Use it when | Initial choice |\n|---|---|---|\n| `aip` facade with defaults | The application creates, parses, serializes, or validates native AIP values | Prefer for most semantic consumers |\n| `aip` facade with selected features | The application embeds one or more re-exported service roles | Add only the named role features |\n| `aip` facade with `full-core` | Integration or conformance work needs nearly every product-neutral facade module | Use deliberately, then inspect the dependency tree |\n| A role-specific crate | A component needs a narrow compile-time boundary or a workspace role not re-exported by `aip` | Depend on that crate directly |\n\nThe facade always re-exports `aip-core`. Its default features are the `std` and\n`json` compatibility markers; they do not enable the runtime, gateway,\ntransport, profile, schema, storage, conformance, or connector modules.\n\nThe facade is not an inventory of every workspace crate. Fleet admission,\norchestration, control-plane, host-bootstrap, and shared MCP-session roles are\ndirect crates at the reviewed revision.\n\n## 2. Pin the reviewed source\n\nAdd the facade and JSON support to your application. A Git dependency records\nthe immutable revision in `Cargo.lock`:\n\n```toml\n[dependencies]\naip = { git = \"https://github.com/getaip/core\", rev = \"97be86e9efedf07ecf1783b03800f683f107fb04\" }\nserde_json = \"1\"\n```\n\nIf policy requires a vendored checkout, replace the Git dependency with the\napproved local path:\n\n```toml\n[dependencies]\naip = { path = \"../aip-core/crates/aip\" }\nserde_json = \"1\"\n```\n\nA path dependency does not record the checkout's Git revision in the consumer\nlockfile. Record and verify the vendored source identity through the deployment\nor software bill of materials (SBOM) process responsible for that checkout.\n\n## 3. Construct and validate an envelope\n\nCreate `src/main.rs` with a semantic-only example:\n\n```rust\nuse aip::{\n    Action, CapabilityId, Envelope, MessageBody, Principal, PrincipalId, PrincipalKind,\n    validate_envelope,\n};\nuse serde_json::json;\n\nfn main() -> Result<(), Box<dyn std::error::Error>> {\n    let action = Action::new(\n        CapabilityId::parse(\"cap:example:echo\")?,\n        json!({ \"message\": \"hello from Rust\" }),\n    );\n\n    let mut envelope = Envelope::new(MessageBody::Action(Box::new(action)));\n    envelope.from = Some(Principal::new(\n        PrincipalId::parse(\"agent:sdk-example\")?,\n        PrincipalKind::Agent,\n    ));\n\n    validate_envelope(&envelope)?;\n    println!(\"{}\", serde_json::to_string_pretty(&envelope)?);\n    Ok(())\n}\n```\n\n`Action::new` generates an action identifier. `Envelope::new` derives the\nmessage type, generates a message identifier, sets `aip_version` to `1.0`, and\nrecords the current UTC time. The printed JSON therefore changes on every run.\n\n`validate_envelope` checks semantic invariants such as the protocol version,\nthe message-type/body match, identifiers, and body-specific requirements. It\ndoes not authenticate `from`, authorize the capability, admit a manifest, or\ndispatch the action. A gateway or protocol endpoint owns those boundaries.\n\n## 4. Verify the semantic project\n\nGenerate and retain a lockfile before using `--locked`:\n\n```sh\ncargo generate-lockfile\ncargo check --locked\ncargo run --locked\n```\n\nExpected result: the project compiles and prints a JSON envelope containing\n`\"aip_version\": \"1.0\"`, `\"message_type\": \"aip.core.v1.action\"`, an `action`\nbody, and the `agent:sdk-example` sender. Generated identifiers and `sent_at`\nwill differ between runs.\n\nInspect the enabled facade features:\n\n```sh\ncargo tree --locked -e features -p aip\n```\n\nFor the initial example, the facade should not show optional runtime, gateway,\ntransport, profile, schema, storage, conformance, or connector features. A\nsuccessful compile proves only that this consumer and dependency graph compile;\nit is not protocol conformance, deployment readiness, or provider qualification.\n\n## 5. Add features by task\n\nEnable a feature only when its public module belongs in the current component.\nFeature implications in this table are the explicit facade relationships at the\nreviewed revision.\n\n| Task | Facade feature | Important implication |\n|---|---|---|\n| Generate or validate against the schema registry | `schema` | Exposes `aip::schema` |\n| Compose authentication and authorization primitives | `auth` | Exposes `aip::auth` |\n| Sign, verify, or canonicalize native values | `crypto` | Exposes `aip::crypto`; it does not define authorization policy |\n| Admit and query manifests | `discovery` | Exposes `aip::discovery` |\n| Run durable action and session services | `runtime` | Also enables `auth` and `discovery` |\n| Embed the gateway composition layer | `gateway` | Also enables `runtime` |\n| Persist runtime state in PostgreSQL | `storage-postgres` | Also enables `runtime` |\n| Use the shared transport abstraction | `transport` | Exposes `aip::transport` without selecting a wire binding |\n| Use a native wire binding | `transport-http`, `transport-nats`, `transport-sse`, or `transport-websocket` | Each also enables `transport` |\n| Translate a compatibility protocol | `profile-mcp`, `profile-a2a`, or `profile-webhook` | Exposes only the selected profile mapping |\n| Embed an outbound MCP client | `mcp-client` | Also enables `profile-mcp` |\n| Embed an AIP-backed MCP server | `mcp-server` | Also enables `gateway` and `profile-mcp` |\n| Check the MCP compatibility mapping | `mcp-conformance` | Also enables `profile-mcp` |\n| Use an MCP transport | `transport-mcp-stdio` or `transport-mcp-streamable-http` | Also enables `transport` and `profile-mcp` |\n| Use the product-neutral connector contract | `connector` | Exposes `aip::connector` |\n| Host one immutable connector artifact | `connector-host` | Also enables `connector` and `connector-registry` |\n| Read or implement fleet registry contracts | `connector-registry` | Also enables `connector` |\n| Persist the fleet registry in PostgreSQL | `connector-registry-postgres` | Also enables `connector-registry` |\n| Dispatch to a remote connector host | `connector-remote` | Also enables `connector-registry` |\n| Add metrics and tracing conventions | `observability` | Exposes `aip::observability` |\n| Build deterministic tests | `testkit` | Exposes `aip::testkit` |\n| Run implementation conformance checks | `conformance` | Exposes `aip::conformance` |\n| Enable every product-neutral facade role | `full-core` | Excludes product connector features by an enforced source gate |\n\nFor example, a component that embeds a gateway and exposes an HTTP transport\ncan select those roles explicitly:\n\n```toml\n[dependencies]\naip = { git = \"https://github.com/getaip/core\", rev = \"97be86e9efedf07ecf1783b03800f683f107fb04\", features = [\"gateway\", \"transport-http\"] }\n```\n\nSelecting a feature makes its module available. It does not configure an\nidentity resolver, policy, storage backend, transport listener, manifest,\nhandler, connector registry, or credential provider.\n\n## 6. Use role-specific crates when ownership matters\n\nChoose a direct crate when a component should expose only one role or when the\nfacade does not re-export that role.\n\n| Role | Direct dependency | Boundary owned by the crate |\n|---|---|---|\n| Protocol semantics | `aip-core` | Native types, identifiers, serialization, and pure validation |\n| Schema tooling | `aip-schema` | Schema registry, generation, compilation, and validation helpers |\n| Identity and cryptography | `aip-auth`, `aip-crypto` | Policy primitives and cryptographic primitives remain separate |\n| Discovery | `aip-discovery` | Manifest registry, admission policy, cache, and profile negotiation |\n| Execution | `aip-runtime`, `aip-gateway` | Durable lifecycle services and gateway composition |\n| Transports | `aip-transport` and `aip-transport-*` | Shared transport contract and individual bindings |\n| Compatibility profiles | `aip-profile-*`, `aip-mcp-*` | Wire translation and MCP lifecycle roles |\n| Connector implementation | `aip-connector` | Product-neutral connector traits and error contracts |\n| Fleet data plane | `aip-connector-registry`, `aip-connector-host`, `aip-connector-remote` | Catalog, isolated host, route selection, and remote dispatch |\n| Fleet lifecycle | `aip-connector-admission`, `aip-connector-orchestration`, `aip-connector-control-plane`, `aip-connector-host-bootstrap` | Verified admission, platform-neutral rollout, restricted lifecycle service, and host process shell |\n| PostgreSQL persistence | `aip-storage-postgres`, `aip-connector-registry-postgres` | Runtime state and normalized fleet registry state |\n| Testing | `aip-testkit`, `aip-conformance` | Deterministic fixtures and conformance checks |\n\nDirect dependencies still use the same exact source revision. Do not combine\ndifferent AIP source revisions in one dependency graph unless a documented\ncompatibility procedure explicitly permits it.\n\n## 7. Keep legacy `full` out of new applications\n\n`full-core` is the broad product-neutral feature group in the facade. A source\ngate follows every feature it enables and rejects the graph if a product\nconnector feature or dependency becomes reachable.\n\n`full` has a different purpose. The facade source labels it a legacy\ncompatibility feature group. It adds a fixed set of product connector features\nto `full-core`, so it increases coupling and does not represent the current\npublic connector catalog. New core consumers should use `full-core`, role\nfeatures, or direct role crates. Add only the product dependency owned by the\nartifact.\n\nTo migrate an application away from `full`:\n\n1. replace `full` with `full-core` or a smaller explicit feature list;\n2. run `cargo check` once to resolve the changed graph and identify imports that\n   depended on product code;\n3. add only the required product connector dependency through its documented\n   integration boundary;\n4. inspect the manifest and lockfile diff, then run `cargo check --locked` and\n   `cargo tree --locked -e features` against the reviewed result.\n\nThe repository's registered examples still declare `required-features =\n[\"full\"]` at the reviewed revision. Running one of those exact examples inside\nthe source workspace may therefore require the legacy flag:\n\n```sh\ncargo run --locked -p aip --example minimal-agent --features full\n```\n\nThat requirement belongs to the repository example metadata. It is not a\nrecommended dependency choice for a new application, and the authoring pass for\nthis page did not execute the command.\n\n## 8. Review and narrow the change\n\nBefore merging a dependency change, inspect both the declared and resolved\nsurface:\n\n```sh\ncargo check --locked\ncargo tree --locked -e features\ngit diff -- Cargo.toml Cargo.lock\n```\n\nConfirm that:\n\n- the dependency resolves from the approved source and revision;\n- `full` is absent unless an exact repository compatibility task requires it;\n- every enabled facade feature belongs to the component's declared role;\n- product connector packages appear only when explicitly owned by that artifact;\n- the change contains no credential, internal endpoint, or local absolute path;\n- compilation is reported as compilation evidence, not conformance or runtime\n  evidence.\n\nIf a feature is unnecessary, remove it from `Cargo.toml`, regenerate the\nlockfile, and repeat the checks. No runtime rollback is required for the\nsemantic example because it performs no external operation. Existing Cargo\nbuild artifacts do not need to be deleted to narrow the dependency declaration.\n\n## Resolve common failures\n\n| Symptom | Likely cause | Bounded action |\n|---|---|---|\n| Cargo cannot find `aip` in a registry | The manifest used registry version syntax for a package that is `publish = false` at this revision | Use the pinned Git source or an approved vendored path |\n| Cargo rejects the active toolchain | The compiler is older than the workspace minimum | Select Rust `1.88` or newer and rerun `cargo check --locked` |\n| An import such as `aip::gateway` is missing | Its facade feature is not enabled | Add only the owning feature and inspect the feature tree |\n| Product connector packages appear unexpectedly | `full` or a direct product dependency is enabled | Replace `full`, then trace the remaining product dependency with `cargo tree` |\n| A repository example refuses to build without `full` | Its registered metadata still requires the compatibility feature group | Use `full` only for that exact example; do not copy it into the application manifest |\n| The dependency graph is much larger than expected | `full-core` or a high-level feature selected more roles than the component needs | Replace it with the smallest task-specific features or direct role crates |\n| Validation succeeds but dispatch later fails | Semantic validation does not authenticate, authorize, admit, route, or execute | Inspect the gateway or endpoint boundary that owns the failed stage |\n\nDependency inspection and semantic validation are read-only with respect to\nprovider state. They do not justify retrying an ambiguous provider mutation.\n\n## Related documentation\n\n- Start with [Install AIP](../getting-started/installation.md) to choose the\n  correct source artifact and binary boundary.\n- Read [How AIP works](../getting-started/how-aip-works.md) before embedding\n  protocol roles in one process.\n- Use [Capabilities and contracts](../concepts/capabilities.md) to interpret the\n  capability placed in an action.\n- Read [Profiles, transports, and connectors](../concepts/profiles-and-connectors.md)\n  before selecting compatibility or connector modules.\n- Follow [Use native AIP](use-native-aip.md) when a client should call a running\n  endpoint instead of embedding the SDK.\n",
    "text": "Use the Rust SDK\n\nUse this guide when a Rust application needs AIP 1.0 types, validation, or an\nembedded protocol service. You will pin the reviewed SDK source, construct and\nvalidate one native action envelope, and then select optional modules by role.\nThe procedure is for application developers who can change a Cargo manifest.\n\nAt source revision\n97be86e9efedf07ecf1783b03800f683f107fb04, every AIP workspace package has\npublish = false. Consume that revision from source or from an approved mirror;\ndo not assume that aip = \"1\" resolves to an AIP-owned registry release. The\nexamples and commands on this page were checked against source without building\nthe workspace or running an AIP service.\n\nPrerequisites\n\nYou need:\n• Rust 1.88 or newer, matching the reviewed workspace minimum;\n• a Rust toolchain that supports edition 2024 packages;\n• access to the reviewed source revision or an approved immutable mirror of it;\n• permission to update and retain the project's Cargo.toml and Cargo.lock;\n• a decision about whether the project needs only protocol semantics or also a\n  runtime, transport, profile, or connector role.\n\nNo provider credential is required for the semantic example. Do not place\ncredentials, tenant identifiers, or deployment secrets in a Cargo feature or\nsource URL.\n1. Choose the dependency boundary\n\nThe aip facade is the single entry crate that re-exports the semantic core\nand feature-gated modules from role-specific crates. Start with the smallest\nboundary that owns the API you need.\n\n| Boundary | Use it when | Initial choice |\n\n| aip facade with defaults | The application creates, parses, serializes, or validates native AIP values | Prefer for most semantic consumers |\n| aip facade with selected features | The application embeds one or more re-exported service roles | Add only the named role features |\n| aip facade with full-core | Integration or conformance work needs nearly every product-neutral facade module | Use deliberately, then inspect the dependency tree |\n| A role-specific crate | A component needs a narrow compile-time boundary or a workspace role not re-exported by aip | Depend on that crate directly |\n\nThe facade always re-exports aip-core. Its default features are the std and\njson compatibility markers; they do not enable the runtime, gateway,\ntransport, profile, schema, storage, conformance, or connector modules.\n\nThe facade is not an inventory of every workspace crate. Fleet admission,\norchestration, control-plane, host-bootstrap, and shared MCP-session roles are\ndirect crates at the reviewed revision.\n2. Pin the reviewed source\n\nAdd the facade and JSON support to your application. A Git dependency records\nthe immutable revision in Cargo.lock:\n\n[dependencies]\naip = { git = \"https://github.com/getaip/core\", rev = \"97be86e9efedf07ecf1783b03800f683f107fb04\" }\nserdejson = \"1\"\n\nIf policy requires a vendored checkout, replace the Git dependency with the\napproved local path:\n\n[dependencies]\naip = { path = \"../aip-core/crates/aip\" }\nserdejson = \"1\"\n\nA path dependency does not record the checkout's Git revision in the consumer\nlockfile. Record and verify the vendored source identity through the deployment\nor software bill of materials (SBOM) process responsible for that checkout.\n3. Construct and validate an envelope\n\nCreate src/main.rs with a semantic-only example:\n\nuse aip::{\n    Action, CapabilityId, Envelope, MessageBody, Principal, PrincipalId, PrincipalKind,\n    validateenvelope,\n};\nuse serdejson::json;\n\nfn main() -> Result> {\n    let action = Action::new(\n        CapabilityId::parse(\"cap:example:echo\")?,\n        json!({ \"message\": \"hello from Rust\" }),\n    );\n\n    let mut envelope = Envelope::new(MessageBody::Action(Box::new(action)));\n    envelope.from = Some(Principal::new(\n        PrincipalId::parse(\"agent:sdk-example\")?,\n        PrincipalKind::Agent,\n    ));\n\n    validateenvelope(&envelope)?;\n    println!(\"{}\", serdejson::tostringpretty(&envelope)?);\n    Ok(())\n}\n\nAction::new generates an action identifier. Envelope::new derives the\nmessage type, generates a message identifier, sets aipversion to 1.0, and\nrecords the current UTC time. The printed JSON therefore changes on every run.\n\nvalidateenvelope checks semantic invariants such as the protocol version,\nthe message-type/body match, identifiers, and body-specific requirements. It\ndoes not authenticate from, authorize the capability, admit a manifest, or\ndispatch the action. A gateway or protocol endpoint owns those boundaries.\n4. Verify the semantic project\n\nGenerate and retain a lockfile before using --locked:\n\ncargo generate-lockfile\ncargo check --locked\ncargo run --locked\n\nExpected result: the project compiles and prints a JSON envelope containing\n\"aipversion\": \"1.0\", \"messagetype\": \"aip.core.v1.action\", an action\nbody, and the agent:sdk-example sender. Generated identifiers and sentat\nwill differ between runs.\n\nInspect the enabled facade features:\n\ncargo tree --locked -e features -p aip\n\nFor the initial example, the facade should not show optional runtime, gateway,\ntransport, profile, schema, storage, conformance, or connector features. A\nsuccessful compile proves only that this consumer and dependency graph compile;\nit is not protocol conformance, deployment readiness, or provider qualification.\n5. Add features by task\n\nEnable a feature only when its public module belongs in the current component.\nFeature implications in this table are the explicit facade relationships at the\nreviewed revision.\n\n| Task | Facade feature | Important implication |\n\n| Generate or validate against the schema registry | schema | Exposes aip::schema |\n| Compose authentication and authorization primitives | auth | Exposes aip::auth |\n| Sign, verify, or canonicalize native values | crypto | Exposes aip::crypto; it does not define authorization policy |\n| Admit and query manifests | discovery | Exposes aip::discovery |\n| Run durable action and session services | runtime | Also enables auth and discovery |\n| Embed the gateway composition layer | gateway | Also enables runtime |\n| Persist runtime state in PostgreSQL | storage-postgres | Also enables runtime |\n| Use the shared transport abstraction | transport | Exposes aip::transport without selecting a wire binding |\n| Use a native wire binding | transport-http, transport-nats, transport-sse, or transport-websocket | Each also enables transport |\n| Translate a compatibility protocol | profile-mcp, profile-a2a, or profile-webhook | Exposes only the selected profile mapping |\n| Embed an outbound MCP client | mcp-client | Also enables profile-mcp |\n| Embed an AIP-backed MCP server | mcp-server | Also enables gateway and profile-mcp |\n| Check the MCP compatibility mapping | mcp-conformance | Also enables profile-mcp |\n| Use an MCP transport | transport-mcp-stdio or transport-mcp-streamable-http | Also enables transport and profile-mcp |\n| Use the product-neutral connector contract | connector | Exposes aip::connector |\n| Host one immutable connector artifact | connector-host | Also enables connector and connector-registry |\n| Read or implement fleet registry contracts | connector-registry | Also enables connector |\n| Persist the fleet registry in PostgreSQL | connector-registry-postgres | Also enables connector-registry |\n| Dispatch to a remote connector host | connector-remote | Also enables connector-registry |\n| Add metrics and tracing conventions | observability | Exposes aip::observability |\n| Build deterministic tests | testkit | Exposes aip::testkit |\n| Run implementation conformance checks | conformance | Exposes aip::conformance |\n| Enable every product-neutral facade role | full-core | Excludes product connector features by an enforced source gate |\n\nFor example, a component that embeds a gateway and exposes an HTTP transport\ncan select those roles explicitly:\n\n[dependencies]\naip = { git = \"https://github.com/getaip/core\", rev = \"97be86e9efedf07ecf1783b03800f683f107fb04\", features = [\"gateway\", \"transport-http\"] }\n\nSelecting a feature makes its module available. It does not configure an\nidentity resolver, policy, storage backend, transport listener, manifest,\nhandler, connector registry, or credential provider.\n6. Use role-specific crates when ownership matters\n\nChoose a direct crate when a component should expose only one role or when the\nfacade does not re-export that role.\n\n| Role | Direct dependency | Boundary owned by the crate |\n\n| Protocol semantics | aip-core | Native types, identifiers, serialization, and pure validation |\n| Schema tooling | aip-schema | Schema registry, generation, compilation, and validation helpers |\n| Identity and cryptography | aip-auth, aip-crypto | Policy primitives and cryptographic primitives remain separate |\n| Discovery | aip-discovery | Manifest registry, admission policy, cache, and profile negotiation |\n| Execution | aip-runtime, aip-gateway | Durable lifecycle services and gateway composition |\n| Transports | aip-transport and aip-transport- | Shared transport contract and individual bindings |\n| Compatibility profiles | aip-profile-, aip-mcp- | Wire translation and MCP lifecycle roles |\n| Connector implementation | aip-connector | Product-neutral connector traits and error contracts |\n| Fleet data plane | aip-connector-registry, aip-connector-host, aip-connector-remote | Catalog, isolated host, route selection, and remote dispatch |\n| Fleet lifecycle | aip-connector-admission, aip-connector-orchestration, aip-connector-control-plane, aip-connector-host-bootstrap | Verified admission, platform-neutral rollout, restricted lifecycle service, and host process shell |\n| PostgreSQL persistence | aip-storage-postgres, aip-connector-registry-postgres | Runtime state and normalized fleet registry state |\n| Testing | aip-testkit, aip-conformance | Deterministic fixtures and conformance checks |\n\nDirect dependencies still use the same exact source revision. Do not combine\ndifferent AIP source revisions in one dependency graph unless a documented\ncompatibility procedure explicitly permits it.\n7. Keep legacy full out of new applications\n\nfull-core is the broad product-neutral feature group in the facade. A source\ngate follows every feature it enables and rejects the graph if a product\nconnector feature or dependency becomes reachable.\n\nfull has a different purpose. The facade source labels it a legacy\ncompatibility feature group. It adds a fixed set of product connector features\nto full-core, so it increases coupling and does not represent the current\npublic connector catalog. New core consumers should use full-core, role\nfeatures, or direct role crates. Add only the product dependency owned by the\nartifact.\n\nTo migrate an application away from full:\n1. replace full with full-core or a smaller explicit feature list;\n2. run cargo check once to resolve the changed graph and identify imports that\n   depended on product code;\n3. add only the required product connector dependency through its documented\n   integration boundary;\n4. inspect the manifest and lockfile diff, then run cargo check --locked and\n   cargo tree --locked -e features against the reviewed result.\n\nThe repository's registered examples still declare required-features =\n[\"full\"] at the reviewed revision. Running one of those exact examples inside\nthe source workspace may therefore require the legacy flag:\n\ncargo run --locked -p aip --example minimal-agent --features full\n\nThat requirement belongs to the repository example metadata. It is not a\nrecommended dependency choice for a new application, and the authoring pass for\nthis page did not execute the command.\n8. Review and narrow the change\n\nBefore merging a dependency change, inspect both the declared and resolved\nsurface:\n\ncargo check --locked\ncargo tree --locked -e features\ngit diff -- Cargo.toml Cargo.lock\n\nConfirm that:\n• the dependency resolves from the approved source and revision;\n• full is absent unless an exact repository compatibility task requires it;\n• every enabled facade feature belongs to the component's declared role;\n• product connector packages appear only when explicitly owned by that artifact;\n• the change contains no credential, internal endpoint, or local absolute path;\n• compilation is reported as compilation evidence, not conformance or runtime\n  evidence.\n\nIf a feature is unnecessary, remove it from Cargo.toml, regenerate the\nlockfile, and repeat the checks. No runtime rollback is required for the\nsemantic example because it performs no external operation. Existing Cargo\nbuild artifacts do not need to be deleted to narrow the dependency declaration.\n\nResolve common failures\n\n| Symptom | Likely cause | Bounded action |\n\n| Cargo cannot find aip in a registry | The manifest used registry version syntax for a package that is publish = false at this revision | Use the pinned Git source or an approved vendored path |\n| Cargo rejects the active toolchain | The compiler is older than the workspace minimum | Select Rust 1.88 or newer and rerun cargo check --locked |\n| An import such as aip::gateway is missing | Its facade feature is not enabled | Add only the owning feature and inspect the feature tree |\n| Product connector packages appear unexpectedly | full or a direct product dependency is enabled | Replace full, then trace the remaining product dependency with cargo tree |\n| A repository example refuses to build without full | Its registered metadata still requires the compatibility feature group | Use full only for that exact example; do not copy it into the application manifest |\n| The dependency graph is much larger than expected | full-core or a high-level feature selected more roles than the component needs | Replace it with the smallest task-specific features or direct role crates |\n| Validation succeeds but dispatch later fails | Semantic validation does not authenticate, authorize, admit, route, or execute | Inspect the gateway or endpoint boundary that owns the failed stage |\n\nDependency inspection and semantic validation are read-only with respect to\nprovider state. They do not justify retrying an ambiguous provider mutation.\n\nRelated documentation\n• Start with Install AIP (../getting-started/installation.md) to choose the\n  correct source artifact and binary boundary.\n• Read How AIP works (../getting-started/how-aip-works.md) before embedding\n  protocol roles in one process.\n• Use Capabilities and contracts (../concepts/capabilities.md) to interpret the\n  capability placed in an action.\n• Read Profiles, transports, and connectors (../concepts/profiles-and-connectors.md)\n  before selecting compatibility or connector modules.\n• Follow Use native AIP (use-native-aip.md) when a client should call a running\n  endpoint instead of embedding the SDK.\n"
  },
  "integrity": {
    "algorithm": "sha256",
    "sourceDigest": "0b42e3b17fa8d145afd85efa91eb3332aebd4f23587d4b6f8a90c6e81896941c"
  }
}