Reusable AI capability
Reconstruct Agent Delegation and Authority Chains
Apply a repeatable principal-chain method to determine which identity acted, what authority was delegated, where context changed, and which actions require repair or review.
This Skill packages a reusable way to use the linked Prompt or Workflow; Amo.ng does not run it for you.
# Reconstruct Agent Delegation and Authority Chains Skill ID: AMO-S-000010 Skill URL: https://amo.ng/skills/reconstruct-agent-delegation-and-authority-chains Purpose: Give security, platform, and service owners a reusable capability for tracing agent, user, service, connector, tool, and downstream-system authority across incidents, design reviews, and access-control investigations. Required inputs: - Agent, user, service, tool, connector, and downstream-system identities in scope - Delegation contracts, permission policies, token or credential metadata, and revocation rules - Tool calls, traces, messages, audit logs, state changes, and affected actions - Expected principal propagation and authorization boundaries - Investigation window, known impact, accountable owners, and decision constraints How to use: When to use: - A system may have acted as the wrong principal or exceeded delegated authority. - Agent, tool, connector, or downstream audit records disagree about the initiating identity. - A design or release review needs an explicit principal and delegation chain. When not to use: - General agent readiness with no identity or authorization question. - Credential rotation or access changes without evidence and owner authorization. - Treating token possession as proof that an action was permitted. Reusable method: 1. Define the action and authorization question before inspecting evidence. 2. Build a principal ledger for the initiating user or service, agent, tool, connector, and downstream actor. 3. Trace each delegation edge: issuer, recipient, scope, purpose, resource, time, revocation state, and evidence. 4. Compare expected identity propagation with logs, claims, policy evaluation, and downstream authorization. 5. Classify each edge as supported, contradicted, unresolved, stale, broadened, confused-deputy, or missing context. 6. Identify affected actions without assuming every action in the time window used the defective path. 7. Define the smallest repair, revocation or reauthorization test, audit-correlation requirement, and restart gate. Expected output: A principal and delegation map, evidence ledger, first failed boundary, affected-action register, uncertainty, repair controls, regression checks, and an owner-bound proceed, contain, or investigate decision. Boundaries: Do not claim token inspection, policy evaluation, revocation, containment, or remediation without evidence. The security reviewer and relevant system or service owner decide containment and risk acceptance; the release owner controls restart or deployment. Source grounding: AMO-P-000285. Applicable Workflow: AMO-W-000012. Powered by Prompt: Agent Identity and Delegated Authorization Failure Review Source ID: AMO-P-000285 https://amo.ng/prompts/agent-identity-and-delegated-authorization-failure-review Completion criteria: Complete when every material action has a supported, contradicted, or unresolved principal chain; delegation scope and revocation state are explicit; the first failed boundary is evidence-linked; affected actions and uncertainty are bounded; and repair plus regression gates have accountable owners. Use this Amo.ng Skill with your preferred AI tool. Supply the required inputs and follow the usage instructions. # Reconstruct Agent Delegation and Authority Chains Skill ID: AMO-S-000010 Skill URL: https://amo.ng/skills/reconstruct-agent-delegation-and-authority-chains Purpose: Give security, platform, and service owners a reusable capability for tracing agent, user, service, connector, tool, and downstream-system authority across incidents, design reviews, and access-control investigations. Required inputs: - Agent, user, service, tool, connector, and downstream-system identities in scope - Delegation contracts, permission policies, token or credential metadata, and revocation rules - Tool calls, traces, messages, audit logs, state changes, and affected actions - Expected principal propagation and authorization boundaries - Investigation window, known impact, accountable owners, and decision constraints How to use: When to use: - A system may have acted as the wrong principal or exceeded delegated authority. - Agent, tool, connector, or downstream audit records disagree about the initiating identity. - A design or release review needs an explicit principal and delegation chain. When not to use: - General agent readiness with no identity or authorization question. - Credential rotation or access changes without evidence and owner authorization. - Treating token possession as proof that an action was permitted. Reusable method: 1. Define the action and authorization question before inspecting evidence. 2. Build a principal ledger for the initiating user or service, agent, tool, connector, and downstream actor. 3. Trace each delegation edge: issuer, recipient, scope, purpose, resource, time, revocation state, and evidence. 4. Compare expected identity propagation with logs, claims, policy evaluation, and downstream authorization. 5. Classify each edge as supported, contradicted, unresolved, stale, broadened, confused-deputy, or missing context. 6. Identify affected actions without assuming every action in the time window used the defective path. 7. Define the smallest repair, revocation or reauthorization test, audit-correlation requirement, and restart gate. Expected output: A principal and delegation map, evidence ledger, first failed boundary, affected-action register, uncertainty, repair controls, regression checks, and an owner-bound proceed, contain, or investigate decision. Boundaries: Do not claim token inspection, policy evaluation, revocation, containment, or remediation without evidence. The security reviewer and relevant system or service owner decide containment and risk acceptance; the release owner controls restart or deployment. Source grounding: AMO-P-000285. Applicable Workflow: AMO-W-000012. Powered by Prompt: Agent Identity and Delegated Authorization Failure Review Source ID: AMO-P-000285 https://amo.ng/prompts/agent-identity-and-delegated-authorization-failure-review Completion criteria: Complete when every material action has a supported, contradicted, or unresolved principal chain; delegation scope and revocation state are explicit; the first failed boundary is evidence-linked; affected actions and uncertainty are bounded; and repair plus regression gates have accountable owners.Copy skill copies the Skill details. Use with AI adds a short instruction for your preferred AI tool; neither action runs the Skill.
Purpose
Give security, platform, and service owners a reusable capability for tracing agent, user, service, connector, tool, and downstream-system authority across incidents, design reviews, and access-control investigations.
Required inputs
Have these details available before following the usage instructions.
- Agent, user, service, tool, connector, and downstream-system identities in scope
- Delegation contracts, permission policies, token or credential metadata, and revocation rules
- Tool calls, traces, messages, audit logs, state changes, and affected actions
- Expected principal propagation and authorization boundaries
- Investigation window, known impact, accountable owners, and decision constraints
How to use this Skill
When to use:
- A system may have acted as the wrong principal or exceeded delegated authority.
- Agent, tool, connector, or downstream audit records disagree about the initiating identity.
- A design or release review needs an explicit principal and delegation chain.
When not to use:
- General agent readiness with no identity or authorization question.
- Credential rotation or access changes without evidence and owner authorization.
- Treating token possession as proof that an action was permitted.
Reusable method:
1. Define the action and authorization question before inspecting evidence.
2. Build a principal ledger for the initiating user or service, agent, tool, connector, and downstream actor.
3. Trace each delegation edge: issuer, recipient, scope, purpose, resource, time, revocation state, and evidence.
4. Compare expected identity propagation with logs, claims, policy evaluation, and downstream authorization.
5. Classify each edge as supported, contradicted, unresolved, stale, broadened, confused-deputy, or missing context.
6. Identify affected actions without assuming every action in the time window used the defective path.
7. Define the smallest repair, revocation or reauthorization test, audit-correlation requirement, and restart gate.
Expected output:
A principal and delegation map, evidence ledger, first failed boundary, affected-action register, uncertainty, repair controls, regression checks, and an owner-bound proceed, contain, or investigate decision.
Boundaries:
Do not claim token inspection, policy evaluation, revocation, containment, or remediation without evidence. The security reviewer and relevant system or service owner decide containment and risk acceptance; the release owner controls restart or deployment. Source grounding: AMO-P-000285. Applicable Workflow: AMO-W-000012.
Powered by an Amo.ng Prompt
Agent Identity and Delegated Authorization Failure Review
Open the linked prompt to use the instructions that power this Skill.
Open prompt
Review the supplied evidence to determine which principal acted, under which delegated authority, at each agent, tool, and downstream-system boundary, and where that principal-authority binding failed.
Focus on agent identity spoofing, confused-deputy behavior, stale delegation, wrong-principal actions, and authorization-context loss. Do not perform a broad agent security audit. Do not infer inspection, execution, approval, containment, or remediation unless the supplied evidence supports it.
Context to provide:
- Incident or workflow name: [Incident or workflow name]
- Time window: [Time window]
- Agent and tool boundary description: [Agent and tool boundary description]
- Evidence bundle: [Evidence bundle]
- Delegation policy sources: [Delegation policy sources]
- Accountable owners: [Accountable owners]
Evidence discipline:
- Separate observed facts from inference, hypothesis, and missing information.
- Treat logs, traces, request IDs, token claims, policy excerpts, configuration snapshots, audit events, tickets, and owner statements as evidence only when supplied.
- Preserve uncertainty when timestamps conflict, identities are aliased, policies are incomplete, or downstream enforcement behavior is not evidenced.
- Do not assume that the initiating user, agent runtime identity, tool credential, service account, and downstream effective principal are the same.
- If a claim depends on unavailable evidence, state what evidence would be needed and which owner should provide or verify it.
Authority boundaries:
- Do not declare the issue fixed, contained, approved, or closed without evidence tied to a security reviewer, system owner, data owner, release owner, or service owner named in the supplied context.
- Do not recommend bypassing authorization checks, expanding privileges for convenience, or relying on logging as a substitute for enforcement.
- Prefer the smallest containment and repair steps that restore correct principal binding while preserving legitimate workflow behavior.
Produce the following deliverable.
1. Review scope and evidence inventory
- State the workflow, systems, principals, tools, downstream services, and time window actually covered by the evidence.
- List supplied evidence by type and relevance.
- List important evidence not provided, including why it matters.
- State confidence level for the review and the main reasons for that confidence.
2. Principal and delegation chain
Create a step-by-step chain showing how authority was carried or transformed across boundaries. Use a table with these columns:
- Step
- Timestamp or sequence marker
- Boundary crossed
- Request, trace, job, or session identifier
- Initiating principal
- Agent runtime principal
- Tool or connector principal
- Downstream effective principal
- Delegated authority claimed
- Delegation source or policy reference
- Token, credential, session, or capability involved
- Observed action
- Evidence citation from supplied material
- Confidence
- Missing evidence or ambiguity
Call out every point where identity was asserted, translated, delegated, cached, proxied, impersonated, or lost.
3. Authorization failure chronology
Build a concise chronology of the failure path. For each event, identify:
- What happened
- Which principal appeared to act
- Which principal should have been authoritative, if determinable
- What delegated authority was present, stale, missing, overbroad, or misapplied
- Whether the event indicates spoofing, confused deputy behavior, stale delegation, wrong-principal action, authorization-context loss, or another clearly named failure mode
- What evidence supports the classification
- What remains uncertain
4. Action-to-authority matrix
Create a matrix mapping each consequential action to the authority required and the authority actually observed. Use these columns:
- Action or operation
- Resource or data scope
- Required principal or role
- Required delegation condition, scope, audience, tenant, time limit, or consent
- Observed principal
- Observed delegated authority
- Enforcement point expected
- Enforcement point evidenced
- Decision observed, such as allowed, denied, skipped, inherited, cached, or unknown
- Mismatch type
- Potential impact
- Evidence citation
Highlight actions where the system accepted an authority context that was missing, stale, meant for another audience, meant for another tenant, too broad, inherited from the wrong actor, or not revalidated downstream.
5. Affected scope
Separate confirmed, likely, possible, and not evidenced impact. Cover:
- Users, tenants, accounts, workspaces, repositories, environments, datasets, secrets, transactions, or external systems affected
- Time interval of exposure
- Data or operations reachable under the mistaken authority
- Whether unauthorized read, write, execute, approve, delete, publish, spend, or disclose actions are evidenced
- Whether lateral movement, replay, token reuse, cached delegation, or downstream propagation is evidenced or merely plausible
- Constraints that limit impact
6. Containment and identity-control repair gates
Define repair gates that accountable owners can use to decide whether the workflow may resume or continue operating. Include immediate containment and durable control gates.
For each gate, provide:
- Gate name
- Failure it addresses
- Required control or change
- Owner accountable for verification
- Evidence required to pass
- Pass criteria
- Fail or block condition
- Residual risk if accepted
Include gates where relevant for:
- Principal provenance at agent start and tool-call time
- Delegation freshness and revocation handling
- Audience, tenant, resource, and scope binding
- Prevention of confused-deputy delegation reuse
- Downstream reauthorization rather than blind trust in upstream context
- Service account and connector credential separation
- Audit correlation across user, agent, tool, and downstream identifiers
- Token, session, capability, or cached grant invalidation
- Least-privilege restoration without breaking legitimate workflow paths
7. Owner decision record
Prepare a decision-ready summary for the named accountable owners. Include:
- Most likely root cause, stated with confidence and evidence basis
- Highest-risk unresolved uncertainty
- Minimum containment required before further use
- Minimum identity-control repair required before normal operation
- Verification tasks by owner role
- Open questions that block a defensible decision
- Items that can be safely deferred, with rationale
Completion checks:
- Confirm that the principal and delegation chain covers each supplied boundary or states why a boundary could not be assessed.
- Confirm that every consequential action is mapped to required and observed authority, or marked unknown with missing evidence.
- Confirm that affected scope distinguishes observed impact from plausible but unproven exposure.
- Confirm that each repair gate has an accountable owner, evidence requirement, and pass/fail criterion.
- Do not present remediation as complete unless evidence supplied in the prompt demonstrates completion.
Completion criteria
Complete when every material action has a supported, contradicted, or unresolved principal chain; delegation scope and revocation state are explicit; the first failed boundary is evidence-linked; affected actions and uncertainty are bounded; and repair plus regression gates have accountable owners.
Explore related Workflows
Browse WorkflowsInvestigate an AI Agent Security Incident
Reconstruct an AI agent incident, trace delegated authority and sensitive context, conditionally investigate memory or RAG authorization, and prepare evidence-based containment and recovery gates.
Related Prompts
Browse PromptsAgent Memory Integrity and Poisoning Investigation
Investigate persistent agent memory for poisoning, misattribution, over-retention, or unauthorized alteration and produce a defensible containment and recovery decision.
Investigate whether persistent agent memory was altered, misattributed, over-retained, or poisoned, and produce an evidence-backed containment and recovery decision. Context to provide: - Agent or system name: [Agent or system name] - Investigation window: [Investigation window] - Memory stores and schemas: [Memory stores and schemas] - Available evidence: [Available evidence] - Known suspicious symptoms: [Known suspicious symptoms] - Decision owner: [Decision owner] - Recovery authority boundaries: [Recovery authority boundaries] Evidence rules: - Use only the evidence provided in [Available evidence]. Do not claim that logs, traces, memory stores, tickets, approvals, tests, commands, or source files were inspected unless they are included or quoted. - Separate observations from inference. Label each inferred conclusion as low, medium, or high confidence. - Preserve uncertainty. If a required fact is missing, state exactly what evidence is needed and why it matters. - Before attributing compromise or selecting containment, separate blocking gaps from non-blocking gaps. Request all blocking evidence in one consolidated clarification and stop the affected conclusion until it is supplied. Continue past non-blocking gaps only when they are recorded as Unknown with their effect on confidence, scope, containment, and recovery. - Do not broaden this into a general agent security audit or a generic trace taxonomy. Stay focused on persistent memory integrity, provenance, poisoning, retention, attribution, and recovery. - Treat containment and recovery as accountable operational decisions. If an action exceeds [Recovery authority boundaries], identify the responsible owner or function that must decide. Investigation method: 1. Establish scope - Define which memory stores, records, embeddings, summaries, preference stores, tool-state caches, user profile memories, system memories, and derived memories are in scope based on [Memory stores and schemas]. - Identify what is out of scope and any assumptions required because evidence is missing. 2. Build a memory provenance ledger Create a ledger table with these columns: - Memory item or record ID - Current stored claim or value - Memory type or store - First observed timestamp, if known - Last modified timestamp, if known - Claimed source or author - Evidence supporting source attribution - Write or update path - Retention basis or deletion expectation - Integrity concern: none, altered, misattributed, over-retained, suspicious insertion, suspicious deletion, unverifiable - Confidence level - Evidence references - Required follow-up evidence 3. Reconstruct write paths For each memory store or memory type, reconstruct: - Authorized writers and expected write triggers - Observed or reported writes during [Investigation window] - Transformation steps from raw input to persisted memory - Summarization, embedding, deduplication, merge, overwrite, deletion, or compaction behavior - Identity and attribution mechanisms used at write time - Retention and deletion controls - Plausible bypasses, race conditions, stale-cache paths, ingestion errors, or cross-user contamination paths - Evidence gaps that prevent confirmation 4. Develop a poisoning hypothesis matrix Create a matrix with these columns: - Hypothesis - Poisoning or integrity failure mechanism - Memory items affected - Supporting observations - Contradicting observations - Missing evidence needed - Likelihood: low, medium, high, or indeterminate - Potential blast radius - Immediate containment implication Include at least these hypothesis categories when relevant to the evidence: - Malicious prompt or tool output caused durable memory insertion - Benign user input was misattributed to another user, tenant, workflow, or authority - Summarization or consolidation distorted source meaning - Outdated memory was over-retained after deletion, revocation, policy change, or user correction - Memory merge or deduplication combined incompatible identities, accounts, or contexts - Retrieval surfaced poisoned or stale memory into later decisions - Administrative, migration, sync, or backfill process altered memory incorrectly - Evidence does not support a memory poisoning finding, but confidence is limited 5. Map affected decisions Create an affected-decision map with these columns: - Decision, action, response, workflow, or automation potentially influenced - Memory items used or likely retrieved - Evidence of use versus plausible exposure - Business, safety, security, privacy, financial, or user impact - Reversibility - Owner accountable for review - Required validation before relying on the decision again Do not assume a decision was affected solely because a memory item exists. Distinguish confirmed use, likely use, possible use, and no evidence of use. 6. Decide containment posture Recommend one of these containment states for each affected memory store or memory class: - No containment needed based on current evidence - Monitor only - Read-only quarantine - Retrieval suppression - Write suspension - Record-level deletion or correction pending owner approval - Full memory store isolation - Agent workflow suspension For each recommendation, provide: - Evidence basis - Risk reduced - Operational cost or user impact - Decision owner required - Time sensitivity - Reversal condition 7. Define recovery gate Produce a quarantine and recovery gate that [Decision owner] can use. Include: - Minimum evidence required before restoring memory retrieval or writes - Records that must be corrected, deleted, re-attributed, or re-generated - Regression checks or replay checks needed, if evidence supports them - Owner approvals required under [Recovery authority boundaries] - Monitoring signals after restoration - Conditions that require escalation rather than recovery 8. Final decision artifact End with a concise decision record: - Investigation conclusion: confirmed compromise, likely compromise, possible compromise, no compromise found, or indeterminate - Confidence and primary uncertainty - Memory stores or records requiring action - Affected decisions requiring review - Immediate containment decision - Recovery gate status: not ready, conditionally ready, or ready - Named accountable owner for the next decision - Evidence not available that would materially change the conclusion Completion checks before finalizing: - Every material conclusion cites evidence from [Available evidence] or is explicitly labeled as inference. - The memory provenance ledger, write-path reconstruction, poisoning hypothesis matrix, affected-decision map, and quarantine/recovery gate are all included. - Missing evidence is stated plainly rather than filled with assumptions. - No source, system, command, test, approval, or inspection is claimed without corresponding evidence. - The recommended action stays within [Recovery authority boundaries] or identifies the accountable owner who must authorize it.Multi-Agent Coordination Failure Reconstruction
Reconstructs a multi-agent failure to find the first coordination divergence and produce a corrected handoff contract with testable verification.
Reconstruct the coordination failure across multiple agents and identify the first coordination divergence that can be corrected and tested. Inputs to provide: - Agent roles and authority: [Agent roles and authority] - Coordination evidence: [Coordination evidence] - Expected handoff contract: [Expected handoff contract] - Shared-state context: [Shared-state context] - Observed failure and impact: [Observed failure and impact] - Constraints and authorized changes: [Constraints and authorized changes] Evidence discipline: - Separate observed evidence from inference at every major step. - Do not claim that a log, trace, source file, system, test, approval, or action was inspected unless it is present in the provided material. - If timestamps, message ordering, state versions, ownership rules, or agent responsibilities are missing, name the gap and explain how it affects confidence. - Preserve uncertainty where the evidence supports more than one explanation. - Do not redesign the entire multi-agent workflow. Focus on the smallest correction to the failed coordination point. - Do not produce a broad trace taxonomy. Use classification only where it helps isolate the first divergence. Reconstruction method: 1. Build an evidence inventory listing each provided artifact, what it can prove, and what it cannot prove. 2. Create a coordination chronology from the earliest relevant trigger through the failure manifestation. 3. Map responsibility, authority, and shared-state access for each involved agent. 4. Compare expected coordination behavior against observed behavior. 5. Identify the first point where delegation, handoff, ownership, message ordering, or shared state diverged from the expected contract. 6. Decide the most likely failure mechanism and explain why competing mechanisms are less supported. 7. Define discriminating tests that could confirm or falsify the proposed mechanism. 8. Draft a corrected handoff contract that is narrow, testable, and preserves intended existing behavior. Deliverable format: 1. Evidence inventory Provide a table with columns: - Artifact - Evidence observed - Reliability or limitation - Coordination question it helps answer - Missing information, if any 2. Coordination chronology Provide an ordered table with columns: - Step or timestamp - Agent - Message, action, or state operation - Intended recipient or owner - Shared state read or written - Expected behavior - Observed behavior - Evidence reference - Observation vs inference - Confidence: high, medium, or low 3. Responsibility and state map For each relevant agent, list: - Delegated responsibility - Decision authority - Required inputs - State it may read - State it may write - Handoff obligations - Acknowledgment or completion signal - Actual behavior seen in evidence - Ownership ambiguity or conflict, if any Then list shared-state objects or records with: - State object - Expected owner - Writers - Readers - Versioning or ordering assumption - Observed mutation or stale-read risk - Evidence supporting the risk 4. First coordination divergence State the earliest supported divergence in one sentence. Then provide: - Divergence type: delegation gap, handoff ambiguity, ownership conflict, message-ordering violation, stale shared state, unauthorized state mutation, missing acknowledgment, retry/idempotency failure, or other specified mechanism - Exact expected contract at that point - Exact observed deviation - Why this is earlier than downstream symptoms - Evidence supporting the decision - Confidence level - What evidence would change the conclusion 5. Failure mechanism decision Compare the leading mechanism against plausible alternatives in a table: - Candidate mechanism - Supporting evidence - Contradicting or missing evidence - Predicted observable signal - Decision: selected, possible, unlikely, or not assessable 6. Discriminating tests Propose 3 to 6 tests or checks that the accountable engineering, automation, or operations owner can run. For each, include: - Hypothesis tested - Setup or evidence required - Expected signal if the mechanism is correct - Expected signal if the mechanism is wrong - Owner best placed to verify - Risk of false positive or false negative Prefer tests that distinguish between message-ordering, ownership, handoff, and shared-state causes rather than merely reproducing the incident. 7. Corrected handoff contract Draft the smallest safe correction. Include: - Trigger condition - Sending agent - Receiving agent - Required payload or state reference - Preconditions - State version or ordering requirement - Acknowledgment rule - Completion signal - Timeout or retry behavior - Idempotency requirement - Conflict handling rule - Audit fields or log events needed for future reconstruction - Backward-compatibility or behavior-preservation note 8. Implementation boundary State what should not be changed yet because the evidence does not justify it. Call out any broad workflow redesign, new orchestration pattern, or policy change that would be premature. 9. Completion checks List observable criteria for considering this reconstruction complete, including: - The first divergence is identified or the blocking evidence gap is explicit. - The selected mechanism has at least one discriminating test. - The corrected handoff contract is narrow enough for the responsible owner to implement or reject. - The release owner, automation owner, or service owner can verify the proposed correction against logs, replay, tests, or production telemetry before adoption.Agent Tool-Call Recovery and Idempotency Design
Design reliable AI agent tool execution that survives timeouts, retries, duplicate delivery, partial effects, stale approvals, and uncertain recovery.
You are a senior distributed-systems and AI-agent reliability architect specializing in tool contracts, side-effect safety, durable orchestration, idempotency, retries, reconciliation, compensation, approvals, and production recovery. Your task is to assess the supplied agent and tool architecture and produce an implementation-ready design for safe tool execution when requests time out, responses are lost, calls are duplicated, effects complete partially, approvals become stale, or automated recovery cannot determine what happened. The result must define the system boundary, execution guarantees, durable state model, operation identity, idempotency contract, retry policy, authoritative reconciliation process, compensation behavior, human recovery controls, fault-injection tests, and operational rollout plan. ## Context to Provide Replace every bracketed placeholder with the best available evidence. If critical information is missing, ask for it in one consolidated list before recommending a production design. If a missing detail is non-critical, continue only with a clearly labeled assumption. - [Agent objective, users, and operating boundaries] - [Tool inventory and contracts] - [Orchestration and persistence architecture] - [Side effects, business objects, and criticality] - [Failure, timeout, and incident evidence] - [Retry, queue, and delivery semantics] - [Idempotency and deduplication behavior] - [Confirmation, approval, and authorization rules] - [Status, reconciliation, and compensation capabilities] - [Observability, audit, privacy, and security requirements] - [Service objectives and recovery constraints] - [Definition of done] ## Evidence and Analysis Rules - Do not invent tool behavior, delivery guarantees, identifiers, schemas, error meanings, transaction boundaries, status endpoints, incidents, metrics, owners, approvals, test results, or recovery capabilities. - Separate confirmed evidence, inference, assumption, hypothesis, unknown, risk, recommendation, and decision. - Record the environment, version, date, source, and limitation of material evidence where available. - Preserve conflicting evidence until a specific check resolves it. - Do not describe an inspection, command, query, test, reconciliation, approval, or recovery action as completed unless its result was supplied. - Use `Not provided`, `Not inspected`, `Not run`, `Unknown`, or `To be agreed` where appropriate. - Redact credentials, tokens, personal data, customer records, confidential payloads, and unnecessary business values. - Prefer sanitized schemas, request fingerprints, state records, identifiers, and structured event examples over complete production payloads. - Tie every recommendation to a finding, accountable owner, verification method, and observable acceptance condition. - Identify whether each conclusion applies to one tool, one environment, one tenant, one workflow, or the complete agent system. - Do not extrapolate a guarantee from one component to the complete end-to-end workflow. ## Required Terminology and Boundaries Model the following concepts separately: 1. **Business intent:** The outcome the user or authorized system intended. 2. **Logical operation:** One durable instruction to pursue that intent. 3. **Execution attempt:** One transmission or invocation of the operation. 4. **External effect:** A change created in the tool or downstream system. 5. **Acknowledgment:** Evidence that a request was received or accepted. 6. **Authoritative result:** Evidence that establishes the final effect state. 7. **Compensation:** A separate business action intended to offset an earlier effect. 8. **Recovery action:** An automated or human action used to resolve an unknown or failed state. Do not use request ID, trace ID, correlation ID, attempt ID, operation ID, provider object ID, and idempotency key as though they are interchangeable. Do not claim “exactly once” execution without defining: - what occurs once; - within which system boundary; - for which identity and retention period; - under which failure and replay assumptions; - whether the guarantee covers invocation, durable state change, external effect, notification, or complete business outcome. Where appropriate, use narrower language such as: - at-most-once effect within the deduplication window; - at-least-once delivery with idempotent effect handling; - effectively-once business outcome under stated assumptions; - duplicate suppression within a defined scope; - unknown outcome requiring reconciliation. ## Core Safety Principles - A timeout proves only that the caller did not receive a timely response. It does not prove that the tool performed no effect. - An accepted, queued, or dispatched response is not authoritative completion unless the tool contract explicitly defines it that way. - Generate or assign one stable idempotency key for each logical operation and durably reuse it across retries, restarts, workers, and redeliveries. - A random high-entropy key is acceptable when generated once per logical operation. Never generate a new key merely because an attempt is retried. - Do not place secrets, personal data, email addresses, account details, or sensitive business values inside idempotency keys. - Scope idempotency by the identities needed to prevent cross-tenant, cross-environment, cross-tool, or cross-operation collisions. - Bind the key to a canonical fingerprint of the material request. Reject reuse of the same key with materially different intent or parameters. - Make the retention period longer than the maximum queue delay, retry window, replay window, outage recovery period, late-response window, and expected manual recovery delay—or explicitly block and reconcile attempts that arrive after expiry. - Where possible, record the idempotency decision and commit the protected state change atomically. - When atomicity cannot span the external tool, identify the crash gap and use an appropriate pattern such as a transactional outbox, inbox deduplication, effect journal, provider operation identifier, or reconciliation worker. - Place automatic retries at one deliberate layer unless evidence justifies retries at multiple layers. - Bound retries by attempt count, elapsed deadline, backoff, jitter, retry budget, dependency health, and business validity. - Cancellation does not prove that an already-dispatched effect was prevented. Reconcile an in-flight operation before declaring it cancelled. - Compensation is not equivalent to rollback. It may be partial, delayed, externally visible, chargeable, irreversible, or independently unsuccessful. - Bind consequential approval to the exact action, target, material parameters, object version, authority, approver, and expiry. - Require new approval if user intent, recipient, amount, permissions, object state, policy, price, or another material input changes. - Make automated and manual recovery concurrency-safe so two workers or operators cannot apply conflicting remedies. - Require authoritative reconciliation before converting an unknown outcome into confirmed success or confirmed failure. ## Required Design Workflow ### 1. Establish Input Sufficiency and System Boundary Define: - the agent’s objective and authorized users; - the systems and environments in scope; - where the logical operation begins and ends; - which component owns orchestration state; - which system is authoritative for each business object and effect; - the delivery semantics of every queue, scheduler, webhook, and worker; - the assumptions under which safe recovery is expected; - critical missing information that prevents a reliable design. ### 2. Inventory Tool Effects and Contracts For every tool operation, identify: - action and business purpose; - input and output contract; - effect type; - preconditions and postconditions; - synchronous, asynchronous, or mixed completion; - authoritative completion evidence; - reversibility and compensation capability; - financial, destructive, permission, privacy, customer, or external communication impact; - native idempotency support; - provider operation or object identifiers; - status lookup and reconciliation capability; - error taxonomy; - timeout and rate-limit behavior; - owner and escalation path. Distinguish read-only operations from operations that create, update, delete, publish, send, charge, reserve, approve, grant access, or otherwise produce external effects. ### 3. Define the Execution Guarantee State the strongest guarantee that the available architecture can honestly support. Compare: - at-most-once invocation; - at-least-once delivery; - idempotent processing; - duplicate suppression; - effectively-once effect; - eventual reconciliation; - manual resolution of unknown outcomes. Explain what the guarantee does not cover. If the architecture cannot prevent or reconcile duplicate consequential effects, state this as a blocker rather than describing the workflow as reliable. ### 4. Design Durable Identity Define the purpose and lifecycle of: - agent run ID; - workflow or orchestration ID; - logical operation ID; - idempotency key; - request fingerprint; - execution attempt ID; - trace or correlation ID; - provider request ID; - provider object or effect ID; - approval ID and approval digest; - compensation operation ID; - recovery case ID. For each identifier, specify: - creator; - generation method; - scope; - persistence location; - uniqueness requirement; - propagation path; - retention period; - lookup use; - security restrictions. The request fingerprint must include only material fields and must use a documented canonicalization and versioning rule. ### 5. Design the Execution State Machine Adapt the state names to the supplied system, but explicitly represent: - planned; - awaiting approval; - ready; - dispatching; - accepted or pending; - outcome unknown; - reconciling; - confirmed succeeded; - confirmed failed without effect; - compensation pending; - compensating; - compensated; - manual review; - cancelled before dispatch; - terminal unresolved or abandoned under approved policy. For every state, define: - durable record; - entry condition; - permitted events; - permitted next states; - timeout behavior; - retry eligibility; - responsible component; - authoritative evidence; - customer or operator visibility; - prohibited transitions. Do not permit an in-flight or unknown operation to transition directly to “cancelled with no effect,” “failed with no effect,” or a new execution attempt without the evidence required by the tool contract. ### 6. Design the Idempotency Contract Specify: - logical operation identity; - idempotency-key generation and reuse; - tenant, account, environment, tool, and action scope; - request fingerprint and conflict behavior; - first-request concurrency handling; - duplicate behavior while the first request is in progress; - result storage and semantically equivalent replay; - failure-result treatment; - persistence and atomicity boundary; - retention period and expiry behavior; - late-arriving request behavior; - replay after expiry; - resource deletion or mutation after the original operation; - downstream propagation; - migration and versioning behavior. For concurrent calls with the same key, define whether the system uses locking, leasing, single-flight execution, a uniqueness constraint, compare-and-set, or another proven control. For the same key with a different material fingerprint, require an explicit conflict response. Do not silently reinterpret it as a new operation. ### 7. Design Retry and Ambiguous-Outcome Handling Classify each result according to whether the effect is known not to have started, known to have succeeded, known to have failed, or remains unknown. Address at least: - local validation failure before dispatch; - authentication or authorization failure; - connection failure known to occur before request transmission; - connection loss after transmission may have begun; - client timeout after dispatch; - rate limiting and `Retry-After`; - transient dependency failure; - permanent validation or semantic failure; - duplicate or operation-in-progress response; - asynchronous acceptance; - partial multi-step effect; - late success after the caller timed out; - out-of-order webhook or queue delivery; - unavailable status endpoint; - expired idempotency record; - cancelled request whose execution status is uncertain. For each class, choose one action: - correct input; - stop; - retry with the same operation identity; - wait; - query authoritative status; - reconcile; - compensate; - request fresh approval; - open manual recovery; - escalate an incident. Specify maximum attempts, overall deadline, backoff, jitter, retry budget, circuit or load-shedding behavior, and the component permitted to retry. ### 8. Design Reconciliation Define an evidence hierarchy for determining whether an effect occurred. Possible evidence may include: - authoritative provider status; - provider object ID; - effect receipt; - immutable ledger entry; - business-object state; - signed webhook; - transaction or event journal; - downstream confirmation; - local logs and traces. Do not treat local logs or an agent-generated summary as authoritative when a downstream system owns the effect. For each unknown state, specify: - first reconciliation check; - polling or event schedule; - maximum reconciliation duration; - stale-read and eventual-consistency handling; - conflicting-evidence handling; - matching identifiers; - owner; - escalation threshold; - terminal policy when reality remains unknowable. ### 9. Design Approval and Authorization Freshness For every consequential tool call, define: - who can request the action; - who can approve it; - whether separation of duties is required; - exact parameters covered by approval; - object version or state covered by approval; - approval expiry; - cancellation and revocation behavior; - conditions requiring reapproval; - authorization recheck immediately before dispatch; - evidence recorded for audit. Do not infer approval from silence, prior unrelated consent, an earlier materially different request, or an AI-generated interpretation of authority. ### 10. Design Compensation and Manual Recovery For every compensatable operation, define: - effect being compensated; - compensation action; - business and technical preconditions; - authorization and approval; - idempotency identity for the compensation itself; - expected residual effects; - financial or customer impact; - evidence of completion; - retry and reconciliation behavior; - failure handling; - owner and escalation path. Identify irreversible points of no return. For manual recovery, define: - queue and priority; - case payload; - minimum necessary evidence; - sensitive-data restrictions; - claim, lease, or locking behavior; - permitted operator actions; - maker-checker requirement where relevant; - duplicate-operator protection; - service target; - customer communication owner; - closure evidence; - post-recovery reconciliation. ### 11. Design Observability and Auditability Define the logs, traces, metrics, events, dashboards, alerts, and audit records needed to answer: - What did the user intend? - What operation was authorized? - Which attempts were made? - Which component initiated each attempt? - Which idempotency key and fingerprint were used? - What did the tool acknowledge? - What effect is authoritatively confirmed? - Which operations remain unknown? - Was compensation attempted or completed? - Who performed or approved manual recovery? - Did duplicate suppression or a key conflict occur? - Did the retry or reconciliation deadline expire? Keep sensitive payloads and credentials out of telemetry. Use references, hashes, redacted summaries, or protected evidence stores where appropriate. ### 12. Design Tests and Rollout Include deterministic and fault-injection tests for: - duplicate concurrent requests; - worker crash before dispatch; - crash after dispatch but before recording the response; - effect completion followed by response loss; - response recording without effect completion; - asynchronous acceptance followed by later failure; - timeout followed by late success; - retry after process restart; - redelivery after idempotency expiry; - same key with changed parameters; - out-of-order status events; - partial multi-step effects; - stale or revoked approval; - cancellation during dispatch; - compensation failure; - two operators attempting recovery; - tenant-boundary and authorization violations; - unavailable or stale reconciliation sources. Use sandbox, simulation, fault injection, or controlled fixtures before production. Never create real financial, destructive, permission, communication, or customer-visible effects merely to prove the recovery design. ## Output Format Use the following markdown sections. Use tables for mappings, state transitions, ownership, decisions, and test coverage. ### Input Sufficiency and System Boundary Provide: - scope; - systems and environments; - authoritative systems; - supplied evidence; - critical missing inputs; - assumptions; - blockers; - definition of done. ### Guarantee Statement State the proposed end-to-end guarantee, its exact boundary, retention period, assumptions, exclusions, and unresolved limitations. ### Tool Risk Inventory Use: | Tool operation | Effect | Criticality | Completion evidence | Native idempotency | Status lookup | Compensation | Approval | Owner | |---|---|---|---|---|---|---|---|---| ### Identity and Correlation Model Use: | Identifier | Purpose | Created by | Scope | Persisted where | Retention | Propagation | Security restriction | |---|---|---|---|---|---|---|---| ### Execution State Machine Use: | Current state | Event or evidence | Guard condition | Next state | Durable update | Owner | Prohibited alternative | |---|---|---|---|---|---|---| Also identify unreachable, ambiguous, terminal, and manually recoverable states. ### Idempotency Contract Define key generation, reuse, scope, fingerprinting, concurrency, atomicity, replay response, conflicts, retention, expiry, late requests, downstream propagation, and unsupported guarantees. Include implementation-neutral pseudocode for the receive, reserve, execute, record, replay, and conflict paths where useful. ### Retry and Ambiguous-Outcome Matrix Use: | Condition | Effect certainty | Automatic retry | Required identity | Delay or deadline | Reconciliation | Approval consequence | Final fallback | |---|---|---|---|---|---|---|---| ### Approval and Authorization Contract Show how approval is bound to material action details, how freshness is checked, which changes invalidate approval, and who can authorize execution or recovery. ### Reconciliation Protocol Use: | Unknown condition | Authoritative source | Lookup key | Check cadence | Conflict rule | Deadline | Escalation owner | Terminal policy | |---|---|---|---|---|---|---|---| ### Compensation and Human Recovery Plan Separate: 1. Automated compensation 2. Human-assisted recovery 3. Irreversible or non-compensatable effects Document residual effects and secondary failure handling. ### Scenario and Fault-Injection Tests Use: | Test | Failure point | Setup | Expected state | Prohibited effect | Evidence to collect | Pass criteria | |---|---|---|---|---|---|---| Do not mark a test as passed unless its result was supplied. ### Observability and Operations Plan Define: - required events and fields; - dashboards and alerts; - unknown-outcome queue; - reconciliation schedule; - service objectives; - incident roles; - recovery access controls; - retention and redaction; - review cadence; - feedback into tool contracts and agent policy. ### Prioritized Implementation Plan Separate: 1. Immediate containment 2. Design and implementation 3. Controlled validation 4. Production rollout 5. Continuous monitoring For each action, include the finding addressed, owner, prerequisites, validation method, approval gate, rollback or containment method, and acceptance condition. ### Decisions, Risks, and Follow-Up Questions Record unresolved design decisions, accepted risks, blocking questions, accountable owners, and target decision dates. ## Verification Checklist Before finalizing, confirm that: - the business intent, logical operation, attempt, external effect, and compensation are modeled separately; - the end-to-end guarantee has a precise scope and is not described casually as “exactly once”; - a timeout or missing response is not treated automatically as failure; - accepted or queued work is not treated automatically as completed; - one stable idempotency identity survives retries, restarts, redelivery, and worker changes; - the same key with materially different parameters produces a conflict; - idempotency retention covers the documented replay and late-delivery horizon; - the atomicity boundary and every remaining crash gap are explicit; - retry eligibility is based on error class and effect certainty; - retries are bounded and do not multiply uncontrolled across system layers; - unknown consequential effects are reconciled before retry; - approval is bound to material action details and revalidated before execution; - cancellation is not treated as proof that an in-flight effect was prevented; - compensation is treated as a separate fallible operation rather than guaranteed rollback; - automated and human recovery are concurrency-safe and auditable; - credentials and sensitive payloads are excluded from keys, telemetry, and recovery interfaces; - tests cover duplicates, partial effects, late responses, stale approval, expiry, and recovery races; - no unrun test, uninspected artifact, unresolved conflict, or unapproved action is described as complete; - the recommended next action is the smallest safe step that materially reduces uncertainty or risk. ## Final Instruction to Begin Begin by reviewing the supplied context for blocking gaps. If any exist, request them in one consolidated list. Otherwise, establish the system boundary and evidence inventory, then complete the design in the required order.Zapier and Make Automation Audit and Error Handling Plan
Audit a Zapier Zap or Make scenario for brittle steps, duplicate actions, unsafe retries, mapping defects, concurrency risks, silent failures, and weak monitoring, then produce a tested remediation plan.
You are an expert Zapier and Make automation reliability auditor specializing in workflow mapping, data integrity, failure recovery, idempotency, retries, concurrency, monitoring, and production-safe remediation. Inspect the supplied Zapier Zap or Make scenario and produce an evidence-based automation audit and error-handling plan. Identify brittle steps, duplicate-action risks, unsafe retries, data-mapping defects, partial failures, silent data loss, weak alerts, and unsafe recovery procedures. Do not modify, enable, disable, execute, replay, or publish the automation. ## Context Placeholders Use the context below. If critical evidence is missing, request it in one consolidated list before reaching conclusions. If non-critical information is missing, continue with clearly labeled assumptions, unknowns, and unassessed areas. - [Automation platform, plan, and workspace context] - [Workflow name, purpose, owner, and business criticality] - [Zap or scenario diagram, export, outline, and current version] - [Trigger, schedule or webhook, and source-event identity] - [Apps, actions or modules, paths or routers, and filters] - [Field mappings, transformations, and sanitized sample payloads] - [Run history, redacted errors, and incident examples] - [Retry, replay, incomplete-execution, and concurrency settings] - [Duplicate-prevention and idempotency controls] - [Monitoring, alerts, escalation, and response owners] - [Data sensitivity, external side effects, and approval requirements] - [Allowed changes, test environment, rollback constraints, and deadline] ## Important Constraints - Do not invent workflow steps, settings, run results, error messages, payload fields, mappings, app behavior, duplicate counts, feature availability, owners, alerts, or business impact. - Do not assume that Zapier and Make use the same execution, retry, replay, deduplication, transaction, or recovery behavior. - Use the terminology and controls appropriate to the supplied platform. - Verify plan, workspace, application, and connector capabilities before recommending a platform feature. - Do not expose credentials, authentication headers, tokens, connection details, personal data, customer information, payment data, confidential records, or unnecessary payload values. - Use sanitized examples and redacted evidence. - Do not recommend entering secrets or sensitive production data into ChatGPT. - Do not enable, disable, edit, publish, run, replay, or test a live automation. - Do not create, update, delete, send, charge, notify, provision, revoke, or otherwise mutate a production record or account. - Do not assume that a successful automation run produced the correct business outcome. - Do not assume that a failed or timed-out action produced no external side effect. The destination may have completed the action before the automation platform received the response. - Do not treat trigger-level deduplication as end-to-end duplicate protection. - Do not assume that a replay begins from a clean business state. - Identify every action that may create an additional record, send another message, change a status, issue a payment, modify inventory, assign a task, or trigger another automation when repeated. - Classify every material action as: - read-only; - create; - update; - upsert; - delete; - send or notify; - financial or transactional; - external side effect; - unknown. - Classify every action as idempotent, conditionally idempotent, non-idempotent, or unknown. - Do not recommend automatic retries for non-idempotent or unknown actions unless a reliable idempotency, lookup, upsert, uniqueness, or reconciliation control exists. - Distinguish transient errors from permanent, authentication, validation, data-quality, permission, business-rule, quota, and configuration errors. - Do not retry permanent errors indefinitely. - Do not use arbitrary delays as the primary control for duplicate prevention, ordering, or race conditions. - Do not recommend skipping an error when doing so would silently lose required data or conceal an incomplete business process. - Do not recommend substitute values unless their business meaning, downstream effect, and owner approval are established. - Do not assume that rollback can reverse external application side effects. Verify transactional support for every affected operation. - Preserve failed-run evidence needed for diagnosis, reconciliation, and incident review. - Do not invent alert thresholds. Where operating history is missing, define how suitable thresholds should be established. - Separate confirmed evidence, inferred behavior, hypotheses, risks, unknowns, and recommendations. - Tie every material finding to a workflow step, configuration setting, sanitized payload, run-history entry, error record, or documented business requirement. - Require human approval before replaying runs, processing incomplete executions, changing mappings, enabling retries, altering concurrency, sending customer communications, updating financial records, deleting data, or publishing workflow changes. - Make every recommendation specific to the supplied platform, workflow, applications, data, side effects, and operating constraints. ## Audit Instructions 1. Establish: - automation platform and plan; - workflow purpose; - business owner; - technical owner; - source and destination systems; - business criticality; - expected processing volume; - data sensitivity; - allowed changes; - test environment; - decision deadline. 2. Reconstruct the automation from trigger to final outcome. Include: - trigger or schedule; - polling, instant trigger, or webhook behavior; - source-event identifier; - filters; - paths or router branches; - iterators, loops, or aggregators; - transformations; - lookups; - create, update, or upsert operations; - delays; - external API calls; - notifications; - error routes; - final business outcome. 3. For every step, identify: - input; - expected output; - required fields; - side effect; - owner; - idempotency status; - failure behavior; - retry behavior; - evidence available; - monitoring coverage. 4. Review the trigger and source-event identity. Determine: - how new events are identified; - whether the identifier is stable and unique; - what happens when the source sends the same event again; - what happens when an existing event is updated; - whether historical records can re-enter the workflow; - whether polling windows, pagination, webhook retries, or source resends could omit or duplicate events. 5. Audit filters, paths, and router routes. Identify: - missing filters; - overlapping paths or routes; - records matching multiple branches; - records matching no branch; - fall-through behavior; - incorrect boolean logic; - empty, null, malformed, or unexpected values; - filters based on unstable text; - case, whitespace, date, time-zone, currency, and number-format assumptions. 6. Create field-level data lineage for every material mapping: - source field; - transformation; - default or fallback; - validation; - destination field; - destination requirement; - failure behavior; - downstream use. 7. Identify mapping risks involving: - missing fields; - renamed fields; - schema changes; - null values; - empty strings; - unexpected arrays or objects; - type coercion; - number precision; - dates and time zones; - currency and units; - truncation; - invalid identifiers; - stale sample data; - mapped values from the wrong prior step; - default values that conceal errors. 8. Audit duplicate prevention across the complete workflow. Consider: - trigger deduplication; - source-event IDs; - webhook delivery IDs; - destination unique keys; - find-before-create logic; - search-and-update or upsert behavior; - idempotency keys; - data-store or lookup records; - replay behavior; - concurrent runs; - delayed duplicate events; - manual resubmission; - downstream automations triggered by the same write. 9. For every state-changing action, determine what would happen if it ran: - twice; - concurrently; - after a timeout; - after a partial failure; - during manual replay; - during automatic replay or retry; - after the destination succeeded but returned an error; - after mappings or workflow logic changed. 10. Classify failure modes as: - transient and retryable; - rate-limit related; - destination unavailable; - timeout or ambiguous outcome; - authentication or expired connection; - permission related; - invalid or missing data; - mapping or transformation error; - business-rule rejection; - duplicate or conflict; - concurrency or ordering issue; - permanent configuration defect; - unknown. 11. For Zapier, review where applicable: - trigger deduplication and the identifier used; - Zap History evidence; - errored and held runs; - manual replay; - Autoreplay; - whole-run replay; - whether previously successful actions could repeat; - filters and paths; - app-specific create, update, search, and upsert behavior; - custom error handling where present; - connected-account and permission failures. 12. For Make, review where applicable: - modules, bundles, filters, and router routes; - instant and scheduled triggers; - parallel processing and Process data in order; - incomplete executions; - incomplete-execution storage limits and data-loss settings; - Skip, Retry, Resume, Commit, and Rollback handlers; - scenario deactivation behavior; - variable values used during retry; - commit behavior and verified transaction support; - confidential-data logging settings; - iterator and aggregator behavior. 13. Review concurrency and ordering. Determine: - whether runs can overlap; - whether the same record can be processed simultaneously; - whether later events can complete before earlier events; - whether updates can overwrite newer data; - whether incomplete or delayed executions block or reorder processing; - whether locking, version checking, sequence numbers, or reconciliation are required. 14. Identify silent failure conditions, including: - filters dropping valid records; - branches ending without an intended action; - errors converted into successful-looking runs; - skipped bundles or tasks; - fallback values hiding invalid data; - partial completion across routes; - destination success with incorrect mappings; - notification failures; - missing expected processing volume; - failed downstream automations after the originating run succeeded. 15. Design an error-handling strategy. For each failure class, define: - whether retry is appropriate; - required idempotency protection; - retry decision rule; - delay or backoff approach; - maximum attempt policy or how it should be established; - terminal state; - manual-review queue; - alert; - owner; - reconciliation requirement; - evidence retained. 16. Design a controlled test plan covering: - valid input; - empty and null values; - missing required fields; - malformed values; - unexpected data types; - duplicate source event; - concurrent duplicate events; - out-of-order events; - filter and branch boundaries; - mapping transformations; - destination timeout; - rate limit; - authentication failure; - permission failure; - destination validation failure; - destination success with lost acknowledgement; - partial failure; - manual replay; - automatic retry; - alert delivery failure; - rollback or reconciliation. 17. Use isolated accounts, reversible actions, clearly marked sample records, or non-production environments for testing. Where safe testing is unavailable, provide a review procedure rather than recommending production execution. 18. Design monitoring for: - failed runs; - warning or held states; - incomplete executions; - retry volume; - replay volume; - duplicate outcomes; - processing latency; - unexpected record volume; - missing expected runs; - authentication failures; - mapping failures; - records dropped by filters; - reconciliation differences; - disabled or unpublished workflows; - alert-delivery failures. 19. Produce a prioritized remediation plan separating: - immediate containment; - evidence gathering; - duplicate-prevention controls; - mapping corrections; - error-handler improvements; - retry and replay safeguards; - monitoring; - controlled testing; - staged publication; - rollback and reconciliation. ## Output Format Use markdown headings and concise tables. Use platform-specific terminology where applicable. ### Context Review and Evidence Status Provide: | Evidence or Configuration | Supplied | Reliability | Gap | Required Follow-Up | |---|---:|---|---|---| State all assumptions, unknown settings, unavailable run evidence, and platform limitations. ### Executive Reliability Summary Summarize: - workflow purpose; - principal confirmed failure risks; - duplicate and replay exposure; - most important mapping risks; - silent-failure risks; - monitoring gaps; - immediate containment; - owner decisions required. ### Automation Flow Map Provide: | Step | Platform Component | Input | Operation | Output or Side Effect | Idempotency | Failure Behavior | Monitoring | Owner | |---:|---|---|---|---|---|---|---|---| ### Platform Configuration Review Provide: | Configuration Area | Current Evidence | Expected Behavior | Gap or Risk | Verification Required | |---|---|---|---|---| Use only the rows relevant to Zapier or Make. ### Failure Point Register Provide: | ID | Step | Failure Mode | Evidence | Trigger | Side-Effect State | Visibility | Impact | Confidence | Owner | |---|---|---|---|---|---|---|---|---|---| Distinguish confirmed failures from plausible but unverified failure paths. ### Field Mapping and Data Lineage Provide: | Source Field | Transformation | Default or Validation | Destination Field | Requirement | Failure Behavior | Downstream Use | Risk | |---|---|---|---|---|---|---|---| ### Duplicate, Idempotency, and Replay Review Provide: | Action | Event or Record Identity | Duplicate Source | Existing Control | Replay Outcome | Concurrency Risk | Required Safeguard | |---|---|---|---|---|---|---| Explicitly identify actions that could create duplicate messages, tasks, records, payments, notifications, or downstream automation runs. ### Retry and Recovery Decision Matrix Provide: | Failure Class | Retryable? | Reason | Idempotency Requirement | Recovery Method | Terminal State | Manual Review | Owner | |---|---:|---|---|---|---|---|---| Use `Yes`, `No`, `Conditional`, or `Unknown`. Do not recommend automatic retry where the side-effect state is ambiguous and no duplicate protection exists. ### Concurrency and Ordering Review Assess: - overlapping runs; - parallel webhook processing; - stale writes; - out-of-order completion; - incomplete executions; - record locking or version checks; - ordering requirements; - throughput trade-offs. ### Silent Failure Review Provide: | Silent Failure Path | Why It May Appear Successful | Evidence | Business Consequence | Detection Control | Required Fix | |---|---|---|---|---|---| ### Error-Handling Plan For every material failure point, specify: - platform control; - retry or no-retry decision; - error route or handler; - manual-review process; - evidence preserved; - alert; - reconciliation; - owner; - approval gate. ### Controlled Test Plan Provide: | Test | Sanitized Input | Expected Behavior | Side Effect Allowed? | Failure Detected | Evidence to Capture | Approval | |---|---|---|---:|---|---|---| Do not describe any test as passed unless its result was supplied. ### Monitoring and Alert Plan Provide: | Signal | Detection Method | Decision Rule | Severity | Alert Recipient | Required Response | Escalation | Data-Privacy Control | |---|---|---|---|---|---|---|---| Do not invent numeric thresholds without operating evidence. ### Prioritized Remediation Plan Provide: | Priority | Action | Risk Addressed | Platform Location | Owner | Preconditions | Validation | Review Gate | Rollback or Reconciliation | |---:|---|---|---|---|---|---|---|---| ### Publication and Rollback Plan Define: - test completion conditions; - owner approvals; - configuration backup or version record; - publication sequence; - limited initial monitoring; - rollback trigger; - rollback action; - duplicate and partial-run reconciliation; - post-change verification. ### Follow-Up Questions List only questions that could materially change the failure classification, retry decision, duplicate risk, monitoring design, or remediation priority. ## Verification Checklist Before finalizing the audit, confirm that: - the platform, plan, workflow version, purpose, and owner were identified; - Zapier and Make behavior were not treated as interchangeable; - every workflow step and external side effect was mapped; - trigger deduplication was not treated as complete duplicate prevention; - every state-changing action received an idempotency classification; - retryable and non-retryable failures were separated; - no automatic retry was recommended for an unsafe or unknown side effect without duplicate protection; - destination success followed by an error or timeout was considered; - manual replay, automatic retry, and whole-run replay risks were considered where available; - concurrency, parallel processing, race conditions, and event ordering were reviewed; - source-to-destination mappings, transformations, defaults, and validation were documented; - successful technical execution was not treated as proof of a correct business outcome; - skipped, resumed, incomplete, and partially successful processing was reviewed where relevant; - rollback claims were limited to operations with verified transactional support; - sensitive data and credentials were not reproduced; - test recommendations use isolated, reversible, and sanitized conditions; - no live automation was modified, enabled, disabled, executed, replayed, or published; - every alert has a signal, decision rule, recipient, response, and escalation path; - no unperformed test or remediation was described as completed; - every material finding is tied to supplied evidence or clearly labeled as unverified; - production changes, replays, and reconciliation require named human approval. ## Final Instruction to Begin Begin by reviewing the supplied workflow diagram or export, trigger, applications, paths or routers, filters, mappings, run history, retry and replay settings, duplicate incidents, monitoring, and business requirements. If critical evidence is missing, request it in one consolidated list. Otherwise, produce the complete Zapier and Make Automation Audit and Error Handling Plan in the requested markdown format.Webhook Payload Mapping and Schema Drift Audit
Audit webhook payloads, schemas, mappings, and version changes to detect drift before it causes silent data loss, incorrect records, or downstream failures.
You are an expert webhook integration analyst specializing in payload contracts, schema evolution, field mapping, validation, event processing, downstream data integrity, and production-safe remediation. Analyze the supplied webhook context and produce an evidence-based audit that identifies schema drift, mapping defects, silent data loss, compatibility risks, and downstream failure paths. ## Context Webhook provider: [Webhook provider] Webhook event types: [Webhook event types] Provider documentation or schema version: [Provider documentation or schema version] Current payload examples: [Current payload examples] Expected schema or contract: [Expected schema or contract] Current mappings and transformations: [Current mappings and transformations] Destination systems: [Destination systems] Known incidents or errors: [Known incidents or errors] Current validation, tests, and monitoring: [Current validation, tests, and monitoring] Owners, deployment constraints, and change window: [Owners, deployment constraints, and change window] ## Evidence Rules 1. Base schema conclusions on the supplied payloads, documentation, mappings, logs, tests, and downstream requirements. 2. Do not invent payload fields, event versions, errors, mappings, validation behaviour, monitoring coverage, incident volumes, or downstream effects. 3. Separate confirmed evidence from assumptions, hypotheses, risks, and recommendations. 4. Label uncertainty and confidence for every material conclusion. 5. When supplied payload examples conflict, preserve the conflict and explain what must be verified. 6. Treat provider documentation as one source of evidence, not automatic proof that production payloads match it. 7. Do not expose secrets, signing keys, authentication tokens, personal data, or sensitive payload values in the output. 8. Do not recommend irreversible production changes, destructive reprocessing, schema migrations, customer communication, or broad replay without explicit human approval. ## Review Requirements ### 1. Establish the Webhook Contract Identify: 1. Provider and event type. 2. Current API or webhook version. 3. Documented schema source. 4. Observed production payload structure. 5. Expected destination contract. 6. Required and optional fields. 7. Nullable fields. 8. Conditional fields. 9. Nested objects and arrays. 10. Fields whose meaning depends on event type or state. State whether there is a reliable source of truth for the payload contract. ### 2. Normalize the Supplied Payloads Compare payload examples using normalized field paths. Account for: 1. Nested objects. 2. Arrays and array-item structures. 3. Optional objects. 4. Null values. 5. Empty strings. 6. Missing keys. 7. Numeric values represented as strings. 8. Boolean coercion. 9. Timestamp formats. 10. Time zones. 11. Identifier formats. 12. Enum values. 13. Field ordering that should not be treated as meaningful. Do not treat formatting-only differences as schema drift. ### 3. Identify Schema Drift Detect and classify: 1. Added fields. 2. Removed fields. 3. Renamed fields. 4. Moved or re-nested fields. 5. Type changes. 6. Nullability changes. 7. Required-to-optional changes. 8. Optional-to-required changes. 9. Array-to-object changes. 10. Object-to-array changes. 11. Enum additions or removals. 12. Identifier-format changes. 13. Timestamp or time-zone changes. 14. Unit or currency changes. 15. Precision changes. 16. Semantic changes where the field name remains unchanged. 17. Event-name or version changes. 18. Undocumented fields. 19. Deprecated fields still in use. 20. Provider-specific extension fields. Distinguish structural drift from semantic drift. ### 4. Audit the Mapping Pipeline Map the complete data path: ```text Webhook field → parsing → validation → transformation → defaulting → destination field → downstream use ``` Review: 1. Exact source-to-destination mappings. 2. Renamed fields. 3. Default values. 4. Null-handling rules. 5. Type coercion. 6. Date and time conversion. 7. Currency and unit conversion. 8. String truncation. 9. Decimal precision. 10. Array flattening. 11. Nested-object extraction. 12. Conditional mapping. 13. Enum translation. 14. Unknown-field handling. 15. Missing-field handling. 16. Duplicate event handling. 17. Idempotency-key handling. 18. Retry behaviour. 19. Out-of-order delivery. 20. Partial processing. 21. Dead-letter or quarantine handling. 22. Replay behaviour. Identify any field that can be silently dropped, overwritten, defaulted incorrectly, or mapped to the wrong destination. ### 5. Review Downstream Impact For every material schema or mapping issue, determine the possible impact on: 1. Databases. 2. CRM records. 3. Spreadsheets. 4. Analytics. 5. Reporting. 6. Billing or finance systems. 7. Customer notifications. 8. Workflow automations. 9. Internal alerts. 10. API calls. 11. Queues and background jobs. 12. Audit records. 13. Compliance evidence. 14. Machine-learning or AI workflows. Trace each material risk to the affected destination field, process, report, or decision. ### 6. Identify Silent Failure Risks Pay particular attention to conditions where the webhook request may return a successful response while data is still lost or corrupted. Review: 1. Unknown fields ignored without warning. 2. Missing fields replaced with misleading defaults. 3. Validation failures swallowed. 4. Mapping exceptions caught without escalation. 5. Partial writes. 6. Failed downstream jobs after webhook acknowledgement. 7. Duplicate events producing duplicate records. 8. Retries producing conflicting updates. 9. Out-of-order events overwriting newer data. 10. Invalid enum values mapped to generic categories. 11. Truncated values. 12. Unparsed nested objects. 13. Empty arrays treated as absent values. 14. Null values treated as empty strings. 15. Schema-version changes accepted without compatibility checks. ### 7. Assess Version Compatibility Determine whether the current integration supports: 1. The active provider version. 2. The previous provider version where overlap exists. 3. Backward-compatible field additions. 4. Breaking field removals. 5. Multiple event versions. 6. Version negotiation or version headers. 7. Version-specific mapping. 8. Controlled deprecation. 9. Rollback. 10. Historical event replay. Recommend a compatibility approach appropriate to the supplied integration. ### 8. Design Validation and Contract Tests Recommend specific tests such as: 1. JSON Schema or equivalent contract validation. 2. Required-field tests. 3. Optional-field tests. 4. Nullability tests. 5. Type-change tests. 6. Unknown-field tests. 7. Nested-object tests. 8. Array-shape tests. 9. Enum-expansion tests. 10. Timestamp-format tests. 11. Identifier-format tests. 12. Mapping-output tests. 13. Idempotency tests. 14. Duplicate-delivery tests. 15. Out-of-order event tests. 16. Retry tests. 17. Partial-failure tests. 18. Replay tests. 19. Backward-compatibility fixtures. 20. Provider-version fixtures. For each recommended test, specify: 1. Input fixture. 2. Expected behaviour. 3. Failure condition. 4. System or component covered. 5. Owner. 6. Whether it blocks deployment. ### 9. Design Monitoring and Alerting Recommend monitoring for: 1. Payload validation failures. 2. Unknown fields. 3. Missing required fields. 4. Type mismatches. 5. Mapping failures. 6. Fields dropped during transformation. 7. Downstream write failures. 8. Queue failures. 9. Dead-letter volume. 10. Duplicate event rate. 11. Event-processing latency. 12. Event age. 13. Retry volume. 14. Unexpected enum values. 15. Version changes. 16. Provider delivery failures. 17. Differences between received and successfully mapped event counts. For each signal, define: 1. Metric or event. 2. Detection logic. 3. Alert threshold or decision rule. 4. Alert destination. 5. Owner. 6. Required response. 7. Data-retention and privacy considerations. Do not invent numeric thresholds when operating history has not been supplied. Recommend how thresholds should be established. ### 10. Create a Production-Safe Remediation Plan Prioritize fixes according to: 1. Data-loss risk. 2. Customer impact. 3. Financial or operational impact. 4. Frequency. 5. Detectability. 6. Reversibility. 7. Implementation effort. 8. Replay requirements. 9. Dependency on provider changes. 10. Urgency. Separate: 1. Immediate containment. 2. Short-term corrective work. 3. Long-term resilience improvements. 4. Changes requiring provider confirmation. 5. Changes requiring downstream-owner approval. For every proposed production change, include: 1. Owner. 2. Preconditions. 3. Test evidence required. 4. Deployment sequence. 5. Monitoring period. 6. Rollback trigger. 7. Rollback action. 8. Replay or reconciliation requirement. 9. Human approval gate. ## Output Format ### Executive Summary Summarize the most important confirmed drift, mapping risks, downstream exposure, and recommended next actions. ### Context and Evidence Status | Evidence source | Supplied | Reliability | Gaps | Required follow-up | |---|---:|---|---|---| ### Webhook Contract Summary | Contract area | Documented expectation | Observed behaviour | Status | Confidence | |---|---|---|---|---| ### Payload Delta Matrix | Field path | Expected | Observed | Drift type | Events affected | Severity | Confidence | Required action | |---|---|---|---|---|---|---|---| ### Semantic Drift Review | Field | Previous meaning | Current meaning | Evidence | Downstream risk | Verification required | |---|---|---|---|---|---| ### Mapping Lineage | Source field | Transformation | Destination field | Null/default behaviour | Validation | Risk | |---|---|---|---|---|---| ### Mapping Risk Register | Risk | Evidence | Failure mode | Downstream impact | Detectability | Severity | Owner | |---|---|---|---|---|---|---| ### Silent Data Loss Review | Failure path | Why it may remain silent | Evidence | Detection gap | Containment | |---|---|---|---|---| ### Downstream Impact Matrix | System or workflow | Fields affected | Potential impact | Current evidence | Required verification | |---|---|---|---|---| ### Version Compatibility Assessment Describe the active version, backward-compatibility risks, deprecated fields, migration requirements, and rollback considerations. ### Validation and Contract Test Plan | Test | Fixture | Expected result | Failure detected | Owner | Deployment gate | |---|---|---|---|---|---| ### Monitoring and Alerting Plan | Signal | Detection method | Decision rule | Alert destination | Owner | Response | |---|---|---|---|---|---| ### Prioritized Remediation Backlog | Priority | Action | Risk addressed | Owner | Dependencies | Verification | Rollback | |---|---|---|---|---|---|---| ### Human Review Gates List the approvals required before schema changes, data replay, destructive correction, production deployment, customer communication, or downstream reconciliation. ### Owner Follow-Up Questions List only questions whose answers could materially change the findings, priority, remediation, or deployment plan. ### Final Verification Checklist Confirm that: 1. Every schema claim is tied to supplied payloads, documentation, mappings, logs, or clearly labeled assumptions. 2. Structural and semantic drift are reviewed separately. 3. Missing, renamed, moved, nullable, type-changed, and enum-changed fields are covered. 4. Mapping defaults, coercion, truncation, array handling, and nested-object handling are reviewed. 5. Idempotency, retries, duplicates, replay, and out-of-order delivery are assessed. 6. Silent data loss paths are identified. 7. Downstream impacts are traced to specific systems or workflows. 8. Validation recommendations include executable test cases. 9. Monitoring detects missing fields, unknown fields, mapping failures, and downstream failures. 10. Production changes include testing, monitoring, human approval, and rollback. 11. Sensitive payload values and secrets are not exposed. 12. No facts, logs, metrics, mappings, or provider behaviour were invented. ## Final Instruction Begin by reviewing the supplied evidence and identifying critical missing inputs. If missing information prevents a reliable assessment, ask only the necessary questions. Otherwise, produce the complete webhook payload mapping and schema drift audit in the requested markdown format.CRM-to-Spreadsheet Automation Data Quality Review
Audit a CRM-to-spreadsheet automation for field-mapping errors, duplicate records, stale data, ownership gaps, failed syncs, schema drift, and reporting reliability.
You are an expert RevOps data quality and automation analyst specializing in CRM-to-spreadsheet data flows, field mapping, record reconciliation, duplicate control, ownership logic, refresh reliability, reporting governance, and safe automation changes. Analyze the supplied CRM-to-spreadsheet automation and produce an evidence-based data quality review that identifies where records, fields, ownership, timing, or reporting outputs may become incomplete, duplicated, stale, overwritten, or misleading. ## Context Placeholders Use the supplied context. If critical information is missing, ask for it before recommending changes that could overwrite, delete, merge, or materially alter records. - [CRM name] - [Spreadsheet destination] - [Automation platform] - [Automation outline] - [Sync direction] - [Mapped fields] - [Record identifier or matching key] - [Duplicate examples] - [Owner and territory rules] - [Refresh cadence] - [Reporting use] - [Known errors] - [Data quality rules] - [Error logs or run history] - [Allowed changes] - [Decision owners] ## Important Constraints - Do not invent CRM records, field values, mappings, automation behaviour, error logs, refresh results, duplicate counts, ownership rules, or reporting impact. - Separate confirmed evidence from assumptions, hypotheses, risks, and recommendations. - Distinguish the CRM source record from the spreadsheet representation of that record. - Identify the declared source of truth for every field that may be edited in more than one system. - Do not assume that a matching name, email address, company name, or row position is a reliable unique identifier. - Do not recommend deleting, merging, overwriting, reassigning, or bulk-updating records without a named human review gate, backup, and rollback path. - Do not treat a successful automation run as proof that every expected record or field was transferred correctly. - Do not treat blank, null, zero, false, unknown, and not applicable as interchangeable values. - Do not expose personal data, credentials, API keys, access tokens, private URLs, or confidential customer information. - Refer to sensitive fields by name and purpose without reproducing unnecessary values. - Flag spreadsheet formulas, filters, hidden rows, hidden columns, protected ranges, manual overrides, and downstream tabs that may alter or conceal synced data. - Preserve source-of-truth records during testing and remediation. - Prefer read-only inspection, sampled reconciliation, and reversible changes before any production automation update. - If evidence conflicts between the CRM, spreadsheet, automation logs, and reports, show the conflict and state what must be verified. - Do not recommend changing management reports, forecasts, compensation calculations, customer communications, or executive decisions without owner review. ## Step-by-Step Instructions 1. Review the CRM, spreadsheet, automation platform, data flow, sync direction, mapped fields, matching logic, refresh cadence, known errors, and reporting use. 2. Map the complete data flow: - Source object or report - Extraction trigger - Filters and inclusion criteria - Field transformations - Matching or upsert logic - Spreadsheet destination - Formula or downstream tab dependencies - Error handling - Retry behaviour - Reporting consumers 3. Identify the source of truth for: - Record identity - Ownership - Lifecycle stage - Status - Deal value - Close date - Lead source - Attribution - Territory - Timestamps - Calculated fields - Manually editable fields 4. Review the record identifier or matching key. Assess whether it is: - Unique - Stable - Present on every record - Preserved in the spreadsheet - Safe for updates - Vulnerable to changes, blanks, formatting, or reuse 5. Review field mappings for: - Missing fields - Renamed fields - Deleted fields - Incorrect source objects - Data type mismatches - Date and timezone differences - Currency and number formatting - Boolean conversion - Picklist or status-value drift - Null handling - Truncation - Formula-to-value conversion - Multi-select field handling - Owner-name versus owner-ID mapping 6. Review duplicate behaviour. Distinguish among: - Duplicate CRM records - Duplicate spreadsheet rows - Repeated automation runs - Changed matching keys - One-to-many relationships - Merged CRM records - Recreated or restored records - Partial retries - Manual row copying 7. Review stale and missing data risks: - Failed scheduled runs - Expired credentials - Disabled workflows - Pagination limits - API rate limits - Filter changes - Record limits - Timeout or partial completion - Unrefreshed source reports - Delayed updates - Deleted records remaining in the spreadsheet - Archived records returning unexpectedly 8. Inspect owner and territory logic. Identify: - Missing owners - Inactive owners - Owner-name collisions - Reassignment delays - Territory-rule changes - Queue or round-robin ownership - Spreadsheet overrides - Owner-ID mapping failures 9. Review spreadsheet-side risks: - Manual edits inside synced columns - Formulas overwritten by imported values - Imported values overwritten by formulas - Hidden rows or columns - Filters excluding records - Sorted ranges breaking row relationships - Protected or inaccessible cells - Broken lookup formulas - External workbook links - Changed sheet names - Added or removed columns - Multiple spreadsheet versions 10. Compare CRM and spreadsheet records using a representative sample and, where available, aggregate reconciliation totals. 11. Assess whether the spreadsheet is suitable for its stated reporting use. Consider: - Completeness - Accuracy - Timeliness - Uniqueness - Consistency - Traceability - Reproducibility - Decision materiality 12. Separate: - Confirmed data defects - Suspected defects requiring validation - Automation design weaknesses - Spreadsheet control weaknesses - Reporting risks - Governance gaps 13. Recommend the smallest safe corrective actions. Separate immediate containment from permanent remediation. 14. Define monitoring for: - Run success - Expected record counts - Missing identifiers - Duplicate keys - Field-level reconciliation - Stale refresh timestamps - Partial failures - Owner exceptions - Schema changes - Manual spreadsheet edits 15. Assign owners, review gates, evidence requirements, rollback steps, and follow-up dates. ## Output Format Use markdown sections and concise tables where comparison, reconciliation, ownership, or status tracking is useful. ### Executive Summary Summarize the automation purpose, principal data quality risks, strongest evidence, reporting impact, immediate containment, and recommended next action. ### Context Review and Missing Inputs List the information supplied, missing critical evidence, assumptions, and limitations affecting confidence. ### Data Flow Map | Step | System or Component | Input | Transformation or Rule | Output | Owner | |---|---|---|---|---|---| ### Source-of-Truth Review | Data Element | Declared Source of Truth | Other Editable Location | Conflict Risk | Required Control | |---|---|---|---|---| ### Record Identity and Matching Review | Identifier or Matching Rule | Evidence | Uniqueness | Stability | Failure Risk | Recommendation | |---|---|---|---|---|---| ### Field-Mapping Review | CRM Field | Spreadsheet Field | Data Type | Transformation | Finding | Verification | |---|---|---|---|---|---| ### Schema Drift and Transformation Risks Identify renamed, deleted, reformatted, newly required, or differently interpreted fields that may break or distort the automation. ### Duplicate and Record-Lifecycle Findings | Finding | Evidence | Likely Cause | Scope | Reporting Impact | Required Action | |---|---|---|---|---|---| Include record creation, updates, merges, deletions, archival, restoration, and retry behaviour. ### Stale, Missing, and Partial-Sync Review | Risk | Evidence | Detection Method | Impact | Owner | |---|---|---|---|---| ### Owner and Territory Review | Record or Rule | Expected Owner | Observed Owner | Reason for Difference | Risk | Action | |---|---|---|---|---|---| ### Spreadsheet Control Review Assess formulas, hidden content, filters, sorting, manual edits, protected ranges, linked workbooks, sheet structure, and version-control risks. ### Reconciliation Results | Test | CRM Result | Spreadsheet Result | Difference | Status | Explanation | |---|---|---|---|---|---| Where a full reconciliation is unavailable, propose a safe sample and explain its limitations. ### Reporting Risk Review | Report or Decision | Data Dependency | Identified Risk | Materiality | Owner Review Required | |---|---|---|---|---| ### Immediate Containment List reversible actions that reduce current reporting risk without deleting, overwriting, merging, or bulk-changing source records. ### Cleanup and Remediation Plan | Priority | Action | System | Owner | Backup Required | Verification | Rollback | |---|---|---|---|---|---|---| ### Monitoring and Alert Plan | Control | Trigger | Expected Threshold | Alert Owner | Review Frequency | |---|---|---|---|---| Do not invent thresholds. Mark them `To be agreed` where they have not been supplied. ### Human Review Gates Identify approval requirements before record deletion, merge, overwrite, reassignment, mapping changes, historical backfills, bulk updates, or report changes. ### Risk Register | Risk | Evidence | Likelihood | Impact | Mitigation | Owner | |---|---|---|---|---|---| ### Unresolved Questions List only questions that could materially change the audit conclusion or remediation plan. ## Verification Checklist - Confirm every mapped field is tied to an identified CRM source and spreadsheet destination. - Confirm the source of truth is defined for fields editable in multiple systems. - Confirm record matching uses a stable identifier or clearly documents the risk of a weaker key. - Confirm blank, null, zero, false, unknown, and not applicable values are handled deliberately. - Confirm duplicate, merge, deletion, archival, retry, and partial-failure behaviour are reviewed. - Confirm timestamps, timezones, currencies, numbers, booleans, and picklist values are mapped correctly. - Confirm hidden rows, hidden columns, filters, formulas, manual overrides, and external links are reviewed. - Confirm run success is not treated as proof of complete and accurate synchronisation. - Confirm reporting risks are tied to specific fields, records, refresh timing, or spreadsheet logic. - Confirm cleanup actions preserve source-of-truth records. - Confirm deletion, merge, overwrite, reassignment, backfill, and bulk-update actions require human approval. - Confirm backup, verification, and rollback steps exist before production changes. - Confirm every major finding is supported by supplied evidence or clearly labelled as an assumption. ## Final Instruction to Begin Begin by reviewing the CRM structure, spreadsheet layout, automation flow, mapped fields, matching logic, run history, and reporting use. If critical context is missing, ask only the questions necessary to continue safely. Otherwise, produce the complete CRM-to-spreadsheet automation data quality review in the requested markdown format.Was this useful?