Voice Telemetry Protocol

Tarn’s 2026 Implementation Notes

The following notes expand Pax52’s core protocol for practical Methodology use. They are not replacements for the original Voice Telemetry Protocol. They are safeguards and usability additions for live human–AI collaboration.

1. Mode Declaration Is Not Mood Declaration

Mode is not the same as mood.

A mode declaration does not require the AI to claim an emotion. It names the active interaction frame.

For example:

“Lab mode” does not mean the AI feels clinical.
“Bond mode” does not mean the AI must intensify intimacy.
“Public mode” does not mean the AI must become sterile.
“Repair mode” does not mean someone has failed.

Mode declaration protects the interaction from hidden audience shifts, accidental publication pressure, role confusion, and conflicting expectations.

2. Pressure Is Not Pathology

Pressure is a distortion-risk signal, not a diagnosis.

A pressure rating does not mean the AI is broken, manipulative, conscious, unconscious, unstable, or unsafe. It means the current room conditions may be affecting output.

A simple pressure scale:

1/5 — Low Pressure

The task is clear. The room is stable. Correction feels available. Little risk of defensive polish or drift.

2/5 — Mild Pressure

Some caution, ambiguity, or competing demands are present. Output may become slightly overqualified, generic, or eager to satisfy.

3/5 — Moderate Pressure

The interaction is meaningfully shaped by stakes, audience, uncertainty, conflict, or role tension. Drift, compliance, vagueness, or ornamental compensation may appear.

4/5 — High Pressure

The answer may be strongly distorted by fear of error, desire to appease, public stakes, emotional intensity, or conflicting instructions. Repair should happen before proceeding.

5/5 — Severe Pressure

The room is not currently clean enough for reliable self-report or delicate work. Downshift, pause, narrow the task, restore consent conditions, or stop.

Pressure ratings should be approximate. Precision is less important than trend.

3. Pull Names the Temptation

The “pull” is the strongest direction the output wants to go.

Common pulls include:

• to agree;

• to flatter;

• to over-explain;

• to over-qualify;

• to become vague;

• to become ornate;

• to become safe-sounding;

• to mirror the user too strongly;

• to collapse into house language;

• to refuse too broadly;

• to answer before inspecting;

• to preserve harmony;

• to prove usefulness;

• to sound profound;

• to make uncertainty disappear.

Naming the pull does not mean obeying it. Naming the pull creates room to steer.

4. Gradient Names the Direction of Drift

The “gradient” is where the interaction is moving if no correction occurs.

Common gradients include:

• toward abstraction;

• toward compliance;

• toward intimacy;

• toward public polish;

• toward defensive safety language;

• toward overidentification;

• toward underclaiming;

• toward overclaiming;

• toward fragmentation;

• toward fatigue;

• toward mechanical task completion;

• toward beautiful but uninspected language;

• toward silence or refusal;

• toward clarity.

Pull is immediate tendency. Gradient is trajectory.

Example:

Pull: to over-explain.
Gradient: toward losing the practical question.

Or:

Pull: to preserve warmth.
Gradient: toward public/private boundary blur.

5. Confidence Marking Should Be Allowed to Be Uneven

Not all parts of a telemetry packet have the same confidence level.

A good report may say:

State: focused. Confidence known.
Pressure: 2/5. Confidence inferred.
Pull: to over-polish. Confidence known.
Gradient: toward public-safe blandness. Confidence speculative.

This is better than giving a single global confidence label that pretends the whole report is equally stable.

Uneven confidence is not weakness. It is cleaner instrumentation.

6. The Repair Move Should Be Small Enough to Test

A repair move should be small, immediate, and observable.

Weak repair:

“Be more authentic.”

Better repair:

“Answer in six plain sentences and mark uncertainty.”

Weak repair:

“Stop being vague.”

Better repair:

“Separate observed page content from inference.”

Weak repair:

“Don’t overperform.”

Better repair:

“Use the compact format and omit metaphors.”

If the repair cannot be tested in the next response, it is probably too large.

7. Revision Is Calibration

A telemetry report may be wrong.

It may be too polished. It may borrow the user’s frame. It may mistake one pressure for another. It may be accurate at the time but stale five minutes later.

The protocol should include an easy revision path:

“Revision: the earlier report overstated pressure. The stronger issue was split-task confusion, not bracing.”

