How to Structure and Validate Peptide COA Data Using Python

PeptideGrading — Thu, 05 Nov 2026 12:50:43 +0000

Building a research database involves more than collecting information. The real challenge is making sure data from different sources remains consistent, accurate, and useful.

This is especially important when working with laboratory reports.

A Certificate of Analysis (COA) documents the results of specified tests performed on a sample or batch. In peptide research, these reports may contain information about purity, molecular identity, analytical methods, and batch identification.

However, laboratory reports don't always follow the same structure.

Some provide detailed analytical information. Others display a purity percentage with limited supporting documentation.

Research-data platforms such as Peptide Grading organize publicly available peptide supplier information and laboratory documentation, illustrating why consistent data structures matter when comparing research records.

So how can developers organize COA information and identify missing or inconsistent data?

Let's build a simple validation workflow using Python.

Understanding Peptide COA Data Before creating a database, we need to understand which information should be stored.

A peptide COA may contain several useful fields.

Report ID: Identifies the laboratory report.

Batch ID: Connects the report to a specific sample batch.

Testing Date: Records when the analysis was performed.

Analytical Method: Identifies the testing technique used.

Purity Percentage: Records the reported purity measurement.

Identity Method: Documents the technique used to examine molecular identity.

These fields provide important context for interpreting laboratory findings.

For example, high-performance liquid chromatography (HPLC) can be used to evaluate peptide-related impurities, while mass spectrometry can provide evidence about molecular identity.

However, an HPLC purity percentage does not automatically represent the total peptide mass content of a sample.

Similarly, mentioning mass spectrometry does not establish that identity testing was performed adequately.

Our objective is to organize laboratory information, not independently certify a report's scientific conclusions.

Representing Laboratory Reports Using Python Let's start with two hypothetical COA records.

Both contain reported purity measurements, but their supporting documentation differs.
records = [
{
"report_id": "COA-001",
"batch_id": "LOT-A17",
"test_date": "2026-10-20",
"method": "HPLC",
"purity_percent": 98.7,
"identity_method": "LC-MS"
},
{
"report_id": "COA-002",
"batch_id": "",
"test_date": "2026-10-22",
"method": "",
"purity_percent": 99.2,
"identity_method": None
}
]
These are fictional examples created for demonstration.

Notice something interesting.

The second report displays a higher purity percentage, but three important fields are missing.

Batch identifier: Missing

Analytical method: Missing

Identity-testing information: Missing

A research database should preserve these differences instead of treating both reports as equally documented.

Creating a Python Data Validator We can create a simple function to identify missing or invalid information. from datetime import date from math import isfinite

def validate_coa(record):
issues = []

required_fields = (
    "report_id",
    "batch_id",
    "test_date",
    "method",
    "identity_method"
)

for field in required_fields:
    value = record.get(field)

    if not isinstance(value, str) or not value.strip():
        issues.append(f"Missing {field}")

purity = record.get("purity_percent")

if (
    isinstance(purity, bool)
    or not isinstance(purity, (int, float))
    or not isfinite(purity)
    or not 0 <= purity <= 100
):
    issues.append("Invalid purity_percent")

test_date = record.get("test_date")

if isinstance(test_date, str) and test_date.strip():
    try:
        date.fromisoformat(test_date)
    except ValueError:
        issues.append("Invalid test_date format")

return issues

This validator performs three basic checks.

Required Fields

It identifies missing or empty text fields.

Purity Values

It checks whether the reported purity is a finite numerical value between 0 and 100.

Date Format

It verifies that a provided testing date follows an ISO date format.

This is structural validation.

It does not establish whether a report is authentic or whether its laboratory measurements are scientifically correct.

Testing the Validation Function
Now let's test our hypothetical records.
for record in records:
issues = validate_coa(record)

if issues:
print(record["report_id"], issues)
else:
print(record["report_id"], "No validation issues")
Expected output:
COA-001 No validation issues
COA-002 ['Missing batch_id', 'Missing method', 'Missing identity_method']
The validator successfully identifies missing fields in the second report.

However, an important distinction remains.

A report passing structural validation is not necessarily a verified laboratory report.

It simply satisfies the database requirements we defined.

Scientific verification requires additional evidence.

Why COA Data Completeness Matters Imagine a research database containing hundreds of laboratory reports collected from different sources.

Some reports include detailed analytical documentation.

Others provide only a headline purity percentage.

Without consistent data structures, users may struggle to understand what information is available.

Consider these examples.
Report A
Purity: 98.7%

Batch identification: Available

Analytical method: Documented

Identity method: Documented
Report B
Purity: 99.2%

