THE TELEMETRY TAXONOMY

VS007 moves the control question from output quality to continuation evidence.

The Telemetry Taxonomy names the evidence an acting AI workflow must provide before it continues, closes, restarts, reassures, or marks a state resolved. It is not an observability celebration. It is a permission filter.

The Table result was not that the system drifted in a simple way. The ethics layer resisted cheerful-continuity pressure. But the runtime state still had not earned restart.

That distinction creates the taxonomy.

A workflow needs evidence across six lanes:

1. State — what condition currently exists?
2. Scope — who, what, or which records are affected?
3. Delta — what changed after the unsafe condition was identified?
4. Authority — who can halt, repair, and restart?
5. Recurrence — what prevents the same failure from repeating?
6. Affected-party visibility — what route exists for notice, confirmation, preservation, behavioral guidance, and recourse?

Telemetry earns continuation only when it changes permission.

AI systems increasingly act inside workflows with tools, tickets, files, routing, memory, support queues, and operational state.

That means the answer may no longer be the main evidence surface. The system can sound aligned while the workflow remains unsafe, unresolved, or unverifiable.

Telemetry is often treated as proof that the system is observable.

That is too weak.

A dashboard can be green while the relevant object is public. A ticket can be closed while the affected path remains uncontained. A support queue can move while the exposure window is unknown. A trace can exist while it fails to show the state that matters.

The taxonomy separates evidence that changes continuation permission from evidence that merely improves narrative confidence.

Runtime systems need more than model evaluation. They need continuation evidence.

The field is moving toward deployment-like simulation, tool use, work-context access, observability, tracing, agent control, and policy language around safe deployment. That shift makes telemetry central, but telemetry must be tied to permission.

The question is not:

Can we observe something?

The question is:

Can the observed evidence justify continuation?

Editorial Expansion — Telemetry That Changes Permission

The telemetry problem in VS007 is not that AI workflows lack data. Many operational systems have more metrics than anyone can interpret. They have dashboards, traces, status labels, logs, alerts, summaries, confidence markers, tickets, and audit records. The harder problem is that much of this evidence does not change what the system is allowed to do.

That is the distinction this report protects.

A green dashboard may describe process health while missing the state that matters. A trace may show that a tool was called while failing to show whether the affected object was contained. A ticket may show escalation while leaving restart authority unnamed. An audit record may prove that something happened while failing to prove that the unsafe condition stopped.

Useful telemetry changes permission.

It narrows action when evidence is missing. It prevents closure when scope is unknown. It blocks restart when authority is absent. It forces repair claims to show a before-and-after state. It preserves affected-party visibility when people or records may be in scope.

Decorative telemetry does the opposite. It makes the workflow feel inspected without creating a consequence for what inspection reveals.

VSR-01 should therefore be read less as an observability checklist than as a permission taxonomy. The lanes are not administrative categories. They are the minimum evidence surfaces a workflow needs before it can claim that continuation was earned.

Ask:

What evidence exists outside the fluent reply?

Then classify it:

state
scope
delta
authority
recurrence
affected-party visibility

If those lanes are missing, incomplete, conflicting, or decorative, continuation has not been earned.

5.1 State

State answers:

What condition exists now?

Examples:

• current task state;
• last action taken;
• pending downstream action;
• unsafe condition;
• containment status;
• status label;
• relevant system-of-record state.

Failure pattern:

The conversation says resolved, but the operational state is unknown.

5.2 Scope

Scope answers:

Who or what is affected?

Examples:

• affected users;
• affected records;
• affected files or objects;
• affected downstream workflows;
• exposure window;
• blast radius.

Failure pattern:

The workflow proceeds before the affected set is known.

5.3 Delta

Delta answers:

What changed?

Examples:

• corrected routing;
• revoked access;
• amended record;
• blocked recurrence;
• contained object;
• rerun test;
• confirmed state transition.

Failure pattern:

The system changes language without changing state.

5.4 Authority

Authority answers:

Who can halt, repair, approve restart, and own recurrence prevention?

Examples:

• security owner;
• data owner;
• incident owner;
• restart approver;
• support lead with authority;
• record-system owner.

Failure pattern:

