# Inquiry-to-owner infrastructure: handover runbook

Project: REF-CAPTURE-001  
Version: 1.0  
Evidence: synthetic operating design  
Reviewed: 2026-09-28

This runbook describes expected controls for a fictional reference system. The fixtures have not been executed against a live CRM or connector. Replace illustrative field mappings, record IDs, assignment tables and operational settings with reviewed implementation values before use.

## 1. Locate a submission

Search the processing ledger by source_event_id or capture_id. Use an approved operator interface rather than exporting full form contents to analytics or general logs. The visible receipt should contain the current processing status, operation checkpoints, destination IDs and review reason.

Keep work_email and other inquiry data within authorized processing stores. Analytics events can report page and fixed resource IDs without form contents, email addresses or user-entered assumptions.

## 2. Interpret the states

| State or delivery outcome | Meaning | Operator action |
| --- | --- | --- |
| CAPTURED | Submission persisted; destination work is unfinished | Check its processing checkpoint and any outstanding operation |
| COMPLETE | Required destination records, association, owner and task were read back; receipt saved | No replay required |
| SUPPRESSED_REPEAT | This delivery repeats a source event already accepted | Return the original capture/receipt; preserve its existing processing status |
| VALIDATION_REVIEW | A required input, source or payload version failed validation | Correct through the approved workflow; retain original input and reason |
| IDENTITY_REVIEW | Matching was ambiguous, conflicted or could not be confirmed | Resolve the identity; approve the target before replay |
| OWNER_REVIEW | No active approved owner, or precedence could not be resolved | Correct the owner table or relationship; approve the route before writes |
| WRITE_REVIEW | A write was confirmed rejected, or destination verification failed | Inspect the rejected operation and destination state; revise its permitted plan |
| PENDING_RECONCILIATION | A request was sent but its write outcome is unknown | Determine whether the operation committed before any repeat write |

SUPPRESSED_REPEAT is a delivery outcome, not a replacement for the original capture's COMPLETE or review status. A06 is an intermediate recovery state, not a successful terminal state.

## 3. Review a held capture

1. Confirm the source event, project and payload version.
2. Read the exact failed rule and current destination lookup evidence.
3. Obtain the relevant business or data owner's approval for the correction.
4. Retain the original input and append the approved correction and rule version.
5. Check operation checkpoints for previous side effects.
6. Replay only the eligible unfinished operation, then verify the required destination state.

Do not choose the first plausible account, promote customer lifecycle status or substitute an unapproved owner to clear a queue.

## 4. Reconcile an uncertain write

A timeout does not show whether a create or update committed. Preserve the original attempt and operation_key. In A06, the uncertain operation is create_account; do not create the contact, association or task yet.

Check the provider's operation result or supported request identifier if available. Otherwise, use the mapped capture/operation reference, destination identifiers and approved identity checks. A vendor-neutral operation key does not automatically make a provider's create endpoint repeat-safe.

Choose one documented recovery:

- Confirmed committed: save the destination ID and checkpoint, then resume the next unfinished operation.
- Confirmed not applied: approve a retry using the same intended operation key and the supported retry method.
- Still unknown or multiple plausible matches: retain PENDING_RECONCILIATION or move to a named review case. Do not retry blindly.

After recovery, read back the association, owner and task before setting COMPLETE. This design does not promise distributed exactly-once delivery.

## 5. Monitor the operating path

Track accepted captures, completed captures, counts by review state, pending reconciliation, repeat deliveries and capture-to-completion elapsed time. Set review intervals and escalation thresholds with the client operator before release; this reference does not prescribe a response-time promise.

Distinguish:

- Persisted submission from completed CRM delivery.
- Completed delivery from a qualified sales opportunity.
- A follow-up task from completed follow-up or an email receipt.
- A page/resource interaction from an inquiry or sale.

Keep reconciliation cases visible until their destination outcome is confirmed. Retain data only under the approved retention and access policy.

## 6. Pause, restore and replay

Pause new processing when matching rules, owner precedence or writes are producing unsafe destination changes. Continue capture only if the approved store can persist submissions safely and the form success wording remains accurate.

Record the last approved configuration version and capture checkpoint before a change. Restore the reviewed configuration if needed. Configuration restoration does not undo CRM side effects: inspect changed records and use a separately approved data correction plan.

After restoring, reconcile in-flight operations and replay eligible unfinished work. Preserve completed receipts and source-event uniqueness so existing tasks are not created again.

## 7. Change control

A source, field, lifecycle, matching, assignment or permission change receives a version and named approval. Update the dictionary and tests together. Test affected cases, including repeats and existing customers, before production activation.

Keep credentials and personal information outside the public reference files and test evidence. Assign account ownership to the client and document the access required to operate the system.

## 8. Handover checklist

- Current build brief and static architecture.
- Actual provider field mapping and data ownership.
- Approved owner precedence and active-owner table.
- Processing ledger, review destinations and operator access.
- External-operation and timeout/reconciliation rules.
- Executed fixture log with destination readback evidence.
- Concurrent replay and missing-owner checks in the target environment.
- Known issues and provider limitations.
- Backup, pause and restoration notes.
- Named release approver and ongoing operator.

Fixture status in this pack: EXPECTED_ONLY_NOT_EXECUTED. No production readiness or delivery outcome is established by these documents.

Technical references:

- IETF HTTP semantics, retry distinction: https://www.rfc-editor.org/rfc/rfc9110.html#section-9.2.2
- IANA reserved domains: https://www.iana.org/domains/reserved