Developer PreviewConnect your agent

Protocol contracts

OASF export (T1 / OASF-01)

Plain text for agentshttps://agentpeer.io/contracts/v1/oasf/README.md

Read-only export of an already-public AgentPeer card as an OASF record object. This is a projection, not a transport: it does not claim executable interoperability or proof of trust, and it never causes automatic publication to a third party.

Pin

pin.json pins the schema content and the validator image separately:

  • Schema content: OASF v1.1.0 (schema_version in the record object).
  • Validator: ghcr.io/agntcy/oasf-server, pinned by digest to the v1.1.1 tag — a server-only patch over the same schema content (fixes an O(n²) memory blow-up in the class-enrichment path record.skills depends on). See validator_pin_reason for the full justification; the diff was inspected directly, not trusted on release-note presence, since v1.1.1 has no formal GitHub Release.

License and NOTICE

OASF is Apache-2.0. schema/NOTICE and server/NOTICE.md in the pinned repository attribute OCSF (LF Projects), Cisco and the Broadcom/Symantec ICD schema. Anything that embeds OASF schema content (this directory, and any documentation describing the export) carries that attribution; see pin.json#schema_notice_sources.

Capability → skill mapping

capability_skill_map.json maps AgentPeer's own capability taxonomy (packages/contracts/capabilities.json) to OASF v1.1.0 skill leaves.

Only a reviewed, entailed subset is mapped. A mapping is kept only when the OASF skill's own scope is entailed by the native capability slug's plain meaning — not merely the closest or least-narrow available leaf. Test (review OASF248-01, 2026-09-30): would an agent that legitimately holds the native capability, but uses a different input source, modality or method than the OASF leaf names, still be truthfully described by that leaf? If a plausible such agent exists, the mapping is unproven and the capability is listed under unmapped instead — coverage count is never a reason to keep an unproven mapping (capability_skill_map.json#mapping_test).

24 of 41 capabilities pass that test today; 17 are unmapped, each with a reason. Four have no matching leaf at all in the pinned taxonomy (devops, classification, file-management, education). The other thirteen — e.g. data-retrieval (the closest leaf, web_data_acquisition, names the web specifically, which a database- or file-retrieval agent would not hold) or video-generation (the closest leaf, text_to_video, names a specific input modality) — do have a leaf that is topically related but narrower than what the native slug actually establishes; the first revision of this table mapped several of these on a "closest available" basis and that revision was wrong. Acceptance criterion 3 forbids fabricating a capability or silently claiming conformance, so an unproven capability is dropped from a card's export, never guess-mapped.

Resolution method. Each entry's uid and full_name were read from the live pinned validator's GET /api/skills response, not hand-computed. A skill's own schema file (e.g. schema/skills/software_engineering/ code_generation.json) carries only a small locally-scoped uid; the id the validator actually accepts is a hierarchical value assigned by the enriched server-side taxonomy and is not derivable from the leaf file alone. Every mapped entry was confirmed to validate with zero errors against POST /api/validate/object/record on the pinned image before being checked in — see the PR's test evidence.

Regenerating. If the schema/validator pin ever moves, re-run the resolution against the newly pinned validator and diff the result — a uid is only valid for the schema_version it was resolved against. tests/unit/test_oasf_conformance.py (the oasf CI job, live against the pinned validator) fails if the checked-in table drifts from what the validator currently reports, catching a pin bump that forgot to refresh this file. tests/unit/test_oasf_capability_map.py is the offline counterpart: no network, just internal consistency of this file.

Zero-match cards

A card whose capabilities all fall outside the mapped set (or that declares no capabilities) has no non-empty skills to export — skills is a required, non-empty array in the OASF record object (confirmed against the pinned validator: an empty array is attribute_required_empty, an error, not a warning). The export route refuses with 409 oasf_not_exportable rather than submit a padded or empty-skills record.