FV-Execute. Actions that happen when they should.
Execute initiates control actions in response to policy, approval, schedule, incident state or supervisory override. The decision to act is recorded with the action, so there is no ambiguity about why the environment changed.
Control removes the physical path. Blueprints show where each module sits.
- Actions follow defined conditions, not informal practice
- TriggeredActions follow defined conditions, not informal practice
- Sensitive actions require the right approval pattern
- ApprovedSensitive actions require the right approval pattern
- Every action is paired with its reason and approver
- RecordedEvery action is paired with its reason and approver
- Where appropriate, actions have a defined undo path
- ReversibleWhere appropriate, actions have a defined undo path
Critical actions decided in the moment, by whoever is closest.
Ad-hoc response
When a control action is taken by the person who happens to be on shift, the rationale lives only in their memory and the outcome is harder to reason about later.
Missed conditions
Actions that should follow a schedule, a state change or an upstream signal often do not, because nothing systematic connects the signal to the action.
No supervisory layer
Without an explicit supervisory override, a runaway automation or a faulty trigger has no clean way to be paused, redirected or stopped.
Control Module - FIRE
An action without a reason is a fact you will struggle to defend. Execute records both, together, every time.
The Scenario
Scenario: a scheduled lockdown that does not depend on memory
A weekly maintenance pattern requires several systems to be placed into a restricted state outside business hours. Rather than relying on individuals to remember and act, Execute initiates the lockdown on schedule, with the policy that authorises it and the supervisor who can override it both recorded against the action. The same pattern applies in reverse when the window ends, and the evidential record shows what happened and why.
"Execute is the discipline of treating an action as a decision, not as a habit."
Where Execute requires an approved action.
Execute is the gate around any change that matters. Nothing destructive, privileged or boundary-altering happens without a named approver and a recorded decision.
Grounded in IEC 62443-3-3 SR 1.5 Authenticator Management, NIST CSF PR.AC-4 and ISO 27001 A.5.18, A.8.18.
FV-Execute
Control layer
Firebreak open and close events
Every change to the physical conduit state is an approved Execute event, not a console click.
Privileged change to OT assets
Engineering changes against PLCs, RTUs and HMIs require multi-party approval before the path is opened.
Restore from offline vault
Restoration from the offline vault is an explicit, recorded Execute decision with quorum approval.
Boundary policy changes
Changes to the zone and conduit definitions themselves are governed actions, not silent edits.
Relies on · prerequisites
- Independent approver identities that cannot be impersonated from the system being changed
- Recorded intent for every action, not just an audit log of the action
- Quorum policy that survives a single compromised admin
Pairs with · companion modules
Firebreak
Relay
Lock
ValidateFeatured In
Capabilities
What you get with every deployment
Condition-led initiation
Actions begin because a defined condition was met, not because somebody remembered.
Approval where it matters
Sensitive actions require the right approval before execution rather than after the fact.
Incident-aware
Execute responds to incident state so containment, isolation and lockdown actions can be carried out at machine speed within agreed bounds.
Supervisory override
An explicit supervisory layer can pause, redirect or stop an action when human judgement needs to take over.
Scoped authority
Each action is constrained to the systems and operations the policy permits.
Decision and execution paired
The reason for the action and the action itself are recorded together through Archive.
Demo to Live
Adoption Guide
Catalogue the actions
List the control actions that matter, including their owners, scopes and current triggers.
Define conditions and approvals
For each action, agree the policy, schedule, incident state and approval pattern that should govern it.
Pilot with one workflow
Move one action onto Execute end-to-end, including the supervisory override and the evidential record.
Operate and review
Run Execute as the initiation layer for control actions and review patterns through Archive on a regular cadence.
Catalogue the actions
List the control actions that matter, including their owners, scopes and current triggers.
Define conditions and approvals
For each action, agree the policy, schedule, incident state and approval pattern that should govern it.
Pilot with one workflow
Move one action onto Execute end-to-end, including the supervisory override and the evidential record.
Operate and review
Run Execute as the initiation layer for control actions and review patterns through Archive on a regular cadence.
Playbooks
Which playbook covers this module
Each playbook shows where this module sits in a real deployment, who authorises it and how a pilot scales into rollout.
A Control Blueprint for AI: 2026 Playbook
The kill switch doctrine chapter explains who may initiate a control action against an agent or cluster, and on what authority.
Read the playbook: A Control Blueprint for AI: 2026 PlaybookControl for Water: Deployment Playbook
Sets the approval pattern, escalation route and pre-approved conditions for control actions during a supply incident.
Read the playbook: Control for Water: Deployment PlaybookQuestions