# Inquiry-to-owner infrastructure: project brief

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

All organizations, domains, records and IDs in this pack are fictional. The acceptance fixtures specify expected behavior. They have not been executed against a live CRM, form provider or connector. The pack is a design reference, not deployable configuration or measured client work.

## 1. Purpose and useful terminal state

A founder-led B2B SaaS team needs demo requests to reach an accountable next step. Define the path from a persisted submission to a checked CRM account, contact association, owner and follow-up task.

The agreed complete state requires:

- A single accepted source event, identified by source_event_id.
- A resolved CRM account and contact.
- A confirmed account-contact relationship.
- An active owner selected by the approved precedence rule.
- One follow-up task for this capture.
- A saved receipt containing the verified destination IDs and completed status.

Accepting a form submission means that its capture record was persisted. It does not mean that CRM delivery, qualification, email delivery or revenue occurred.

## 2. Operating model and scope

Operating model: founder-led inbound inquiries.

Input: one versioned demo request from an approved form source. The capture service assigns capture_id once, persists it, and maps the source's stable submission ID to source_event_id. A repeat delivery uses the original capture record.

In scope:

- Required-field and type validation.
- Source-event replay suppression.
- Account and contact identity resolution.
- Existing customer and owner precedence.
- Approved CRM record and task actions.
- Destination readback and receipt storage.
- Review queues, uncertain-write reconciliation and controlled replay.

Outside this reference:

- Lead sourcing, enrichment and outreach generation.
- Marketing enrollment or inference of marketing permission.
- AI-generated qualification or ownership decisions.
- Campaign execution, lead-volume predictions or revenue claims.
- A specific vendor's credentials, subscription entitlement or API property mapping.

## 3. Contract

The dictionary defines application fields. Map them to the actual provider and CRM schema during implementation. Illustrative IDs such as ACC-201, CON-301 and OWN-02 are not valid vendor IDs.

An accepted payload includes project_id, payload_version, source_event_id, source_channel, submitted_at, work_email, company_domain, inquiry_type and consent_state. The collector adds capture_id after persisting the submission.

The reference fixes project_id to REF-CAPTURE-001, payload_version to 1, source_channel to website_demo_form, and inquiry_type to demo_requested. Dates use an explicit UTC timezone. Email syntax validation does not establish deliverability or permission. Domain normalization is a candidate lookup rule, not proof of legal entity identity.

Only approved inquiry metadata can update an existing contact. Preserve its current customer status, account association and active account owner. This example does not authorize a lifecycle-stage change.

## 4. Decision sequence

1. Capture: persist the source event and reject unsupported payload versions. Claim the source_event_id through an atomic uniqueness check so concurrent deliveries cannot both start side effects.
2. Validate: check required values, types and approved source. Invalid submissions receive VALIDATION_REVIEW without CRM writes.
3. Resolve identity: confirm account and contact using the agreed identifiers and relationship evidence. Multiple plausible account matches receive IDENTITY_REVIEW. A failed lookup is not an empty result.
4. Assign: preserve an active existing account owner. For an approved net-new account, use the active owner OWN-02 from the reference assignment table. Missing or conflicting owners receive OWNER_REVIEW before CRM changes.
5. Write: apply the approved create/update plan in checkpoints. Persist an operation_key before each external side effect. Resume from verified checkpoints rather than restarting completed operations.
6. Verify: read back record IDs, association, owner and task. Set COMPLETE only when those checks succeed and the receipt is saved.

An operation key is a control that must be implemented and tested. It does not assume that an arbitrary CRM create endpoint is repeat-safe. A timeout after a write creates PENDING_RECONCILIATION because the request might have committed.

## 5. Responsibilities and dependencies

Client business owner:

- Approves capture purpose, required fields, customer handling, owner precedence and the follow-up task.
- Provides authorized access, representative records, processing permissions and a release approver.
- Names the operator for review items and ongoing changes.

Implementation team:

- Maps the contract to the actual source, CRM and automation interfaces.
- Implements persistence, validation, matching, permitted writes and exception handling.
- Runs the fixture suite in an authorized test environment and retains destination evidence.
- Documents configuration, limitations, access ownership and recovery.

Ongoing operator:

- Reviews invalid identities, missing owners and failed destination checks.
- Reconciles uncertain writes before approving a replay.
- Maintains the assignment table and approved field policy.

Dependencies include stable source submission IDs, authorized lookup/write access, a persistence store with an atomic unique source-event constraint, an active approved owner, readable destination state and an agreed review queue. If a provider cannot support these controls, revise the design or record the limitation before release.

## 6. Acceptance fixtures

- A01: a new valid inquiry reaches COMPLETE with account ACC-201, contact CON-301, owner OWN-02, task TSK-401 and receipt RCP-1001.
- A02: a repeated delivery of SRC-1001 returns SUPPRESSED_REPEAT, references RCP-1001 and creates no additional record or task. The original capture's COMPLETE status stays unchanged.
- A03: an existing customer account preserves ACC-203, CON-303, OWN-01 and customer status; its new inquiry creates task TSK-403.
- A04: an invalid email receives VALIDATION_REVIEW and no CRM writes.
- A05: two plausible account matches receive IDENTITY_REVIEW and no CRM writes.
- A06: an account-create request that times out receives PENDING_RECONCILIATION. The account outcome remains unknown; contact, association and task creation stop until destination reconciliation.

The CSV records the full input and expected checks. It is not a test execution log.

## 7. Release gates

Before production, map every field and external operation to the chosen tools, confirm access and permissions, approve the owner table, and execute the six fixtures. Include a concurrent repeat-delivery test and a missing-owner test for the final environment. Capture actual destination evidence and record unresolved cases.

Verify the form success message distinguishes accepted capture from completed delivery. Verify the operator can find each review item and reconcile an uncertain write. Confirm a safe pause procedure and backup before changing an existing configuration.

## 8. Handover

Deliver the final brief, architecture, actual field mapping, approved assignment rules, configuration version, executed test log, destination evidence, issue register and runbook. The synthetic pack demonstrates their format; it does not establish that the release gates have passed.

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