[Docs] OCSF 1.5 renames class 5001 to "Device Inventory Info"; Trace docs still say "Inventory Info" #121

Activity

1. sabasiddique1

   added

   type:docsImprovements or additions to documentationImprovements or additions to documentation

   status:needs-triageNot yet triaged. Applied by the issue formsNot yet triaged. Applied by the issue forms

   on Sep 14, 2026
2. rocklambros

   added this to ACS Project Trackeron Sep 17, 2026
3. github-project-automation

   moved this to Needs triage in ACS Project Trackeron Sep 17, 2026
4. rocklambros

   added this to the Spec and docs fixes for v0.1 milestone on Oct 5, 2026
5. rocklambros

   added

   scope:in-focusFeeds the ninety-day committed outcome. Maintainers onlyFeeds the ninety-day committed outcome. Maintainers only

   status:acceptedIn the backlog. Maintainers onlyIn the backlog. Maintainers only

   and removed

   status:needs-triageNot yet triaged. Applied by the issue formsNot yet triaged. Applied by the issue forms

   on Oct 5, 2026
6. bar-capsule commented on Oct 8, 2026

   

   bar-capsule

   on Oct 8, 2026

   Collaborator

   More actions

   @sabasiddique1 thanks for flagging this! Here are the two decisions you asked for:

   1. Version: let's pin OCSF 1.9.0, the latest release.
   2. Labels: let's use OCSF's official names. I checked every OCSF release, and 5001 was always Device Inventory Info, so there's no older name to keep. 6002 has the same problem: its official name is Application Lifecycle. "Application Activity" is the name of category 6.

   All our class numbers mean the same classes in 1.9.0, so only the names change.
   What to update:

   • class_name for 5001 and 6002 in ocsf-mapping.json
   • the class tables in events.md and extend_ocsf.md, and the 5001 example in extend_ocsf.md
   • the version: "1.5+" becomes 1.9.0 in the mapping description, events.md and extend_ocsf.md. extend_ocsf.md also says 1.5 in the unmapped.acs note and in metadata.version of its three examples.
   • one more thing I found while checking 1.9.0: decision_class.required_fields lists finding.title and finding.uid, but Detection Finding calls that object finding_info. Our deny example in extend_ocsf.md already uses finding_info, so the mapping should match it.

   What to leave for other issues:

   • the allow sentence in decision_class.description - [Docs] Trace events page omits the OCSF class for allow that ocsf-mapping.json defines #198 decides which class allow goes to
   • the OCSF examples in acs.md and implementation_examples.md need a bigger rewrite, so I opened [Docs] OCSF examples in acs.md and implementation_examples.md contradict the normative mapping #234 for them
7. rocklambros

   self-assigned this

   on Oct 12, 2026
8. rocklambros commented on Oct 12, 2026

   

   rocklambros

   on Oct 12, 2026

   Collaborator

   More actions

   Notes for the PR that closes this, from checking #63 against the OCSF schema repository at the v1.0.0, v1.1.0, 1.5.0 and 1.9.0 tags.

   • The name. "Device Inventory Info" is 5001's caption at every tag I checked. "Inventory Info" never is, because inventory_info is only the machine name. After Add the skill lifecycle hooks to the Trace mappings #63, ocsf-mapping.json gives 5001 two class_name values: the agbom/* rows say Inventory Info and steps/skillRegister says Device Inventory Info. This PR renames the agbom/* rows.
   • The skillRegister note. It still says "modeled as Inventory Info, the class agbom/* already uses". Please fix it in the same pass.
   • activity_id. steps/skillRegister, agbom/snapshot and agbom/changed have none, but OCSF requires activity_id on every event. For 5001 the values are 1 Log and 2 Collect. Collect (2) is the closest fit for both a registration and a snapshot.
   • Larger fit questions, for [Bug] ACS events can't fill the fields their OCSF classes require #235. These are not for this PR.
     • 5001 requires a device object ("The device that is being discovered by an inventory process"). Neither a skill registration nor an AgBOM snapshot carries one.
     • 1005 Module Activity requires actor and device (from the system category) and a module. At 1.5.0 that module has a required load_type_id, an OS loader enum.
     • Every existing steps/* row has the same kind of gap, so this belongs with the class-mapping questions in [Bug] ACS events can't fill the fields their OCSF classes require #235.
     • 1.9.0 also adds Software Inventory Info (5020), which has an sbom attribute and may fit agbom/* better.
   • Pinning to 1.9.0. The docs say "OCSF 1.5+", but 1.9.0 changes meaning in two places. It adds Invoke (3) to 1005's activities. It also relaxes module.load_type_id to an at-least-one rule with function_name. If this PR pins 1.9.0, please change the "1.5+" wording in extend_ocsf.md and events.md too.
9. rocklambros

   closed this as completedin #258on Oct 13, 2026
10. github-project-automation

    moved this from In progress to Done in ACS Project Trackeron Oct 13, 2026
11. dtduc-git

    added a commit that references this issue on Oct 14, 2026

    Pin the OCSF mapping to 1.9.0 and use OCSF's class names (GenAI-Secur…

    ...

    This issue will close once commit 1445556 is merged into the 'integration' branch.

    1445556