Pin the OCSF mapping to 1.9.0 and use OCSF's class names

[rocklambros]

What changed

ocsf-mapping.json now pins OCSF 1.9.0 and uses OCSF's own class captions, as Bar decided on #121. Class 5001 is "Device Inventory Info" and 6002 is "Application Lifecycle" at every OCSF release, so the agbom/* rows and the five 6002 rows were mislabeled. The class numbers already meant these classes, so only the names change. steps/skillRegister, agbom/snapshot and agbom/changed gain "activity_id": 2 (Collect), because OCSF requires activity_id on every event. decision_class.required_fields names finding_info, the object Detection Finding defines, in place of finding.title and finding.uid. The class tables and examples in events.md and extend_ocsf.md follow.

Reviewers are @bar-capsule, @afogel and @artmaro, and one approval lands this. Bar and Ariel lead the Spec workstream, so the proposals below need an answer from one of them first. After that, any one of the three can approve.

Which issue does this implement

Closes #121

• This is an editorial correction (typo, grammar, link, formatting) with no change in meaning, so it needs no issue

Base branch

• integration, because this touches the specification, schemas, a reference implementation, an adapter, tests, or CI
• main, because every changed path is on the documentation lane allowlist in CONTRIBUTING.md

Type of change

• Specification change (schema, hooks, events, AgBOM)
• Reference implementation or adapter
• Documentation
• Tooling or CI
• Governance (licensing, security policy, contributor docs)

Specification changes

• I opened a Discussion before this PR
• Schema changes validate against the JSON Schema spec
• I described the impact on downstream implementers below

Breaking for implementers? Only for a deployment that copied the old captions into class_name. Every class_uid is unchanged. A deployment emitting OCSF for steps/skillRegister or agbom/* should now set activity_id 2, which OCSF already required.

No Discussion was opened. The decisions are on #121.

Decided by a Spec lead. Bar's decision (6059681393) covers the 1.9.0 pin, the 5001 and 6002 captions, the version strings, and finding_info in required_fields.

Proposed by me, for a Spec lead to confirm. My notes on #121 (6117227902) add two things Bar's list does not include. steps/skillRegister, agbom/snapshot and agbom/changed get activity_id 2 (Collect), because OCSF requires an activity_id and 5001 offers only 1 (Log) and 2 (Collect). The skillRegister note no longer says "modeled as Inventory Info". Please say if you'd rather have 1 (Log).

I ran the three examples in extend_ocsf.md once, by hand, through https://schema.ocsf.io/api/v2/validate, which validated against its default schema version, 1.9.0. That check does not look inside unmapped, and nothing in CI repeats it. Before this change, each failed on missing required attributes and warned about the 1.5.0 version. The 5001 example also warned about its caption. After it, the deny example (2004) and the AgBOM example (5001) validate with no errors or warnings. They gained type_uid, plus metadata.product and device.type_id on the 5001 example. The tool call example (1007) still fails on one error, a missing device. That is the class-fit problem in #235, so it stays open there.

Not changed

• The allow sentence in decision_class.description stays for [Docs] Trace events page omits the OCSF class for allow that ocsf-mapping.json defines #198.
• evidences and verdict_id in decision_class.required_fields stay for [Bug]: acs.decision trace event cannot carry reason_codes, policy_references, cited_provenance_ids, or chain_hash, so replay from the trace alone is not possible #228, which decides what goes in them.
• The OCSF examples in docs/acs.md and implementation_examples.md stay for [Docs] OCSF examples in acs.md and implementation_examples.md contradict the normative mapping #234.
• The rows that still lack an activity_id (the 6002, 1007 and 6005 rows) belong with [Bug] ACS events can't fill the fields their OCSF classes require #235. Application Lifecycle's activities are install, remove, start, stop and similar, which a user message does not fit. Choosing an id there is a class-fit decision, not a rename.

Merging

• Merge with an explicit squash message: the title, the closing line from the issue section above, a blank line, and the Signed-off-by lines. The repository squashes with the PR body by default, which drops the sign-off.
• If Add a Go Guardian reference implementation #169 (the Go Guardian) has merged first, run cd reference-implementations/agt-go && go generate ./internal/schema and commit the result to this branch before merging.

I tested this

• I synced my branch with the base branch before opening this
• uv run pytest -v passes on my machine
• uv run mkdocs build --strict passes on my machine

pytest reports 907 passed and 1 skipped. The hook taxonomy guard passes unchanged, because no steps/* key changes.

Checklist

• Commits are signed off with git commit -s (required by the DCO)
• Prose follows STYLE.md
• No secrets, tokens, or internal URLs in the diff

Security

• This change has no security impact

[github-actions]

This pull request's description says it closes #121, which is on the project roadmap. When it merges, GitHub closes that issue and the roadmap counts it as delivered. Please confirm the change delivers the whole issue before merging.

[bar-capsule]

@rocklambros just noting that this drops the title: finding.title was required before, and finding_info alone doesn't require one (OCSF only recommends title). Not dramatic, but not sure it's intended.

[rocklambros]

Good catch, that wasn't intended. finding_info.title is back in required_fields in 79407d9, so the title stays required the way finding.title was.

[rocklambros]

Merged with the admin bypass. @bar-capsule approved 5588f20 on October 13. The only change since is 79407d9, the one-line fix from her review that puts finding_info.title back in required_fields, and that push dismissed the approval. CI was green on the merged head.