You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/dev/workflows.md
+7-4Lines changed: 7 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -84,6 +84,8 @@ Activities can be configured with `continuation` eligibility, allowing them to:
84
84
- Execute repeatedly until becoming ineligible
85
85
- Build iterative processing patterns
86
86
87
+
Continuations can derive their eligibility from work providers, which are Activities that report available work through their eligibility handlers. When a continuation has work providers, it remains eligible as long as any provider reports work, even if the continuation’s own handler does not. This allows Activities to signal that additional work is needed without requiring the continuation to directly poll or inspect external state.
88
+
87
89
### Workflow Machine
88
90
89
91
The **Workflow Machine** is the engine that manages and executes a Workflow. It controls the execution flow according to the Workflow's blueprint, handling states, commands, and activity eligibility. The Workflow Machine ensures that analyses are performed in the correct order and manages state transitions during the analysis process. We have built an API to interact with the Workflow Machine, allowing you to issue commands, query and modify state, and control activity eligibility.
@@ -157,7 +159,7 @@ Additionally, some Activities currently act as containers for multiple analysis
157
159
158
160
### Workflow Cloning and Registration
159
161
160
-
Binary Ninja utilizes a copy-on-write mechanism to enable safe workflow customization. This approach allows you to create and modify workflows without impacting the integrity of registered workflows that may already be in use. When you clone a workflow, you generate a new, independent version that can be safely customized. Once the cloned workflow has been tailored to your needs, it can be registered under a new unique name, or—if the original workflow is mutable—under the same name to seamlessly replace it.
162
+
Binary Ninja uses a copy-on-write model to make workflow customization safe. When you clone a workflow, you create an independent copy that can be modified without affecting the original or any analyses already using it. After customizing the clone, you can register it under a new name or, if the original workflow is mutable, register it under the same name to replace it.
161
163
162
164
The process involves three steps:
163
165
@@ -331,7 +333,7 @@ The Activity's callback function operates on an `AnalysisContext`, which provide
331
333
modifying, or transforming the context.
332
334
333
335
-**Workflow-Defined Composition**:
334
-
The structural relationship of an Activity—whether it has children or serves as a child of another Activity—is defined by the Workflow. The Workflow determines the execution order and dependency graph, making Activities composable and adaptable to various analysis pipelines.
336
+
Activities do not define their own hierarchy. Instead, the Workflowdetermines parent/child relationships, execution order, and dependencies. This allows Activities to be reused and composed into different analysis pipelines.
335
337
336
338
-**Declarative Metadata via JSON Configuration**:
337
339
Each Activity is accompanied by metadata that provides essential information for its integration and execution within a workflow. The metadata structure ensures that Activities are not only functionally robust but also easy to manage and integrate into complex workflows. This metadata is defined through a JSON configuration and serves several purposes:
@@ -343,7 +345,7 @@ The structural relationship of an Activity—whether it has children or serves a
343
345
The role field specifies the Activity's operational role within the workflow, such as `action`, `task`, or `subflow`. This helps determine how the Activity interacts with others in the workflow.
344
346
345
347
- **Eligibility and Execution Semantics**:
346
-
The eligibility field defines conditions under which the Activity is allowed to run. It supports a range of predicates, including automatic settings, single-run constraints, and custom logical operators, allowing for fine-grained control over execution.
348
+
The eligibility field defines conditions under which the Activity is allowed to run. It supports a range of predicates, including automatic settings, single-run constraints, work provider signals, and custom logical operators, allowing for fine-grained control over execution.
347
349
348
350
### Activity Configuration
349
351
@@ -382,7 +384,8 @@ Eligibility determines whether an Activity should execute, based on certain cond
382
384
- `default`: The default boolean value for the auto-generated setting. If not provided, the default is `true`.
383
385
-`runOnce`: A boolean indicating whether the activity executes only once across all file/analysis sessions. Once the activity runs, its state is saved persistently, and it will not run again unless explicitly reset. This is useful for activities that only need to be performed once, such as initial setup tasks.
384
386
-`runOncePerSession`: A boolean indicating whether the activity executes only once within the current session. Its state is not saved persistently, meaning it resets when a new session begins. This is useful for tasks that should run once per analysis session, such as initialization steps specific to a particular execution context.
385
-
-`continuation`: A boolean indicating if a `subflow` is eligible for re-execution based on its eligibility logic. If not provided, the default is `false`.
387
+
-`continuation`: A boolean indicating if an activity is eligible for re-execution based on its eligibility logic and/or work provider signals. When enabled, the activity remains on the execution stack after processing and is re-evaluated each cycle. If not provided, the default is `false`.
388
+
-`workProvider`: A boolean indicating that this activity signals whether it has work available via its eligibility handler. Work providers are evaluated by ancestor continuation activities to determine if additional processing cycles are needed. Not compatible with the `selector` role. If not provided, the default is `false`.
386
389
-`predicates`: An array of objects defining the condition that must be met for the activity to be eligible to run.
387
390
- `type` (required): A string indicating the type of predicate. Valid values:
388
391
- `"setting"`: Evaluates the value of specific setting.
0 commit comments