docs: OTel↔OCSF audit crosswalk + drafted replies (OTel #2409, OCSF Slack)

CHANGELOG.md

@@ -12,6 +12,7 @@ Format follows [Keep a Changelog](https://keepachangelog.com/en/1.1.0/).
 - **Cisco Slack reply trimmed — Teryl leads the MCP-gap filing, Jeff co-authors.** Two facts landed after #439 merged: Teryl asked to take the upstream filing of the MCP-gap issue with Jeff as co-author (agreed, superseding the issues draft's "Lead: Fred" note), and Teryl is in CoSAI but not in the OCSF community Slack. The reply in `docs/ocsf-slack-mcp-reply-draft.md` is trimmed accordingly: the field-level sketch of the `tool` object and the "happy to share the full draft" offer are gone — proposal details are the author's to reveal, and a channel discussion the author can't join helps nobody. What remains is the connector role: confirm the production shape (6003 + `ai_operation` + reference bundle), name the gap in one paragraph, promise to ping the thread when the issue files so Cisco's use case lands on the record, and the #1724 cross-link. Header records the ownership decision. Docs only — no product impact.
 
 ### Added
+- **OTel↔OCSF audit crosswalk drafted — the #2409 offer becomes an artifact before the reply promising it is even posted.** Antoine Toulme (OTel Collector maintainer, Splunk) answered the crosswalk offer in [open-telemetry/community#2409](https://github.com/open-telemetry/community/pull/2409) with "Interested in this," pointing at his stale-closed OCSF-connector draft (opentelemetry-collector-contrib#47461) — a connector that died for lack of exactly this mapping. `docs/otel-ocsf-audit-crosswalk/` is the deliverable: a field-level mapping (envelope + integrity constructs) between the apeirora audit data model (`auditing`@`663d809`, includes the `578b930` revisions our review prompted) and the OCSF 1.9.0 `record_integrity`/`attestation` shape, with requirement levels verified against both schemas — including the tell that OCSF's `prev_event.uid` is *required* while its `fingerprint` is optional, the exact inverse of OTel's hash-only chain pointer. Eight documented non-1:1 seams, each with a transform rule (canonicalization mandated-vs-declared is the deepest: a translated signature stays bound to its origin-shape bytes, so the transform must carry origin digest + declared scheme or the proof degrades to noise), and four one-attribute spec asks that would make the mapping lossless (three OTel, one already filed as ocsf-schema#1709). Backed by executable evidence, not prose: `derive_otel_vectors.py` (stdlib-only) derives OTel `AuditRecord`s from the production OCSF export and re-verifies chain linkage *across the transform* — 235/235 links on the full 236-event export, genesis by omission — and the committed 7-record sample chains against the OCSF bundle record-for-record, signatures verifiable against the same public JWKS. Docs only — no product impact.
 - **OCSF Slack: Cisco asked our exact question — reply drafted, and Issue 1 gets its demand signal.** Mitchell Wasson (Cisco) asked the OCSF channel how to represent AI agent logs (Codex, Claude) in OCSF and which event type fits MCP calls, guessing API Activity — which is precisely our production shape and precisely the gap Issue 1 of the CoSAI WS4 issues draft has been holding in REVIEW since July (the generic `tool` object with `primitive`/`type` axes and `mcp` sub-block, Teryl-aligned against CMF). `docs/ocsf-slack-mcp-reply-draft.md` is the paste-ready reply: confirms 6003 + `ai_operation` from production, points at the public reference bundle as a poke-able example, names the MCP-identity gap honestly (tool name smuggled into `api.operation`, server/resource/prompt unmapped), sketches the drafted `tool` object, cross-links ocsf-schema#1724 as the schema-side complement, and offers to share the full draft. Strategic note recorded in the header: a Cisco producer asking in public is the multi-producer justification for filing Issue 1 upstream — with AI Identity shipping it, IBM/CMF aligned, and Cisco asking, the proposal stops being one vendor's wish. Docs only — no product impact. (#436, #437, #438 are the same day's OCSF/OTel thread.)
 - **OTel Audit Logging initiative: supporter acceptance drafted — the standards footprint grows a second leg.** Hilmar Falkenberg (SAP) incorporated our two OCSF observations into the Audit Logging spec draft (apeirora/opentelemetry-specification@578b930: `audit.sequence.stream_id` chain scoping, `audit.integrity.signer` producer-vs-collector split) and invited us to join [open-telemetry/community#2409](https://github.com/open-telemetry/community/pull/2409) as a supporter. `docs/otel-2409-draft-comment.md` is the paste-ready acceptance, scoped deliberately to the OCSF↔OTel intersection: three production lessons verified absent from 578b930 (chain pointers need a resolvable record id, not only a hash; genesis omits the prev pointer — never a sentinel; signatures need a declared canonicalization or verification degrades to trusting the producer), the offer of a written OCSF↔OTel crosswalk (`stream_id`↔`chain_uid`, signer split↔`authority_uid`, chain pointer↔`prev_event`), and both public artifacts offered as test vectors (production reference bundle + stdlib-verifiable sample). Context recorded in the draft's header: SAP-led (sponsors SAP + Microsoft), developed in the `apeirora` org (SAP's IPCEI-CIS EU sovereign-cloud program) after the OTel GC declined formal SIG status Oct 2025 — supporter is the lightest-weight standards commitment available, and the crosswalk is the durable role. Docs only — no product impact.
 - **PR-shaped OCSF class draft for ocsf-schema#1724 — AI Agent Trust Inventory — ready to hand to Dave the moment the co-drafting offer is taken up.** `docs/ocsf-1724-class-draft/` lays the files out exactly as they would land in the ocsf-schema repo: a thin Discovery class (`events/discovery/ai_agent_trust_inventory.json`, uid 24 — first free above `cloud_resources_inventory_info`'s 23 — with a Log/Collect/Change activity enum whose `Change` caption carries the admission-control timing contract), five objects (`agent_config_declaration`, `agent_execution_params`, a single typed `agent_artifact` with a Model Weights/Adapter/Tool Schema/Policy Bundle/Charter enum instead of per-kind arrays, `ai_sampling_params`, `agent_credential` — references and scopes only, structurally incapable of carrying material), and a `dictionary-additions.json` fragment listing every new attribute, all collision-checked by name against ocsf-schema `main` 2026-08-11. Three verified conventions shaped the design: `record_integrity` is attached at `base_event`, so the per-emission chaining the issue asks for needs zero schema mechanics; `charter` already exists in the dictionary as a `file` object, so the charter digest rides `ai_agent.charter.hashes[]` natively; and `agent_artifact` introduces no new dictionary attributes at all. The worked sample (`docs/cosai-ws4-ocsf-mapping/trust-base-inventory-sample/`) is regenerated in the drafted shape — `declared_configuration`/`executed_parameters` with the typed `artifacts` array and credential `type_id`s — so the public sample Dave's issue thread links to and the class draft are one shape; `build_sample.py --verify` re-verifies the chain, digests, and event-3 divergence after the regen. The draft README carries the design rationale and six open questions for the WG (naming, enum-merge semantics, float attributes, the cross-object required-ness of loaded artifacts, TEE reference posture). Not metaschema-validated here — that needs the files inside a real ocsf-schema clone, which is step one when this graduates to an actual PR branch. Docs only — no product impact.