Batch identification: Missing

Analytical method: Missing

Identity method: Missing

Although Report B displays a higher purity percentage, it provides less supporting documentation.

That does not prove Report A is scientifically reliable or Report B is inaccurate.

It means the reports provide different levels of information for evaluation.

This distinction becomes especially important when building searchable laboratory databases, scientific information systems, and research documentation platforms.

Designing a Better Research Database For larger applications, I recommend separating COA information into three main components. Report Metadata This describes the laboratory document itself.

Useful fields include:

Report ID: Unique document identifier.

Laboratory Name: Organization identified as performing the analysis.

Batch Identifier: Batch associated with the sample.

Testing Date: Date of analysis.

Source Document: Original PDF or supporting file.
Analytical Results
Instead of storing every laboratory finding in one field, create separate records for individual measurements.

For example:
analytical_result = {
"report_id": "COA-001",
"test_name": "Purity",
"method": "HPLC",
"value": 98.7,
"unit": "%"
}
This structure supports reports containing multiple analytical tests.

It also helps prevent measurements obtained through different methods from being combined without considering their testing context.
Verification Status
A database should distinguish collecting data from verifying it.

Imported: The document has been received.

Parsed: Expected information has been extracted.

Structurally Validated: Required fields satisfy database rules.

Source Reviewed: The original document has been examined.

Analytically Reviewed: A qualified reviewer has assessed the relevant scientific documentation.

These stages should remain separate.

An automated validator should never assign scientific approval simply because the expected fields are present.

Handling Missing and Conflicting Data Real-world datasets rarely arrive in perfect condition.

Laboratory reports may contain missing information, inconsistent terminology, unusual formatting, or conflicting measurements.

A reliable research database should preserve uncertainty rather than silently guessing.
Missing Information
If a testing date is unavailable, store a null value instead of inventing one.
Conflicting Results
If two documents report different values for the same batch, preserve both records and flag the discrepancy for investigation.
Different Analytical Methods
Measurements produced using different methods should retain their original testing context.

Two purity percentages should not automatically be considered directly comparable without understanding how they were measured.
Source Tracking
Every extracted value should ideally retain a reference to its original document.

Useful additional fields include:

Source URL: Where the document originated.

Extraction Method: Manual entry, PDF extraction, or another process.

Review Timestamp: When the information was examined.

Revision History: How records changed over time.

These practices make research databases easier to maintain, audit, and improve.

What Automated COA Validation Cannot Establish Automated data validation is useful, but it has important limitations.

A Python validator cannot determine whether:

A laboratory report is authentic.
A tested sample matches a particular commercial product.
An analytical method was performed correctly.
A reported purity measurement is accurate.
A substance is safe or effective for human use. These questions require additional evidence and, in some cases, qualified scientific review.

A well-designed research platform should communicate these limitations clearly.

Improving the System for Production Use Our Python example is intentionally simple.

For production applications, developers can introduce additional features.

Schema Validation

Use tools such as Pydantic to enforce consistent data types and validation rules.

Database Constraints

Prevent malformed records from entering important database tables.

Document Provenance

Preserve original laboratory reports alongside extracted information.

Automated Testing

Create unit tests for missing fields, invalid numbers, incorrect dates, and conflicting records.

Human Review

Require appropriate review before making scientific verification claims.

Advanced systems can also support PDF parsing, automated document classification, change tracking, and data-validation dashboards.

However, automation should improve transparency rather than hide uncertainty.
Final Thoughts
The challenge of building a scientific research database isn't simply collecting more documents.

It's making the information consistently interpretable.

When organizing peptide Certificates of Analysis, developers should preserve the relationship between reported results, analytical methods, batch identifiers, and original source documents.

A Python validator provides a practical starting point.

But reliable research-data systems also require provenance tracking, transparent handling of missing information, and clear distinctions between structural checks and scientific verification.

These principles are relevant to platforms working with scientific documentation. The Peptide Grading research platform is one example of a project organizing publicly available peptide market information and laboratory records.

Good data architecture doesn't replace scientific verification. It makes the available evidence easier to examine.
References

United States Pharmacopeia, Reference Standards to Support the Quality of Synthetic Peptide Therapeutics: https://www.usp.org/sites/default/files/usp/document/our-work/biologics/reference_standards_to_support_quality_of_synthetic_peptide_therapeutics.pdf
U.S. Food and Drug Administration, Bioanalytical Method Validation Guidance for Industry: https://www.fda.gov/media/70858/download

DEV Community: PeptideGrading

How to Structure and Validate Peptide COA Data Using Python