Plan the deliverable before the data work begins.

1. Begin with the business outcome

The first question is not “How much data can be collected?” It is “What decision, workflow, system, or deliverable must this project support?” A clear outcome prevents the scope from expanding into unrelated records and helps determine which information is actually necessary.

Describe what will happen after delivery. You might need a company list for market analysis, structured product records for catalog work, verified contact fields for an approved business process, normalized files for a system import, or a documented research report for internal planning. The intended use affects the required sources, freshness, completeness, output format, and quality controls.

A useful outcome statement identifies:

• the decision or downstream process the deliverable supports;
• the people or system that will use it;
• the minimum information required for that use;
• the date or operational deadline that matters; and
• the condition that would make the finished work useful rather than merely interesting.

2. Choose the kind of data work

Many projects combine several activities, but identifying the primary work makes the scope easier to understand. Morrow Creek separates research, collection, and quality work so the source and acceptance rules can match the actual need.

A combined project might research a target population, collect approved fields, and then validate the completed dataset. That is acceptable when each stage has a defined input, output, and rule set. It should not be treated as one vague instruction to “find everything.”

3. Define what one record represents

Every structured dataset needs a stable record definition. One row might represent a company, location, product, person, document, event, property, transaction, or another entity. If one row sometimes represents a company and sometimes a branch location, totals and duplicate checks can become unreliable.

State the target entity and the rule for distinguishing one record from another. For company research, decide whether subsidiaries, brands, parent organizations, and locations are separate records. For product collection, decide how size, color, package quantity, regional listing, and seller variation affect uniqueness. For cleaning, identify the key or combination of fields used to recognize repeated records.

Useful identity rules include:

• the primary name or identifier for the entity;
• the fields that distinguish legitimate variations;
• how parent-child or relationship records should be represented;
• which duplicates should be consolidated and which should remain separate; and
• how records with uncertain identity should be flagged rather than silently merged.

For focused list-building work, review the separate company list research service. For catalog-oriented records, review product data collection.

4. Specify every required field

A field list is the working contract for a structured data project. Separate required fields from optional fields and explain what each field means. “Contact information” is less precise than naming organization name, public business email, public telephone number, city, state, website, source URL, and observation date.

For each field, define the expected type and format. Dates may require an ISO date, a full timestamp, or a source-preserved value. Prices may require currency and unit context. Categories may need an approved list. Names and addresses may need standard capitalization or component fields. Missing information may be blank, marked with a controlled status, or excluded according to the confirmed rule.

Field-level scope should answer:

• Is the field required for every accepted record?
• What source or evidence can support it?
• What format, unit, vocabulary, or pattern is valid?
• Can the value contain more than one item?
• How should an unavailable, ambiguous, conflicting, or outdated value be represented?
• Does the field contain customer-provided, public, derived, or calculated information?

5. Set source and access boundaries

The scope should name permitted source types and any prohibited sources. Public websites, public documents, customer-provided files, and authorized interfaces can have different access, usage, freshness, and provenance requirements. A technically reachable page is not automatically an approved source.

Morrow Creek reviews requests for lawful use, source restrictions, access controls, and compatibility with applicable terms before production. Work does not include bypassing authentication, defeating technical controls, misrepresenting identity, or accessing systems without authorization.

If a project depends on named sources, identify the domains, documents, files, or interfaces and state whether alternatives are acceptable. If provenance matters, request source URLs, document names, page references, observation dates, or other agreed evidence fields as part of the deliverable.

6. Define volume, coverage, and freshness

“As many as possible” is difficult to price and impossible to test without a stopping rule. A stronger scope states a target record count, a defined universe, a geographic boundary, a date range, a list of target sources, or another measurable coverage standard.

Coverage can be defined by:

• a fixed number of accepted records;
• all qualifying entries found within named permitted sources;
• a complete customer-provided list with specified fields enriched or checked;
• a geographic, product, industry, or category boundary;
• a date or reporting period; or
• a time-boxed research effort with an agreed output and limitation statement.

Freshness also needs a rule. A value observed during production is different from a value required to be published within the last 30 days, valid on a particular date, or verified against a second source. State the requirement that matches the intended use.

7. Turn quality into acceptance rules

“Accurate” is a goal; an acceptance rule explains how quality will be checked. Before production begins, define the tests that determine whether the finished deliverable is ready for release.

Common controls include required-field completeness, valid data types, allowed values, date consistency, duplicate detection, identifier uniqueness, source presence, record-count reconciliation, format checks, and verification of selected fields. Some projects also need exception files or status fields identifying records that could not be resolved under the agreed evidence rules.

An acceptance rule should distinguish a true defect from a limitation of the permitted sources. If a required public value does not exist, the correct result may be an explicit unavailable status rather than an invented answer. Ambiguous records can be flagged for customer review when the confirmed scope does not provide enough evidence to resolve them safely.

8. Choose the delivery format and structure

The output should fit the system or workflow that will use it. Common formats include CSV, Excel, JSON, cleaned source files, validation summaries, and written reports. More than one format is appropriate only when each version has a defined purpose.

Specify column order, worksheet names, JSON structure, encoding, delimiters, date format, decimal handling, file naming, and any required summary fields. For spreadsheet-focused cleanup, see Excel and CSV data cleaning. A clear output specification reduces last-minute conversion work and prevents multiple files from being delivered without an understood customer purpose.

9. Confirm scope before production

After the request is reviewed, the confirmed job should state the deliverable, sources, fields, coverage, exclusions, quality checks, output format, price, and acceptance conditions. Material assumptions belong in that written scope, not in an undocumented conversation.

If a source changes, a required field proves unavailable, or the requested population differs from what was described, the issue should be resolved through a scope clarification rather than hidden inside the finished files. That protects both the customer and the production process.

10. What happens after submission

1. Request: Start a private job and describe the outcome using the checklist above.
2. Review: Morrow Creek checks feasibility, lawful use, source boundaries, missing decisions, and measurable acceptance criteria.
3. Scope: The private job receives the written deliverable definition and exact price before commitment.
4. Production: Approved work proceeds against the confirmed fields, sources, rules, and formats.
5. Quality control: Completed files are tested against the acceptance requirements before release.
6. Payment and delivery: When the finished files are ready, the customer pays through the private workspace and downloads the approved customer deliverables.

The project workspace keeps the request, scope, status, payment, and customer files together. Internal production evidence and operational artifacts are not added to the customer package unless the confirmed deliverable specifically requires an appropriate customer-facing item.