Conformance and compatibility
The SDKs target PAP draft 0.1. Draft changes may be incompatible, so support
is expressed as a protocol profile rather than inferred from package version.
Compatibility rules​
- Reject an unsupported protocol major version.
- Accept a later minor version while ignoring unknown fields.
- Ignore extensions that are not supported.
- Preserve required security checks outside replaceable plugins.
- Keep Python and TypeScript behavior aligned through shared JSON fixtures.
Evidence in this repository​
| Artifact | Purpose |
|---|---|
protocol/requirements.yaml | Maps normative requirements to implementation status. |
protocol/fixtures/ | Shared positive and negative wire examples. |
personal_agent_protocol/__tests__/ | Python behavior and security tests. |
src/__tests__/ | TypeScript validation and discovery tests. |
protocol/fixtures/conformance/ | The conformance cases: the ones each SDK decides alone (check) and the ones run against a company. |
personal_agent_protocol/conformance.py | The Python conformance runner (pap conformance run). |
src/__tests__/support/conformance.mjs | The same cases as the TypeScript personal agent. |
Every language pairing​
Both runners play a personal agent against a company's base URL over real TCP and TLS, with a driver for what only the user or a demo company's operator can do. Each of the four pairings runs every positive, negative and recovery case:
| Personal agent | Company | Where |
|---|---|---|
| Python | Python | test_conformance.py |
| Python | TypeScript | test_cross_language.py (the TypeScript company on node:https) |
| TypeScript | Python | test_cross_language.py (the Python company with served_over_tls) |
| TypeScript | TypeScript | conformance-pairing.test.mjs |
Every pairing passes every case, with no skips: both personal agents fetch
Bearer tokens for MCP (bearer_for_mcp, bearerForMcp) and call tools with
McpClient, and both join a browser of their own (Python browser_http,
TypeScript browserFetch, each with its own cookie jar) to the Session to
open and confirm operation pages on both reference companies. A runner given no
browser skips the website cases, saying so.
With PAP_CONFORMANCE_REPORTS=<dir>, each writes its JSON report (schema 1),
and scripts/conformance_report.py <dir> turns them into the
compatibility and conformance report. CI runs
every pairing and checks the committed report; the release workflow publishes
the report of each release as its conformance-report artifact.
Current release gate​
An area is documented as implemented only when its public API exists and its relevant fixtures pass in both applicable SDKs. Partial means safe foundational pieces exist but the end-to-end protocol flow does not. Planned means the documentation may explain the intended integration, but applications cannot depend on an SDK implementation yet.
See Protocol status for the current matrix.