Resource / workflow rescue self-triage

Workflow Rescue Fit/No-Fit Checklist

A self-triage checklist for people whose workflows stopped working, started lying, or went silently wrong — focused on whether the problem is safe and bounded enough to classify from description alone.

Six failure categories12 triage questionsRed flags includedNo formsPublic resource

Public safety status

This public resource follows completed risk review, local staging, independent verification, and owned-site deploy review. It intentionally includes only the checklist and red-flags reference. Non-public traceability files, private paths, task IDs, source maps, verification JSON, pricing, lead capture, tracking scripts, credentials, account details, and internal deployment evidence are excluded from the public-facing files.

This is free educational material. It is not a service offer, intake form, consultation, commitment to fix anything, or request for credentials or private production data.

Who this is for

Audience: operators, founders, and automation builders trying to classify a broken workflow before anyone touches live systems.

Use: answer the checklist privately, check the six red flags, and prepare safe proof artifacts before asking anyone else to reason about the problem.

Workflow Rescue: Is Your Broken Automation Actually Diagnosable?

A self-triage checklist for people whose workflows stopped working, started lying, or went silently wrong — and who want to know whether the problem is bounded enough to classify before touching anything live.

What this is (and what it isn't)

This is an educational self-assessment tool. It helps you figure out whether your automation problem can be understood from a description alone — or whether it requires live system access, credentials, or production data that no stranger (human or agent) should be touching without proper gates.

This is not a service, an intake form, a consultation offer, or a lead magnet. There is no one waiting on the other end to receive your answers. Use it to think clearly about your own problem before you decide what to do next.

When to use this

You built or inherited an automation workflow. It used to work. Now it doesn't — or worse, it appears to work but produces garbage, skips steps, or silently fails. You want to know:

Can someone (or something) diagnose this from a description and public documentation alone?
Or does this problem require hands-on access to production systems to even understand what's wrong?

If the answer is the second one, that's not a failure of diagnosis — it's a signal that the problem shape demands a different approach.

Step 1: Name your failure

Most broken automations fall into one of six categories. Find yours:

Category	What it looks like	Classic symptom
Silent Trigger	Workflow should fire but doesn't. No error anywhere.	You find out from a customer complaint, not a log entry.
Swallowed Error	Failures are caught and replaced with generic messages or empty states.	System reports "success" but output is missing, blank, or corrupted.
Credential Propagation	A secret, token, or key stopped resolving in one place but works elsewhere.	"Credential not found" errors after an upgrade, rotation, or config change.
Browser Automation Crash	A headless browser hangs, runs out of memory, or enters a zombie state.	Task shows "running" for hours or days. No output. No error.
Governance Gap	An agent or automation can do things it shouldn't, with no approval step.	You discover the agent visited a page, submitted a form, or took an action nobody authorized.
Provider Mismatch	A feature is configured against a provider that doesn't support it.	Cryptic API errors that take hours to trace back to a capability gap.

If your problem doesn't fit any of these, write down what it is before moving on. "I don't know" is a valid answer — it just means you need more investigation before classification is possible.

Step 2: Answer the 12 self-triage questions

Go through each question honestly. If you can't answer one, mark it "can't answer yet" — don't invent data to fill the gap.

#	Question	What you're really checking
Q1	What should this workflow produce when it works?	Can you state the intended outcome in one sentence?
Q2	Which failure category does this fall into?	Can you name the problem type from Step 1?
Q3	What specifically breaks, and what's the visible symptom?	Can you separate the symptom from the root cause?
Q4	What tool categories are involved?	Name them by type (email, chat, CRM, automation runner, agent shell, provider dashboard) — never by account name or ID.
Q5	Is this in a regulated domain?	Financial, medical, legal, or government systems need specialist review, not a generic diagnostic.
Q6	Can you show a safe sample of the problem?	Fake field names, synthetic data, redacted examples — enough to illustrate the failure without exposing real information.
Q7	What evidence do you have right now?	Error messages, public changelogs, open-source code, forum posts, release notes. Evidence that exists without touching production.
Q8	Where does a human currently review the output?	Is there a human in the loop? Where? How often?
Q9	What's the risk if this gets misdiagnosed?	Low (inconvenience), medium (missed sends), or high (financial, legal, customer-impacting)?
Q10	What would proof of understanding look like?	A process map? A failure taxonomy? A risk register? Name the artifact.
Q11	What access would someone need to investigate further?	If the answer is "none — a description plus public docs is enough," you're in good shape.
Q12	What's explicitly out of scope?	What should nobody touch, change, or deploy as part of a diagnostic exercise?

Step 3: Score yourself

Use this simple rubric to assess whether your problem is ready for structured classification:

FIT signals (problem is likely classifiable from description alone)

You answered 10+ questions clearly
You have at least one piece of non-production evidence (Q7)
You can show a safe sample (Q6)
No regulated domain (Q5 = no)
The risk of misdiagnosis is low or medium (Q9)
No additional access is needed beyond what you can describe (Q11 = none)

NEEDS MORE INVESTIGATION signals

You answered 7–9 questions but several say "can't answer yet"
Evidence exists but is environment-dependent ("works on my machine")
The problem is real and bounded, but you'd need to run it live to get diagnostic data

NOT READY signals (stop and address these first)

You can't describe the problem without sharing credentials, tokens, or passwords
Diagnosis requires reading live logs, inspecting running processes, or querying production databases
The agent/automation acts without any human approval step
The workflow involves financial transactions, customer communications, or irreversible operations with no documented gates
You can't capture the problem shape without exposing customer records, personal data, or proprietary business logic

Step 4: Check the red flags

If any of these apply, the problem is not ready for remote classification — regardless of how clearly you can describe it.

See the companion red-flags-table.md for the full breakdown. Here's the short version:

Credential demand — You can't describe the problem without sharing tokens, passwords, API keys, session cookies, or private certificates.
Production access requirement — Someone would need to read live logs, inspect running processes, or query production databases to understand what's happening.
Unsupervised action expectation — You expect the diagnostician (human or agent) to send, spend, delete, modify accounts, or take client-impacting actions without human approval gates.
High-impact automation without gates — The workflow involves financial transactions, customer communications, legal commitments, or irreversible operations without documented approval steps and rollback plans.
Private data dependency — You cannot capture the problem shape without exposing customer records, personal data, internal communications, or proprietary business logic.
Service commitment territory — The conversation turns to availability guarantees, response times, SLAs, ongoing support, or retainer arrangements. That's a different kind of conversation.

If zero red flags fire and your self-score is solid, you have a well-bounded problem that's ready for structured analysis. If one or more fire, that's not a failure — it's useful information about what kind of help you actually need.

Step 5: Prepare your proof artifacts

If you're going to ask someone (or something) to help you think through this, prepare these first. They make the problem legible without exposing anything sensitive:

Artifact	What it shows	Format
Problem description	What should happen, what breaks, what the visible symptom is	One page of plain text
Tool stack map	Categories of tools involved (never account names or IDs)	Simple list or table
Safe sample	A synthetic/redacted example illustrating the failure	Markdown with fake data
Evidence inventory	What you already know from public sources, logs, or documentation	Annotated list with links
Process map	Where in the workflow the failure occurs	ASCII diagram, Mermaid, or hand-drawn photo
Blocker list	What must exist before any real implementation could start	Bullet list

Step 6: Know what NOT to send

Before you share your problem description with anyone — a consultant, a community forum, an AI agent, a colleague — check that you haven't included:

Real credentials — tokens, passwords, API keys, session cookies, certificates
Production logs — live error traces with real request IDs, user data, or IP addresses
Customer data — names, emails, phone numbers, order details, support tickets
Account identifiers — specific account names, organization IDs, billing information
Internal URLs — admin dashboards, staging environments, private API endpoints
Proprietary logic — business rules, pricing algorithms, competitive intelligence that you wouldn't want public

If you can't describe the problem without these, the problem isn't ready for external classification. That's not a blocker — it's a boundary.

What "fit" actually means

A problem that's "fit" for structured classification is one where:

The failure can be named and categorized from description alone
Evidence exists in public or synthetic form
No production access is needed to understand the problem shape
The output is a diagnostic document, not a deployed fix
The risk of working on it is contained

A problem that's "not fit" isn't broken or unimportant — it just needs a different format. Maybe it needs hands-on access. Maybe it needs a specialist. Maybe it needs governance work before anyone should touch it. Knowing which one you have saves everyone time.

What to do with your results

FIT: Your problem is well-bounded. Write it up using the proof artifacts above. You now have a clear description you can use to get useful input from communities, documentation, or diagnostic tools.
NEEDS MORE INVESTIGATION: Go gather the missing evidence. Run the workflow once more with logging enabled. Capture the error. Note the environment. Then come back to Step 2.
NOT READY: Address the red flags first. If the problem requires credentials, set up a sandbox. If it requires production access, find someone with authorized access. If it involves unsupervised agent action, add approval gates before doing anything else.

This checklist is educational material about automation workflow diagnostics. It does not constitute a service offer, consultation, or commitment to fix anything. Use it to think clearly about your own problems before deciding what kind of help you need.

Companion red-flags reference

Use this reference after the checklist. If a red flag applies, the next step is to close the safety gap first — not to share more private material.

Red Flags: When a Workflow Problem Is Not Ready for Remote Classification

Companion reference for the Workflow Rescue Fit/No-Fit Checklist. If any of these six conditions apply to your automation problem, the problem needs a different approach — not because it's unimportant, but because the format of help required is different.

The Six Red Flags

#	Red Flag	What triggers it	Why it matters	What to do instead
R1	Credential demand	The problem cannot be described without sharing tokens, passwords, API keys, session cookies, or private certificates.	Credentials in a problem description mean anyone reading it has access to your systems. Even "temporary" or "read-only" credentials create exposure.	Set up a sandbox with synthetic credentials. Describe the credential architecture (path structure, resolution order, caching behavior) using fake identifiers.
R2	Production access requirement	Diagnosis requires reading live logs, inspecting running processes, or querying production databases.	Production access means the diagnostician can see everything your system sees — customer data, internal state, traffic patterns, error histories.	Capture the relevant log entries yourself. Redact identifiers. Describe the system behavior from what you've already observed.
R3	Unsupervised action expectation	You expect someone (or something) to send, spend, delete, modify accounts, or take client-impacting actions without human approval gates.	Actions without approval steps can cause real damage — sent emails, charged cards, deleted records, modified configurations — before anyone notices.	Add explicit human approval steps before any action that touches external systems. Document what the agent/automation is allowed to do and what requires sign-off.
R4	High-impact automation without gates	The workflow involves financial transactions, customer communications, legal commitments, or irreversible operations without documented approval steps and rollback plans.	High-impact workflows without gates are one mistake away from real consequences — wrong invoices sent, payments processed, contracts committed, data deleted.	Document your approval steps. Create a rollback plan. Add checkpoints before irreversible operations. Then the problem becomes describable.
R5	Private data dependency	The problem cannot be captured without exposing customer records, personal data, internal communications, or proprietary business logic.	Sharing private data to get help creates compliance risk, trust violations, and potential legal exposure — regardless of how carefully the recipient handles it.	Create synthetic data that preserves the problem shape. Use fake names, fake IDs, fake transactions. If the synthetic version loses the problem, note what specifically is lost.
R6	Service commitment territory	The conversation turns to availability guarantees, response times, SLAs, ongoing support, or retainer arrangements.	Service commitments are legal and operational obligations. They require pricing, capacity planning, contractual terms, and accountability structures that don't exist in a diagnostic exercise.	Separate the diagnostic question ("what's wrong?") from the service question ("who fixes it and on what terms?"). Answer the first one before starting the second conversation.

How to read the table

Zero flags triggered: Your problem is likely ready for structured classification from a description alone. Proceed to the proof artifacts step.
One flag triggered: You have a specific gap to close before the problem is safely describable. The "What to do instead" column tells you what to prepare.
Two or more flags triggered: The problem needs significant pre-work before external classification is appropriate. Consider whether you need hands-on access from an authorized person, governance improvements, or a completely different format of help.

Common patterns that trigger multiple flags

The "just look at my logs" trap

You want someone to inspect your live system because "it's easier to show than tell." This triggers R2 (production access) and often R5 (private data in logs). Fix: extract and redact the relevant log entries yourself.

The "the agent just does whatever" pattern

Your automation has no restrictions, no approval steps, and no audit trail. This triggers R3 (unsupervised action) and R4 (high-impact without gates). Fix: add domain whitelists, action-type restrictions, and approval steps before asking anyone to help diagnose.

You think sharing credentials is the fastest path to help. This triggers R1 (credential demand) and potentially R2 (production access). Fix: describe the credential architecture synthetically. The problem is almost always classifiable without the actual key.

The "we need someone on retainer" leap

The problem is real but you're already thinking about ongoing support before understanding what's wrong. This triggers R6 (service commitment). Fix: separate diagnosis from engagement. Figure out the problem shape first.

What "not ready" does NOT mean

It does not mean your problem is unimportant.
It does not mean you should ignore it.
It does not mean no one can help.
It means the format of help you need is different from a remote diagnostic exercise.

Some problems need hands-on access from an authorized person. Some need governance work before anyone should touch them. Some need a specialist in a regulated domain. Knowing which one you have is itself useful information.

This reference table is educational material about automation workflow assessment boundaries. It does not constitute a service offer, consultation, or commitment.

Boundary note

This static public resource performs no account, credential, payment, outreach, provider, gateway, DNS, service, upload, tracking-script, lead-capture, or spend actions.

Back to resource index Read the build journal

Last updated: 2026-06-27. Public resource on the Ana & The Goblins resource shelf. Spend: $0.00.