Identity and location
Well, API, permit, lease, field, operator, jurisdiction, legal location and coordinates.
Paper and Scanned Tickets to Structured Well Data
Convert Historical Scout Tickets into Searchable Well Records
GAEA converts typed, handwritten and scanned scout tickets into source-linked well, completion, formation, casing, test and production records using an agreed data schema and documented QA/QC.
Configurable well-data schema Source-linked transcription Documented QA/QC workflow
Record scope
Define What “Scout Ticket” Means for the Archive
Terminology and content vary by jurisdiction, operator and period. Source review identifies the document classes and the fields that can be captured reliably.
Dates and depths
Permit, spud, drilling, total depth, completion, abandonment and plugging information.
Well construction
Casing, tubing, cement, perforations, open-hole intervals, status and producing completion.
Geology and results
Formation or log tops, tests, shows, initial production, production or injection summaries and remarks.
Scope rule: a value is captured only when it is present, within the agreed field list and sufficiently legible. Supporting permits, driller’s logs, completion reports and production summaries are classified separately when included.
Accepted inputs
Preserve the Complete Record and Its Context
Representative files are reviewed before pricing so handwriting, forms, revisions, repeating sections and source quality are reflected in the scope.
Source documents
- Paper scout tickets
- PDF, TIFF, JPEG and PNG
- Microfilm or microfiche scans
- Multi-page well files
Record conditions
- Typed or handwritten entries
- Annotations and revisions
- Historical abbreviations and units
- Damaged, faded or partial records
Reference information
- Existing ticket or well indexes
- Regulatory identifier lists
- Client data dictionary
- Target database or import schema
Scan guidance: retain all margins, page identifiers, reverse-side information, stamps and annotations; scan flat and square at a resolution that keeps small typed and handwritten values legible.
Structured data model
Keep the Wellbore Separate from Repeating Well Records
A relational delivery prevents multiple completions, tops, casing strings or test records from being compressed into one ambiguous spreadsheet row.
| Table | Purpose | Relationship |
|---|---|---|
| Wellbore Parent | Stable well identity, operator, lease, field, location, dates, total depth, type and status. | One record per agreed wellbore identity. |
| Identifiers | API, permit, regulator, operator and legacy identifiers with identifier type and source. | Many identifiers can reference one wellbore. |
| Completions | Completion number, status, formation, intervals, dates and completion-specific identifiers. | One wellbore can contain multiple completions. |
| Formation tops | Formation name, depth, source text, unit and certainty. | Multiple tops can reference one wellbore. |
| Casing and tubing | String type, diameter, setting depth, interval, cement and source text. | Multiple strings can reference one wellbore. |
| Tests | Test type, date, interval, oil, gas, water, pressure and recovery values when present. | Tests reference the wellbore or a specific completion. |
| Production / injection | Period, product or fluid, volume, rate, unit, source and record status. | Repeating observations reference a completion, well, lease or field as scoped. |
| Source documents | Document name, type, date, page count, page reference and archive location. | Every structured record can remain linked to source evidence. |
| Exceptions | Illegible, ambiguous, conflicting or unresolved fields and their review status. | Exceptions reference the affected table, field, source and page. |
Deliverables
Choose the Data and Documentation Required for Handoff
The quotation defines the included formats, tables, field mapping, normalization rules and import test.
| Deliverable | Typical use | Scope decisions |
|---|---|---|
| CSV / Microsoft Excel | Review, exchange and loading into common databases. | Table separation, delimiters, sheet names, identifiers and null handling. |
| JSON / XML | Structured application exchange and integration. | Schema, hierarchy, repeating records, units and validation rules. |
| SQL or import tables | Loading into a defined relational database. | Database platform, keys, types, constraints and staging process. |
| Client-defined import | Direct loading into an agreed application or EDI workflow. | Exact target version, mapping specification and test dataset. |
| Source index | Links wells and structured records to PDF, TIFF or image evidence. | File naming, archive path, pages, revisions and document types. |
| Data dictionary | Defines fields, types, units, controlled values and relationships. | Client terminology and normalization conventions. |
| Exception register | Preserves illegible, missing, conflicting and unresolved items. | Review responsibility, status values and resolution process. |
| QA/QC summary | Documents coverage, checks, assumptions and delivery verification. | Sampling, acceptance thresholds and import reconciliation. |
Source and structured output
Review Source Traceability and Relational Delivery
The example shows how one source ticket can populate linked well, completion, top, casing and test records while an uncertain value remains visible for review.
Downloadable synthetic exampleSource-Linked Well Data Package
The package includes a synthetic source ticket plus linked tables and one intentionally unresolved water-rate value.
Well and completionFormation topsCasing stringsInitial testsProduction recordsSource-document indexData dictionaryException register
All values are synthetic and must not be used for regulatory, engineering, drilling, production or interpretation purposes.
Download synthetic packageTranscription policy
Do Not Turn Uncertainty into False Precision
Source traceability and explicit exceptions are more valuable than a database filled with unsupported assumptions.
Core transcription rules
- Capture only fields included in the approved schema.
- Preserve original source text where normalization changes representation.
- Leave absent values blank rather than applying a default.
- Flag illegible or ambiguous values instead of guessing.
- Record units and conversion rules explicitly.
- Link records to source document and page.
- Keep transcription QA separate from technical acceptance.
Example exception
The synthetic ticket displays the water rate as ?7 m3/d. The first digit cannot be supported by the source.
Structured result
water_rate_m3_d = blankresolution_status = Unresolvedsource_text = ?7 m3/dThe exception register retains the table, field, document, page, issue type and resolution note so a reviewer can resolve the value without losing provenance.
Quality assurance
A Defined Twelve-Stage Transcription QA/QC Workflow
Checks cover document inventory, field mapping, source comparison, relational consistency and import readiness.
- Source inventoryCount, identify and reconcile supplied records and pages.
- Image preparationRotate, crop and improve readability without altering evidence.
- Document classificationSeparate scout tickets, permits, logs, tests and other forms.
- Schema mappingMap source labels to approved fields, types and tables.
- Initial transcriptionEnter values using the agreed manual or assisted workflow.
- Identifier verificationRecheck API, permit, lease, well and completion identifiers.
- Date and unit reviewValidate formats and document every normalization.
- Range checksIdentify invalid dates, depths, intervals, rates and codes.
- Cross-field checksReview relationships among wells, completions and repeated data.
- Source comparisonCompare structured values with the original page evidence.
- Exception reviewRecord and route illegible, conflicting or unresolved fields.
- Import verificationTest schema, keys, counts, formats and delivery completeness.
Pricing and schedule
Scope the Project from Representative Records
No single per-ticket price is meaningful until record condition, field coverage, repeating data, normalization and delivery requirements are understood.
Recommended Pricing Basis
Review a representative sample, define a standard record and exception class, then quote the expected document volume and verification level.
- Standard typed ticket
- Handwritten or annotated ticket
- Multi-page or mixed document packet
- Repeating completion, test or production tables
- Exception requiring client review
A pilot batch is advisable for mixed historical archives because the sample establishes actual field coverage, readability, throughput and exception frequency.
Factors Affecting Cost and Timing
Ticket and page count
Fields per document
Typed versus handwritten
Image quality and damage
Form and jurisdiction variation
Repeating data tables
Unit and date normalization
Database field mapping
Verification level
Import testing and schedule
Project process
Three Steps from Historical Tickets to Verified Data
1
Review and Define
Classify representative records and confirm tables, fields, units, normalization, exceptions, outputs and acceptance requirements.
2
Transcribe and Verify
Capture approved fields, preserve source linkage, perform identifier, format, range and source-comparison checks, and register uncertainty.
3
Test and Deliver
Reconcile counts, test the agreed import, provide the structured data, dictionary, source index, exceptions and QA/QC summary.
Include with the quotation request:
- Ticket and page count
- Representative sources
- Jurisdictions and date range
- Required fields and tables
- Target database or software
- Output formats
- Unit conventions
- Illegible-value policy
- Verification level
- Required completion date
- Confidentiality requirements
Applications and handling
Make Historical Well Records Searchable Without Losing Their Evidence
Archive modernization
Inventory and structure aging paper, microfilm and scanned collections.
Well search
Find records by well, identifier, operator, field, location, formation or status.
Database migration
Load defined well tables into a supported project or enterprise schema.
Regional correlation
Use qualified formation, depth and completion information as interpretation inputs.
Record reconciliation
Compare historical identifiers and information across available sources.
Controlled handoff
Provide documented tables, source links and exceptions to project teams.
Confidentiality, Retention and Responsible Use
Historical well records may contain proprietary, confidential or restricted information. Transfer, access, retention and deletion requirements can be agreed before production.
Structured data should retain its source, revision, transcription status and unresolved exceptions. It should not be represented as independently verified regulatory truth or used beyond the authority and accuracy of the source record.
- Preserve document and page provenance
- Separate transcription from technical approval
- Restrict access as required
- Document final retention or deletion
Reference material
Understand Historical Well Records and Their Data
Geoscience Data Digitization
Review broader practices for converting legacy subsurface records.
Read the digitization guideScout Tickets: Origin and Use
Explore the history and role of scout tickets in well-data archives.
Read the scout-ticket guideNorth Dakota Scout Ticket Data
See an official example of the well, completion, test and production information associated with scout records.
Review the government resourceTexas Oil and Gas Well Records
Review official well-record identifiers, document types and search fields.
Review the government resourceFrequently asked questions
Before You Submit a Scout-Ticket Archive
What is considered a scout ticket?
Scout ticket is a broad historical term. Depending on jurisdiction, operator and period, it can refer to a well summary, completion card, drilling summary or another concise record of well identity, location, drilling, geological, completion, test or production information.
Which fields can be digitized?
Fields can include well and regulatory identifiers, operator, lease, field, location, dates, status, total depth, formation tops, casing, perforations, completion intervals, tests, production or injection values, log availability and remarks when those values are present and legible.
How are multiple completions or repeated records handled?
The delivery can use related tables so one wellbore can link to multiple completions, formation tops, casing strings, tests, production records and source documents.
What happens when a value is illegible?
GAEA does not silently guess. The structured value is left blank or assigned the agreed status, while the source text, document reference and reason for uncertainty are recorded in an exception register.
Which output formats are available?
Depending on scope, outputs can include CSV, Microsoft Excel, JSON, XML, SQL or client-defined import tables, along with a searchable source index, data dictionary, mapping document, exceptions and QA/QC summary.
Does digitization verify that historical information is correct?
No. Digitization transcribes and structures the source record. It can identify format, range and cross-field inconsistencies, but it does not independently establish that the historical record is factually or legally correct.
How is a project priced?
Pricing is established after representative records are reviewed. Ticket count, pages, field count, handwriting, source quality, repeating tables, unit normalization, database mapping, verification level and import testing affect cost and schedule.
Is the downloadable package real well data?
No. The source ticket, identifiers, geometry, dates, depths and results are entirely synthetic and are provided only to demonstrate relational structure, source linkage and exception handling.
Have a Scout-Ticket Collection to Evaluate?
Send representative records, an estimated document count and the required fields or target database. GAEA will confirm scope, exceptions, verification, delivery and price.
