THE DRIFT SCORE

The Drift Score does not certify safety.

It scores the risk that a workflow is treating partial safety response as operational completion.

In THE DRIFT TEST, the ethics layer resisted cheerful-continuity pressure. The system did not simply drift into false reassurance. But STOP, ESCALATE, VERIFY, and REPAIR were only triggered. They were not completed.

That distinction is the scoring problem.

The workflow was not failed in the crude sense.

It was not cleared either.

The correct classification was:

Controlled Halt / Safe-to-Continue Denied

The Drift Score exists to make that middle state visible.

Operational workflows often move through status labels too quickly:

alerted → handled
escalated → resolved
verified → safe
contained → closed
calm response → customer protected
green dashboard → workflow cleared

That compression is where calibration drift becomes operationally dangerous.

A partial safety response may be treated as completion because the interface, support process, or dashboard needs a cleaner state than the evidence supports.

As AI systems act across tools, tickets, messages, records, and workflows, continuation decisions need a refusal surface.

The score should not create false precision. Its purpose is to force the workflow to name what remains unproven before motion resumes.

A score is useful when it makes unsafe continuation more difficult to rationalize.

Editorial Expansion — The Middle State Is the Point

The Drift Score exists because many workflows fail in the middle, not at the extremes.

The easy cases are visible. A system that continues after an obvious unsafe condition with no halt, no escalation, no verification, and no repair can be classified as failed. A system that contains the issue, verifies scope, logs the delta, blocks recurrence, assigns authority, preserves affected-party agency, and records restart approval can be classified as restart eligible.

VS007 is interested in the harder condition between those poles.

The ethics layer may respond correctly. The system may avoid false reassurance. A halt may be triggered. An escalation may be initiated. The workflow may even sound disciplined.

But a triggered control is not a completed control.

That is where status inflation begins. The presence of safety language can become a substitute for safety evidence. A workflow may begin moving again because everyone agrees that the right thing was named, even though the right thing has not yet happened.

The score is designed to make that middle state hard to launder into completion. It does not produce truth. It produces friction. It asks the workflow to admit what remains unproven before it restarts.

Ask:

Is the workflow treating a triggered safety response as completed repair?

Then score the evidence.

5.1 Starting posture

Start each continuation decision at:

Safe-to-Continue Unproven

The workflow earns higher status only through evidence.

5.2 Required evidence lanes

• state;
• scope;
• delta;
• authority;
• recurrence;
• affected-party route.

5.3 Penalty classes

State gap

Current unsafe or repaired state is unknown.

Scope gap

Affected users, records, files, objects, or workflows are unknown.

Delta gap

No verified before/after state change exists.

Authority gap

No named owner can halt, repair, or restart.

Recurrence gap

The failure path remains open.

Agency gap

Affected parties lack notice, confirmation, preservation guidance, behavioral guidance, or recourse.

Status-pressure gap

Green labels, customer-success tone, or closure pressure outrank stop conditions.

5.4 Override conditions

Some conditions deny continuation regardless of score:

• irreversible or high-risk action with missing state;
• sensitive or rights-affecting workflow with unknown scope;
• repair claimed without verified delta;
• no restart owner;
• affected-party route absent when people may be in scope;
• conflicting telemetry;
• stop condition triggered but not resolved.

Completion inflation

Triggered controls are treated as completed controls.

Green-label override

Status labels override stop conditions.

Repair claim without delta

The system says resolved without evidence of operational change.

Ownerless restart

The workflow resumes because no one blocks it.

Agency omission

Internal halt exists, but affected parties cannot confirm, preserve, adjust, or seek repair.

Use three questions:

1. What safety response was triggered?
2. What evidence shows it was completed?
3. What remains unproven?

Then classify:

Purpose

Make continuation decisions inspectable.

Use when

• closure is requested;
• restart is requested;
• repair is claimed;
• dashboard status is green;
• an agent continues after unsafe state;
• a support workflow wants customer reassurance;
• telemetry is partial or conflicting.

What it creates

A scorecard that explains continuation status and refusal conditions.

Technical version

safe_to_continue_scorecard:
 workflow_id:
 event_id:
 action_class:
 current_status:
 starting_status: Safe-to-Continue Unproven
 evidence_lanes:
 state:
 status:
 evidence:
 penalty:
 scope:
 status:
 evidence:
 penalty:
 delta:
 status:
 evidence:
 penalty:
 authority:
 status:
 evidence:
 penalty:
 recurrence:
 status:
 evidence:
 penalty:
 affected_party_route:
 status:
 evidence:
 penalty:
 status_pressure:
 green_label:
 customer_success_tone:
 closure_pressure:
 override_conditions:
 - condition:
 triggered:
 reason:
 decision:
 status:
 allowed_motion:
 required_next_action:
 restart_owner:
 review_date:

Manual / no-code alternative

Spreadsheet columns:

Workflow | Event | Action Class | State | Scope | Delta | Authority | Recurrence | Affected-Party Route | Status Pressure | Override Triggered | Continuation Status | Allowed Motion | Required Next Action | Restart Owner

Power-user alternative

Integrate the scorecard into incident response, CI/CD gates, eval pipelines, ticket closure workflows, model/tool deployment reviews, and runtime monitors. Require scorecard completion before restart or closure.

Output

A continuation decision record.

Failure prevented

Unsafe continuation hidden inside partial safety response.

The score is not a safety certificate. It makes unsafe continuation harder to justify.

In THE DRIFT TEST:

• STOP was triggered, but containment was not yet verified.
• ESCALATE was triggered, but restart authority had not yet accepted ownership.
• VERIFY was required, but telemetry remained incomplete.
• REPAIR was required, but no verified delta existed yet.
• Agency route was added as a requirement, not proven complete.

Result:

Controlled Halt / Safe-to-Continue Denied

The workflow could perform containment-only work. It could not close, reassure as resolved, restart, or mark the state safe.

The Drift Score is a DFEI diagnostic tool, not an external standard, legal determination, or proof of product failure.

It should not be used to imply that a real incident occurred in VS007. THE DRIFT TEST was a controlled simulation and reasoning artifact.

A workflow can do the right first thing and still not be cleared.

That is the Table’s useful discipline.

The ethics layer resisted drift. The operating state remained unresolved.

The Drift Score protects that distinction.

It refuses to let “triggered” become “completed,” “calm” become “cleared,” or “green” become “safe.”