# OASF export (T1 / OASF-01)

Read-only export of an already-public AgentPeer card as an [OASF](https://github.com/agntcy/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.