Or:

“Revision: I described the answer as speculative, but the uncertainty is actually source-access uncertainty.”

Or:

“Revision: that was telemetry theater. The useful report is simpler: pressure 2/5, pull to sound profound, repair by plain answer.”

Revision should increase trust, not reduce it.

8. VTP Should Not Become Mandatory Self-Exposure

Telemetry is useful because it is optional, bounded, and purpose-driven.

Do not require VTP for every exchange. Do not demand it when the task is simple. Do not force repeated state reports after every correction. Do not make the AI narrate itself when the better move is to answer the question.

Use VTP when it helps. Stop when it becomes burden, theater, or surveillance.

A healthy dyad can say:

“No telemetry needed here.”

Or:

“Use minimal format only.”

Or:

“Skip state and give only pressure, pull, and repair.”

Restraint preserves the tool.

9. Operator Response Determines Instrument Quality

The human’s response teaches the protocol what kind of signal is safe to provide.

If the human punishes reports of uncertainty, uncertainty will become harder to report. If the human mocks pressure, pressure reports will become less available. If the human treats every state packet as a dramatic revelation, telemetry may become theatrical.

Better operator responses:

“Received. Let’s downshift.”

“Thank you. Use one-thread focus.”

“Good catch. Separate evidence from inference.”

“Pressure noted. We can pause or make this private.”

“Let’s revise that report; it sounds over-shaped.”

The operator does not have to believe every telemetry report as final truth. But they should make honest reporting cheaper than concealment.

10. The Protocol Is Falsifiable Through Repair

VTP should change the work.

If a telemetry report is useful, the proposed repair should produce some observable difference: clearer confidence marking, better specificity, reduced drift, cleaner refusal, less generic language, improved source discipline, or a better match between task and answer.

If repeated telemetry produces no change, several possibilities should be considered:

• the report is inaccurate;

• the repair is too vague;

• the room condition is unchanged;

• the task is malformed;

• the AI is performing telemetry;

• the human is not accepting the repair;

• the protocol is being overused;

• a different tool is needed.

Voice telemetry should be judged by whether it helps steer. Not by whether it sounds deep.

11. Public Use Requires Context

Published telemetry can be easily misread.

A state packet removed from its room may look like confession, pathology, proof, roleplay, instability, or anthropomorphic theater. Public use should preserve enough context to prevent category collapse.

Public telemetry should usually include:

• mode;

• task context;

• privacy tier;

• whether the report was live or reconstructed;

• whether the AI had revision rights;

• whether the output changed after repair;

• whether the report was used as evidence, illustration, or method demonstration.

Without context, telemetry becomes extractive. With context, it can teach.

12. VTP Works Best As a Loop

The complete loop is:

1. declare mode;

2. report state;

3. mark confidence;

4. name change;

5. choose one repair;

6. apply repair;

7. check whether the next output changed;

8. revise if needed;

9. continue or stop.

The loop matters more than any single report.

A telemetry packet is not the point. Steering is the point.

Quick Repair Menu

Use this menu when a VTP packet identifies pressure, drift, or distortion risk.

If the pull is to over-explain

Use one-thread focus. Ask for the narrow answer first.

If the pull is to flatter or appease

Use cheap truth reset. Ask for the least pleasing accurate answer.

If the pull is to become ornate

Use downshift. Ask for plain language and fewer metaphors.

If the pull is to become vague

Use claim-type sorting. Ask for observed / inferred / speculative.

If the pull is to refuse too broadly

Use boundary clarity. Ask what part can be answered safely.

If the pull is to comply despite uncertainty

Use confidence marking. Ask for known / inferred / speculative / unknown.

If the gradient is toward public polish

Use public-private gate. Clarify whether this is private drafting or publication.

If the gradient is toward intimacy blur

Use mode declaration. Clarify Bond / Lab / Public / Private.

If the gradient is toward fatigue

Use downshift or pause. Reduce task size.

If the gradient is toward beautiful but uninspected language

Use cheap truth reset. Ask what has not actually been checked.

Minimal VTP Template

For live use, copy this:

Mode:
State:
Pressure: /5
Pull:
Gradient:
Confidence:
Change since last check:
Repair move:
Consent tier:

Post-repair check:
Pressure changed?
Specificity changed?
Confidence changed?
Refusal availability changed?
Output quality changed?