[imran-siddique]

What changed

decision_class in ocsf-mapping.json gains allow_class: class_uid 6002, class_name "Application Lifecycle", and required_fields naming where the disposition goes (unmapped.acs.decision), plus severity_id, metadata.correlation_uid and the join pair. The evaluator rides in unmapped.acs.metadata, as on a 2004. The prose rule, which still said "Application Activity" after #258, now points at it. events.md and extend_ocsf.md get the Decision (allow) row, and test_trace_mapping_defaults.py checks the caption matches the 6002 rows.

The opt-in to record allows as Detection Findings stays. Dropping it is a one-line follow-up if the Spec leads want one class.

Which issue does this implement

Fixes #198

Base branch

• integration

Type of change

• Specification change
• Documentation

Specification changes

• I opened a Discussion before this PR (the issue is status:accepted)
• Schema changes validate against the JSON Schema spec
• I described the impact on downstream implementers below

Breaking for implementers? No. Every class_uid and existing default is unchanged; activity_id for 6002 stays with #235.

I tested this

• Synced with integration at c82310b
• uv run pytest -v: 888 passed, 1 skipped. The 10 failures and 30 errors are Windows-only (symlinks, gh shim) and identical on unmodified integration
• uv run mkdocs build --strict passes

Checklist

• Commits are signed off (DCO)
• Prose follows STYLE.md
• No secrets, tokens, or internal URLs

Security

• No security impact

🤖 Generated with Claude Code

[github-actions]

This pull request's description says it closes #198, 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.

[imran-siddique]

Confirmed, this delivers all of #198. Part 1: the Decision (allow) row is in both events.md and extend_ocsf.md. Part 2: allow_class in ocsf-mapping.json names the required fields, with the disposition in unmapped.acs.decision and the evaluator in unmapped.acs.metadata. One wording difference from the issue: 6002's class name is Application Lifecycle (Application Activity is its OCSF category), so the rows use the class name.

[imran-siddique]

@rocklambros this is green and mergeable, and it delivers all of #198 as confirmed above. Could one of the code owners review it?

[rocklambros]

Imran, OCSF 1.9.0 names class 6002 Application Lifecycle. Application Activity is its category, so your row has the right name and issue #198 had the category. I checked this at schema.ocsf.io. unmapped.acs.metadata also holds the evaluator, as you say, because evaluator sits in the response's metadata.

This closes issue #198. The row is in both tables. allow_class gives the class, the required fields, and where the disposition and the evaluator go. The issue accepted two classes if each one names its fields, so the Detection Finding opt-in can stay, and it works as it did before.

I merged this onto integration d9e3d5d and ran everything. Pytest gives 923 passed and 1 skipped, which is integration's count plus your new test. Integration's own tests also pass over your change. mkdocs build --strict is clean. The agt suite ran 1287 tests with 0 failures on Bun 1.3.11 and 1.3.14. Your test fails when I break the class id, the caption, unmapped.acs.decision, or the allow severity.

Two gaps remain after this PR. Neither one blocks this merge, because both were there before your change.

1. A 6002 allow still needs activity_id and application to pass the OCSF validator. Also, only unmapped.acs.decision tells it apart from the 6002 step event it gated. Both belong with the other 6002 rows in issue #235.
2. A late allow on 6002 has no finding_info, and finding_info.types is where the late_decision marker goes. That one is a question for Bar and Ariel.

Approving and merging.