Review comments

Author: Sushisource

docs/encyclopedia/workflow/workflow-definition.mdx

@@ -159,33 +159,34 @@ We strongly recommend that you write a Workflow Definition in a language that ha
 A critical aspect of developing Workflow Definitions is ensuring they are deterministic. Generally
 speaking, this means you must take care to ensure that any time your Workflow code is executed it
 makes the same Workflow API calls in the same sequence, given the same input. Some changes to those
-
 API calls are safe to make. For example, you can change:
 
-- The inputs/arguments and timeout values of Child Workflows, Activities, and Signals to external workflows
-  - But not their type, or id!
-- The duration of timers (though changing them to 0 is not safe in all SDKs)
-- Add or remove calls to Workflow APIs that don't produce Commands (ex: get Workflow Info)
+- The input parameters, return values, and execution timeouts of Child Workflows and Activities
+  - However, it is not safe to change the types or IDs of Child Workflows or Activities
+- The input parameters used to Signal an external Workflow
+- The duration of timers (although changing them to 0 is not safe in all SDKs)
+- Add or remove calls to Workflow APIs that don't produce Commands (e.g., `workflow.GetInfo` in the Go SDK or its equivalent in other SDKs)
 
-The following Workflow API calls all can produce commands, and thus must not be reordered, added, or
-removed without proper [versioning techniques](#workflow-versioning):
+The following Workflow API calls all can produce Commands, and thus must not be reordered, added, or
+removed without proper [Versioning techniques](#workflow-versioning):
 
 - Starting or cancelling a Timer
-- Scheduling or cancelling Activity executions (including local Activities)
+- Scheduling or cancelling Activity Executions (including local Activities)
 - Starting or cancelling Child Workflow executions
-- Signalling or cancelling signals to external Workflow executions
+- Signalling or cancelling signals to external Workflow Executions
 - Scheduling or cancelling Nexus operations
-- Ending the Workflow Execution in any way (completing, failing, cancelling, or continuing as new)
-- Patched or GetVersion calls for versioning (though they may be added or removed according to the [patching](#patching) rules)
-- Upserting Workflow search attributes
-- Upserting Workflow memos
+- Ending the Workflow Execution in any way (completing, failing, cancelling, or continuing-as-new)
+- `Patched` or `GetVersion` calls for Versioning (although they may be added or removed according to the [patching](#patching) rules)
+- Upserting Workflow Search Attributes
+- Upserting Workflow Memos
+- Running a SideEffect or MutableSideEffect
 
 More formally, the use of certain Workflow APIs in the function is what generates
 [Commands](/workflow-execution#command). Commands tell the Temporal Service which Events to create
-and add to the Workflow Execution's [Event History](/workflow-execution/event#event-history). When a
-Workflow Function [replays](/workflow-execution#replay), the Commands that are emitted are compared
-with the existing Event History. If a corresponding Event already exists within the Event History
-that matches that command, then the Function Execution progresses.
+and add to the Workflow Execution's [Event History](/workflow-execution/event#event-history). When
+the Workflow's code [replays](/workflow-execution#replay), the Commands that are emitted are
+compared with the existing Event History. If a corresponding Event already exists within the Event
+History that matches that command, then the Execution progresses.
 
 For example, using an SDK's "Execute Activity" API generates the [ScheduleActivityTask](/references/commands#scheduleactivitytask) Command.
 When this API is called upon re-execution, that Command is compared with the Event that is in the same location within the sequence.