{ "schemaVersion": "1.0", "title": "AIP code of conduct", "description": "The Agent Interoperability Protocol project is committed to a professional, inclusive, and safe technical community. Everyone who participates in a project space must respect other people and the users affected by protocol, security, connec", "canonical": "https://getaip.org/docs/project/code-of-conduct", "route": "/docs/project/code-of-conduct", "source": "CODE_OF_CONDUCT.md", "protocol": "Agent Interoperability Protocol", "protocolVersion": "1.0", "section": "Project and Releases", "documentType": "Project policy", "language": "en", "revision": { "lastReviewedRevision": "97be86e9efedf07ecf1783b03800f683f107fb04", "documentationSourceRevision": "9192fef3695ad294994f2712f6d156241e5e92fb", "basis": "frontmatter" }, "downloads": { "md": "/docs/download/project/code-of-conduct.md", "txt": "/docs/download/project/code-of-conduct.txt", "json": "/docs/download/project/code-of-conduct.json", "pdf": "/docs/download/project/code-of-conduct.pdf" }, "content": { "format": "text/markdown", "markdown": "---\ntitle: AIP code of conduct\ndescription: Participate respectfully, report concerns privately, and understand the project's moderation process\nkind: policy\naudience: contributor\nappliesTo: \"1.x\"\nwritingStandard: \"aip-docs/1.0\"\nlastReviewedRevision: \"97be86e9efedf07ecf1783b03800f683f107fb04\"\n---\n\n# AIP code of conduct\n\nThe Agent Interoperability Protocol project is committed to a professional,\ninclusive, and safe technical community. Everyone who participates in a\nproject space must respect other people and the users affected by protocol,\nsecurity, connector, and deployment decisions.\n\nThis policy applies to contributors, maintainers, reviewers, operators,\nspeakers, representatives, and guests. Participation is conditioned on\nfollowing it.\n\n## Expected behavior\n\nParticipants are expected to:\n\n- discuss technical claims with specific reasoning while respecting\n uncertainty and different experience levels;\n- critique code, designs, evidence, and decisions without attacking the person\n who proposed them;\n- communicate directly, patiently, and constructively;\n- make room for people with different backgrounds, identities, abilities,\n locations, and levels of familiarity with the project;\n- respect consent, personal boundaries, privacy, and confidential information;\n- disclose relevant technical limitations, conflicts of interest, and security\n impact;\n- accept correction and update claims when stronger evidence becomes\n available;\n- follow a maintainer's bounded moderation or incident-safety direction;\n- take responsibility for harm and participate in reasonable repair when\n possible.\n\n## Unacceptable behavior\n\nThe following behavior is not acceptable:\n\n- harassment, threats, intimidation, stalking, or incitement of violence;\n- discriminatory language or conduct based on identity or protected\n characteristics;\n- personal insults, demeaning comments, sexualized content, or unwelcome sexual\n or personal attention;\n- deliberate misgendering, outing, or publication of private information\n without explicit permission;\n- sustained disruption of reviews, issues, releases, events, or community\n communication;\n- coercion, impersonation, or misuse of project authority;\n- knowingly false technical, security, conformance, or qualification claims;\n- disclosure of credentials, customer data, embargoed vulnerabilities, private\n report details, or protected deployment information;\n- retaliation against a person who reports or helps review a concern in good\n faith;\n- deliberately false, fabricated, or retaliatory reports.\n\nA good-faith report is not a violation merely because it is incomplete,\nmistaken, or cannot be substantiated.\n\n## Keep technical disagreement rigorous and respectful\n\nFirm technical review is part of the project. Maintainers and reviewers may\nreject a change, request evidence, limit a risky operation, or correct an\nunsupported claim. A decision that someone disagrees with is not by itself a\nconduct violation.\n\nTechnical authority does not permit harassment, humiliation, retaliation, or\nselective enforcement. Apply the same evidence and behavior standard to\nmaintainers, established contributors, and newcomers.\n\n## Scope\n\nThis policy applies in:\n\n- repositories, reviews, issues, and project-managed automation;\n- project-operated chat, email, meetings, events, and support channels;\n- release, conformance, qualification, incident, and disclosure activities;\n- public situations where a participant is formally representing the project;\n- private communication that directly affects safety or participation in a\n project space.\n\nProject maintainers can moderate project-controlled spaces and can ask a\nrepository host or relevant organization to act within its authority. This\npolicy does not give maintainers authority over unrelated private life,\nexternal communities, emergency response, employment disputes, or legal\nproceedings.\n\n## Report a conduct concern\n\nSend conduct reports privately to with the subject prefix\n`[CONDUCT]`. Do not place personal, safety, credential, customer, or private\nreport information in a public issue or review.\n\nIf there is immediate danger, contact the appropriate local emergency service\nor the platform's urgent-safety channel. The AIP project is not an emergency\nservice.\n\nReport a software vulnerability through the separate process in\n[SECURITY.md](SECURITY.md). Use `[CONDUCT]` when the concern is about behavior,\nincluding behavior that occurred during vulnerability handling.\n\nInclude what is available and safe to share:\n\n- the project space, approximate date and time, and people involved;\n- what happened and how it affected participation or safety;\n- relevant links, messages, screenshots, or witnesses;\n- any immediate safety or privacy concern;\n- a requested communication method or protective measure, if any;\n- whether a maintainer or reviewer has a conflict of interest.\n\nYou do not need to investigate, confront the reported person, collect every\nrecord, or prove the concern before reporting it. Preserve original records\nwhen safe, and avoid gathering unrelated personal information.\n\n## How reports are handled\n\nThe project will use this process:\n\n1. A maintainer acknowledges the report when practical and identifies the next\n communication step. The project does not publish a fixed response-time SLA.\n2. Anyone named in the report or unable to act impartially must recuse from the\n decision.\n3. The reviewer limits access to people needed to assess safety, facts,\n conflicts, and possible action.\n4. The reviewer may ask the reporter, reported person, or witnesses for\n relevant context without requiring unsafe contact between them.\n5. Temporary restrictions may be used while reviewing an immediate safety,\n privacy, retaliation, or disruption risk. A temporary measure is not a\n final finding.\n6. The reviewer evaluates severity, impact, frequency, context, prior relevant\n behavior, cooperation, and risk of recurrence.\n7. When action is taken, affected participants receive the decision and the\n information they need to follow it, subject to privacy and safety limits.\n\nThe project cannot promise anonymity or absolute confidentiality. Report\ninformation will be limited to a need-to-know basis, but disclosure may be\nrequired for safety, legal obligations, repository-host action, or a fair\nreview. When permitted and safe, the reviewer will tell the reporter before a\nmaterial disclosure.\n\nRecords must contain only information needed for review, enforcement,\nfollow-up, or required obligations. They must not be reused for unrelated\npurposes.\n\n## Enforcement\n\nMaintainers may apply one or more proportionate actions:\n\n1. a clarification, correction, or request to stop;\n2. removal or editing of harmful content;\n3. a private or formal warning with stated expectations;\n4. a temporary restriction from a discussion, review, role, event, or project\n space;\n5. removal of project permissions or representative status;\n6. permanent removal from project-controlled spaces;\n7. escalation to the repository host, service provider, relevant organization,\n or appropriate authority when necessary.\n\nAn enforcement notice should identify the policy boundary, required action,\neffective scope, duration when temporary, and available appeal path. It need\nnot disclose another person's private information or the complete report.\n\nMaintainers may reject or remove contributions independently of conduct\nenforcement when they are unsafe, out of scope, technically unsupported, or\nnot ready. Do not describe an ordinary technical rejection as disciplinary\naction unless this policy is actually invoked.\n\n## Appeal a conduct decision\n\nSend an appeal to with the subject prefix `[CONDUCT APPEAL]`.\nIdentify the decision and explain a material factual error, process conflict,\ndisproportionate action, or relevant new information. Disagreement alone does\nnot require a different outcome.\n\nAn uninvolved maintainer should review the appeal when one is available. If no\nunconflicted maintainer is available, the project may ask the relevant\norganization or repository host to review the part within its authority. The\nproject does not guarantee an external reviewer or a particular appeal\noutcome.\n\nProtective measures remain in effect during an appeal unless the reviewer\nchanges them.\n\n## Maintainer responsibility\n\nMaintainers are subject to this policy. They are responsible for applying it\nconsistently, documenting decisions proportionately, protecting report data,\naddressing retaliation, disclosing conflicts, and correcting enforcement when\nan appeal identifies a material error.\n\nUsing private report information for unrelated technical, commercial, or\npersonal purposes is itself unacceptable behavior.\n\n## Related documentation\n\n- [Contributing to AIP](CONTRIBUTING.md)\n- [Security policy](SECURITY.md)\n- [Licensing and usage terms](docs/reference/licensing.md)\n", "text": "AIP code of conduct\n\nThe Agent Interoperability Protocol project is committed to a professional,\ninclusive, and safe technical community. Everyone who participates in a\nproject space must respect other people and the users affected by protocol,\nsecurity, connector, and deployment decisions.\n\nThis policy applies to contributors, maintainers, reviewers, operators,\nspeakers, representatives, and guests. Participation is conditioned on\nfollowing it.\n\nExpected behavior\n\nParticipants are expected to:\n• discuss technical claims with specific reasoning while respecting\n uncertainty and different experience levels;\n• critique code, designs, evidence, and decisions without attacking the person\n who proposed them;\n• communicate directly, patiently, and constructively;\n• make room for people with different backgrounds, identities, abilities,\n locations, and levels of familiarity with the project;\n• respect consent, personal boundaries, privacy, and confidential information;\n• disclose relevant technical limitations, conflicts of interest, and security\n impact;\n• accept correction and update claims when stronger evidence becomes\n available;\n• follow a maintainer's bounded moderation or incident-safety direction;\n• take responsibility for harm and participate in reasonable repair when\n possible.\n\nUnacceptable behavior\n\nThe following behavior is not acceptable:\n• harassment, threats, intimidation, stalking, or incitement of violence;\n• discriminatory language or conduct based on identity or protected\n characteristics;\n• personal insults, demeaning comments, sexualized content, or unwelcome sexual\n or personal attention;\n• deliberate misgendering, outing, or publication of private information\n without explicit permission;\n• sustained disruption of reviews, issues, releases, events, or community\n communication;\n• coercion, impersonation, or misuse of project authority;\n• knowingly false technical, security, conformance, or qualification claims;\n• disclosure of credentials, customer data, embargoed vulnerabilities, private\n report details, or protected deployment information;\n• retaliation against a person who reports or helps review a concern in good\n faith;\n• deliberately false, fabricated, or retaliatory reports.\n\nA good-faith report is not a violation merely because it is incomplete,\nmistaken, or cannot be substantiated.\n\nKeep technical disagreement rigorous and respectful\n\nFirm technical review is part of the project. Maintainers and reviewers may\nreject a change, request evidence, limit a risky operation, or correct an\nunsupported claim. A decision that someone disagrees with is not by itself a\nconduct violation.\n\nTechnical authority does not permit harassment, humiliation, retaliation, or\nselective enforcement. Apply the same evidence and behavior standard to\nmaintainers, established contributors, and newcomers.\n\nScope\n\nThis policy applies in:\n• repositories, reviews, issues, and project-managed automation;\n• project-operated chat, email, meetings, events, and support channels;\n• release, conformance, qualification, incident, and disclosure activities;\n• public situations where a participant is formally representing the project;\n• private communication that directly affects safety or participation in a\n project space.\n\nProject maintainers can moderate project-controlled spaces and can ask a\nrepository host or relevant organization to act within its authority. This\npolicy does not give maintainers authority over unrelated private life,\nexternal communities, emergency response, employment disputes, or legal\nproceedings.\n\nReport a conduct concern\n\nSend conduct reports privately to with the subject prefix\n[CONDUCT]. Do not place personal, safety, credential, customer, or private\nreport information in a public issue or review.\n\nIf there is immediate danger, contact the appropriate local emergency service\nor the platform's urgent-safety channel. The AIP project is not an emergency\nservice.\n\nReport a software vulnerability through the separate process in\nSECURITY.md (SECURITY.md). Use [CONDUCT] when the concern is about behavior,\nincluding behavior that occurred during vulnerability handling.\n\nInclude what is available and safe to share:\n• the project space, approximate date and time, and people involved;\n• what happened and how it affected participation or safety;\n• relevant links, messages, screenshots, or witnesses;\n• any immediate safety or privacy concern;\n• a requested communication method or protective measure, if any;\n• whether a maintainer or reviewer has a conflict of interest.\n\nYou do not need to investigate, confront the reported person, collect every\nrecord, or prove the concern before reporting it. Preserve original records\nwhen safe, and avoid gathering unrelated personal information.\n\nHow reports are handled\n\nThe project will use this process:\n1. A maintainer acknowledges the report when practical and identifies the next\n communication step. The project does not publish a fixed response-time SLA.\n2. Anyone named in the report or unable to act impartially must recuse from the\n decision.\n3. The reviewer limits access to people needed to assess safety, facts,\n conflicts, and possible action.\n4. The reviewer may ask the reporter, reported person, or witnesses for\n relevant context without requiring unsafe contact between them.\n5. Temporary restrictions may be used while reviewing an immediate safety,\n privacy, retaliation, or disruption risk. A temporary measure is not a\n final finding.\n6. The reviewer evaluates severity, impact, frequency, context, prior relevant\n behavior, cooperation, and risk of recurrence.\n7. When action is taken, affected participants receive the decision and the\n information they need to follow it, subject to privacy and safety limits.\n\nThe project cannot promise anonymity or absolute confidentiality. Report\ninformation will be limited to a need-to-know basis, but disclosure may be\nrequired for safety, legal obligations, repository-host action, or a fair\nreview. When permitted and safe, the reviewer will tell the reporter before a\nmaterial disclosure.\n\nRecords must contain only information needed for review, enforcement,\nfollow-up, or required obligations. They must not be reused for unrelated\npurposes.\n\nEnforcement\n\nMaintainers may apply one or more proportionate actions:\n1. a clarification, correction, or request to stop;\n2. removal or editing of harmful content;\n3. a private or formal warning with stated expectations;\n4. a temporary restriction from a discussion, review, role, event, or project\n space;\n5. removal of project permissions or representative status;\n6. permanent removal from project-controlled spaces;\n7. escalation to the repository host, service provider, relevant organization,\n or appropriate authority when necessary.\n\nAn enforcement notice should identify the policy boundary, required action,\neffective scope, duration when temporary, and available appeal path. It need\nnot disclose another person's private information or the complete report.\n\nMaintainers may reject or remove contributions independently of conduct\nenforcement when they are unsafe, out of scope, technically unsupported, or\nnot ready. Do not describe an ordinary technical rejection as disciplinary\naction unless this policy is actually invoked.\n\nAppeal a conduct decision\n\nSend an appeal to with the subject prefix [CONDUCT APPEAL].\nIdentify the decision and explain a material factual error, process conflict,\ndisproportionate action, or relevant new information. Disagreement alone does\nnot require a different outcome.\n\nAn uninvolved maintainer should review the appeal when one is available. If no\nunconflicted maintainer is available, the project may ask the relevant\norganization or repository host to review the part within its authority. The\nproject does not guarantee an external reviewer or a particular appeal\noutcome.\n\nProtective measures remain in effect during an appeal unless the reviewer\nchanges them.\n\nMaintainer responsibility\n\nMaintainers are subject to this policy. They are responsible for applying it\nconsistently, documenting decisions proportionately, protecting report data,\naddressing retaliation, disclosing conflicts, and correcting enforcement when\nan appeal identifies a material error.\n\nUsing private report information for unrelated technical, commercial, or\npersonal purposes is itself unacceptable behavior.\n\nRelated documentation\n• Contributing to AIP (CONTRIBUTING.md)\n• Security policy (SECURITY.md)\n• Licensing and usage terms (docs/reference/licensing.md)\n" }, "integrity": { "algorithm": "sha256", "sourceDigest": "9701f1f42d4f22400831cb9478cdcf9e73a8b689ef846e22a2d44c74984ec4b1" } }