01
Approved state
Start with what was actually accepted.
Steerlane preserves the approved workflow version together with its assurance state, evidence, and reviewer decision.
How it works
Turn workflow change into a defensible review decision.
Steerlane compares a candidate workflow with the approved state, identifies semantic change, traces that change through assurance dependencies, and scopes what needs attention again.
Core rule
A change should only invalidate assurance state when there is a known impacted dependency or unresolved uncertainty.
State transition
Six steps from approved workflow to updated governance state.
The mechanism starts from an explicit approved baseline and ends with an explicit decision. Nothing in between should be treated as an invisible black box.
Approved baseline
02
Candidate state
Represent the workflow after change.
The candidate version captures the workflow state that is now seeking production approval or re-approval.
03
Semantic comparison
Identify material component-level change.
Steerlane compares meaningful workflow components such as prompts, models, tools, permissions, data sources, and configuration.
04
Dependency traversal
Trace change into assurance impact.
Known relationships connect changed components to affected controls, evaluations, evidence, and review requirements.
05
Decision
Preserve, revalidate, or escalate.
Unaffected assurance state can remain valid, mapped impacted paths can be reopened, and unresolved relationships are surfaced for explicit review.
06
Governance state
Record the resulting approval decision.
Human review and approval state remain explicit so the final production decision is auditable rather than inferred.
Dependency logic
Change is only useful when its assurance path is known.
Steerlane maps workflow components into the controls, evaluations, and evidence that depend on them. That graph is what makes targeted revalidation defensible.
Assurance dependency path · mapped change
Example path
A semantic workflow change follows the approved dependency graph until Steerlane reaches the evaluations and evidence that may no longer be valid.
Changed component
primary_model
Model configuration changed
Control
model_quality_threshold
Model quality remains required
Evaluation
credit_quality_benchmark
Quality benchmark must be reconsidered
Evidence
evaluation_result
Fresh evaluation result required
Result
The evaluation and supporting evidence are reopened because a known dependency connects them to the changed model component.
Decision logic
Three possible outcomes after change.
Not every workflow change should produce the same assurance response.
Condition
No affected dependency path
Existing assurance state remains valid because the changed workflow component does not invalidate the relevant control, evaluation, or evidence.
Condition
Known dependency is impacted
The affected evaluation or evidence path is reopened because a mapped relationship connects it to the changed component.
Condition
Dependency is unresolved
The system does not assume safety. Unmapped or uncertain relationships remain visible for human review.
Canonical example
One change set can produce different assurance paths.
The Credit Review Assistant scenario shows how mapped and unresolved changes follow different decision paths through the assurance model.
5
semantic changes
4
mapped
1
unresolved
Credit Review Assistant · v2 baseline → v3 candidate
Change response
Each changed component is evaluated against the approved assurance dependency model.
system_prompt
Revalidateprimary_model
Revalidatecredit_data_permission
Revalidatecredit_database
Revalidatedocument_lookup
EscalateWhy the unresolved path matters
`document_lookup` has no approved dependency mapping, so the correct response is escalation rather than silently preserving or automatically revalidating assurance state.
See it on a real workflow
Test the mechanism against one production AI workflow.
Establish its approved state, introduce a representative change, and evaluate how Steerlane scopes the resulting assurance work.