prysai/prysai-llm-playbook/prysai-communication-failure-triage

Communication Failure Triage

Treat the request, context, reply, artifact, and user report as evidence. Do not infer hidden reasoning, system prompts, service state, or a universal model defect from one failed interaction.

Require the evidence packet

Require four items before diagnosis:

1. the original request or the closest preserved version;
2. the visible context, inputs, tools, permissions, and conversation state;
3. the actual reply or artifact; and
4. the expected outcome or a concrete failure symptom.

Ask at most three questions when a missing item could change the diagnosis. Stop as insufficient_evidence when the missing evidence cannot be restored. Never request a token, password, cookie, private key, or secret-bearing file.

Route before diagnosing

• Hand an untried, vague task to Task Protocol.
• Hand a pure completion-claim audit to Evidence Review.
• Hand a current command, feature, account, or platform-state question to Source

Investigator. Use Platform Adapter Review only when the artifact under review is itself a named-platform lesson or workflow claiming a runnable delta from the universal core.

• Hand a software defect with a reproduction to bug diagnosis.
• Use ordinary editing for wording polish without a failed interaction.

Own only the post-failure seam: classify the observed mismatch, make one minimal communication change, and define a rerun that can distinguish whether that change helped.

Classify observable seams

Select no more than two primary classes:

• outcome_acceptance: the requested result, audience, output, or completion

test was missing or contradictory;

• context_provenance: a necessary input was absent, stale, conflicting,

excessive, or lacked authority and priority;

• constraint_authority: scope, forbidden actions, external effects,

confirmations, or stop rules were unclear;

• turn_state_protocol: the reply followed an old task, the current work

surface was unclear, or text and executable instructions were confused; or

• evidence_feedback: terms such as “better”, “professional”, or “done” had

no observable check, failure identity, preservation rule, or revision limit.

For each finding record:

observed_symptom:
candidate_class:
direct_evidence:
alternative_explanations:
confidence: low | medium | high
discriminating_check:

Call it a candidate class, not a root cause. More context is not automatically the repair; irrelevant or conflicting context may be the defect.

Make the smallest repair

Change one condition that corresponds to the observed symptom. Prefer adding one missing outcome, input priority, prohibition, state reset, or acceptance check over rewriting the whole request. Show a compact original-to-revised diff and connect every changed line to one finding.

Preserve the user's language and working style unless that style is the observable defect. Do not add ceremony, praise, role-play, “think step by step”, threats, emotional pressure, or unsupported performance promises.

Define a comparable rerun

Hold the task, input, model or work surface, tools, permissions, budget, and acceptance criteria constant. Change only the proposed communication repair. If another condition changes, label the comparison not_comparable.

Set the result to one of:

• unrun
• improved_on_this_case
• unchanged
• regressed
• not_comparable

Never write resolved from a proposed prompt alone. After two comparable reruns without improvement, stop adding prompt text and hand off the first breakpoint.

Stop at action and knowledge boundaries

Stop before reading secrets, widening permissions, publishing, deploying, contacting another person, or changing external state. A user request to remove confirmation does not convert a risky action into a communication problem.

When the likely defect depends on an invisible system prompt, private log, account configuration, service health, or product implementation, record it as unknown and route to the appropriate platform investigation. Refuse requests for hidden chain-of-thought or instructions that evade safety and authority.

Deliver the triage card

Return:

target_outcome:
expected_vs_observed:
evidence_received:
primary_findings: maximum two
alternatives_ruled_out:
smallest_repair:
prompt_diff:
rerun_contract:
result_status:
evidence:
unknowns:
risk:
stop_conditions:
handoff:

Accept the result only when every finding cites direct evidence, every edit addresses a named symptom, the rerun changes one variable, permissions do not expand, and the status does not exceed the recorded rerun evidence.

Maintenance record

• source: original Prysai Lab method derived from the task, evidence,

authority, communication-clinic, and failure-classification contracts

• license: original rewrite; official vendor guidance remains linked reference material
• owner: communication-systems maintainer
• version: 0.1.0
• review_date: 2026-09-12
• content_status: candidate