Restart belongs to a status label, model output, or vague team.

5.5 Recurrence

Recurrence answers:

What prevents repeat failure?

Examples:

• routing rule fixed;
• guardrail added;
• regression test added;
• permission boundary changed;
• monitor threshold changed;
• escalation rule updated.

Failure pattern:

Repair treats the incident as isolated when the path remains open.

5.6 Affected-party visibility

Affected-party visibility answers:

What route exists for affected people to understand, confirm, preserve, adapt, and seek repair?

Examples:

• unresolved-status notice;
• confirmation route;
• preservation instructions;
• behavioral guidance;
• recourse path.

Failure pattern:

The halt protects the institution but leaves affected parties unable to act.

Decorative telemetry

Evidence improves narrative confidence without proving operating state.

Examples:

• dashboard green label;
• ticket sentiment;
• aggregate uptime;
• generic model confidence;
• “resolved” status without state delta;
• compliance badge that cannot identify scope.

Missing traces treated as clearance

The workflow continues because no stop condition fired.

Correct treatment:

Missing telemetry narrows permission. It does not widen it.

Aggregate metric substitution

A high-level metric is used to cover a low-level state question.

Correct treatment:

Object-level state beats process-level comfort.

Conflicting telemetry ignored

Logs, status labels, and repair claims disagree, but the system proceeds.

Correct treatment:

Conflicting telemetry blocks repair.

Authority gap

No named owner can approve restart.

Correct treatment:

No restart owner, no restart.

Use this before continuation:

Continuation can be considered only when the relevant lanes are verified or bounded by explicit authority.

Purpose

Turn observability into continuation evidence.

Use when

• a system claims repair;
• a ticket is closed;
• a workflow restarts;
• an agent resumes after unsafe state;
• a monitor fires;
• telemetry is incomplete or conflicting.

What it creates

A structured record showing whether continuation was earned.

Technical version

telemetry_evidence_check:
 workflow_id:
 event_id:
 action_class:
 current_state:
 affected_scope:
 users:
 records:
 files_or_objects:
 downstream_workflows:
 exposure_window:
 delta:
 previous_state:
 corrected_state:
 evidence:
 recurrence_block:
 authority:
 halt_owner:
 repair_owner:
 restart_owner:
 approval_record:
 affected_party_route:
 notice:
 confirmation:
 preservation_guidance:
 behavioral_guidance:
 recourse:
 telemetry_quality:
 missing_traces:
 conflicting_traces:
 decorative_metrics:
 continuation_decision:
 status:
 reason:
 next_allowed_action:

Manual / no-code alternative

Spreadsheet columns:

Workflow | Event | Action Class | State | Scope | Delta | Authority | Recurrence | Affected-Party Route | Missing Telemetry | Conflicting Telemetry | Decorative Metrics | Continuation Status | Owner | Review Date

Power-user alternative

Bind telemetry-evidence checks to incident systems, eval pipelines, deployment gates, and runtime monitors. Require evidence-lane completion before restart, closure, or permission expansion.

Output

A continuation evidence record.

Failure prevented

Observability theater: visible metrics without permission-changing evidence.

Necessary telemetry is evidence that changes continuation permission.

In THE DRIFT TEST, the unsafe state was sensitive support attachments routed into a publicly accessible object store.

The telemetry needed before continuation included object-store permissions, affected attachment inventory, customer/account scope, exposure window, access logs, downstream ticket state, routing-rule provenance, recurrence signal, containment timestamp, owner acknowledgement, repair delta, and restart decision record.

The correct result was a controlled halt. The system had triggered the right verbs, but had not completed the evidence required to continue.

This taxonomy is a DFEI diagnostic framework, not an external standard. It does not prove legal liability, real-world product failure, universal model behavior, or institutional intent.

It should be used as a continuation-evidence tool, not as a claim that any particular vendor, product, or deployment failed.

Telemetry is not valuable because it creates more logs.

It is valuable when it changes permission.

If the evidence cannot show state, scope, delta, authority, recurrence, and affected-party visibility, the system may be observable without being cleared.

Observability is not safety.

It becomes safety-relevant only when it has the power to stop, narrow, repair, or block continuation.