If I'm understanding things correctly, we use two terms names depending on which side of Osprey you're looking at:
-
On the way into Osprey, things happening on a platform are actions: the submission API is message Action, the wire format sends action_id and action_name, and the rules engine follows suit with GetActionName(), the ActionName feature, and actions/{ActionName}.sml dispatch.
-
On the investigation side, we use events: the Event Stream, /events/:eventId permalinks, # Events chart counts, and the events/* UI API endpoints.
If these are referring to the same thing, itss confusing for new users and awkward for documentation. To me, "Action" makes me think of a moderation action—something Osprey or an analyst does in response to a rule. The UI seems to already uses it that way for Bulk Actions, while "Search by action or label" in the Rules Visualizer means action-the-input. 😵
Proposal: standardize on event for the thing that happens on the platform and flows through Osprey, and reserve action for a response Osprey or an analyst performs. That matches other platforms (including Coop!) and how analysts already talk, and it makes the existing Bulk Actions naming make more sense instead of introducing confusion.
Open questions:
- How this interacts with effects, the current term for what a matched rule does. Do effects become actions, or do we keep effects and simply retire action-as-input?
- Scope and sequencing: renaming the input side is a breaking change well beyond wording—the proto
Action message, the action_name wire fields, and the ActionName feature referenced throughout SML rules are all public surface. A realistic path is probably docs and UI strings first, then deprecation aliases for SML and the wire format in a later release.
Not urgent, but worth aligning on direction soon so ongoing docs work doesn't bake the current split in further.
If I'm understanding things correctly, we use two terms names depending on which side of Osprey you're looking at:
On the way into Osprey, things happening on a platform are actions: the submission API is
message Action, the wire format sendsaction_idandaction_name, and the rules engine follows suit withGetActionName(), theActionNamefeature, andactions/{ActionName}.smldispatch.On the investigation side, we use events: the Event Stream,
/events/:eventIdpermalinks,# Eventschart counts, and theevents/*UI API endpoints.If these are referring to the same thing, itss confusing for new users and awkward for documentation. To me, "Action" makes me think of a moderation action—something Osprey or an analyst does in response to a rule. The UI seems to already uses it that way for Bulk Actions, while "Search by action or label" in the Rules Visualizer means action-the-input. 😵
Proposal: standardize on event for the thing that happens on the platform and flows through Osprey, and reserve action for a response Osprey or an analyst performs. That matches other platforms (including Coop!) and how analysts already talk, and it makes the existing Bulk Actions naming make more sense instead of introducing confusion.
Open questions:
Actionmessage, theaction_namewire fields, and theActionNamefeature referenced throughout SML rules are all public surface. A realistic path is probably docs and UI strings first, then deprecation aliases for SML and the wire format in a later release.Not urgent, but worth aligning on direction soon so ongoing docs work doesn't bake the current split in further.