CORDspec as Contract: How the Envelope Travels

The previous posts in this series have argued that AI systems need contract layers and that CORDspec is the protocol designed for that role. This post is the architecture. How a CORD envelope is built, how it travels between systems, and what each system does with it.

Less abstract. More mechanical. Built for engineers who need to know whether the protocol is implementable in their stack before they invest more attention.

The Lifecycle of an Envelope

Five stages. Each one has a specific responsibility.

One. Creation. A producing system has data to send. It wraps the data in a CORD envelope. The wrapping process is the contract authorship moment. The producer declares what the data is, what it means, where it came from, and what must be preserved when downstream systems consume it.

Two. Transport. The envelope travels from producer to consumer. The transport layer is independent of the protocol. CORD envelopes can travel over HTTP, queue systems, file storage, internal RPC. The protocol does not specify the transport because the envelope is self-describing wherever it lands.

Three. Validation. The receiving system validates the envelope before consuming the payload. The validator checks schema conformance, signature verification, freshness against the validity window, and lineage continuity. An envelope that fails validation is not consumed.

Four. Consumption. The receiving system extracts the payload and uses it. Consumption is where the work of the receiving system happens. The CORD layer is satisfied at this point because the envelope has already established the contract.

Five. Re-emission. If the receiving system produces a downstream output that depends on this envelope, the new output is a new envelope. The new envelope's lineage chain includes the consumed envelope as a parent. The chain extends forward.

Every CORD-aware AI system implements at least three of the five stages. Producing systems implement creation. Consuming systems implement validation and consumption. Systems that both consume and produce implement all five.

What an Envelope Looks Like

A simplified example. A producing system that extracts company information for a sales intelligence pipeline.

{
  "cord_version": "0.1",
  "envelope_id": "acme-extraction-2026-08-14-001",
  "producer": {
    "system_id": "company-extractor-v3",
    "version": "3.2.1",
    "model": "gpt-4-turbo-2024-04-09"
  },
  "payload": {
    "company_name": "Acme Industries",
    "employee_count": 287,
    "headquarters": "Chicago, IL",
    "industry": "manufacturing"
  },
  "schema": {
    "@context": "https://schema.org",
    "@type": "Organization",
    "schema_version": "1.4.0"
  },
  "semantics": {
    "employee_count": {
      "unit": "current_full_time_employees",
      "as_of": "2026-08-14T00:00:00Z",
      "confidence": 0.92,
      "source": "linkedin_company_page"
    }
  },
  "lineage": [
    {
      "system": "web-crawler-v1",
      "envelope_id": "linkedin-crawl-2026-08-13-9847",
      "timestamp": "2026-08-13T18:32:00Z"
    }
  ],
  "verification": {
    "created_at": "2026-08-14T09:14:22Z",
    "valid_until": "2026-09-14T09:14:22Z",
    "required_claims": [
      "company_name",
      "industry"
    ],
    "signature": "sha256:a4f8e9..."
  }
}

Six top-level fields. Each one has a specific role. None of them is optional in a valid CORD envelope.

What Each Field Does

cord_version. The protocol version. Receiving systems use it to know which validation rules apply. Versions evolve. Envelopes from older versions remain valid as long as receiving systems implement backward compatibility.

envelope_id. A unique identifier for this specific envelope. Downstream systems use it to reference the envelope in lineage chains. The id is generated by the producing system and must be globally unique within the producer's namespace.

producer. Identifies the system that created the envelope, including version and (where relevant) the underlying model. This is the start of the lineage chain. A receiving system that finds the producer has been deprecated or has known issues can apply additional scrutiny to the payload.

payload. The data itself. Format is JSON-shaped. Content is whatever the producing system needs to send. The payload is the only field that varies significantly between use cases.

schema. Declares the shape of the payload. References a Schema.org type where possible. Includes a schema_version so receiving systems can detect drift.

semantics. Adds meaning beyond the schema. Units. Confidence. Source. Temporal context. The semantics field is what distinguishes CORDspec from raw JSON-LD. It carries the meaning that the schema layer alone does not communicate.

lineage. An ordered list of parent envelopes that contributed to this envelope's payload. Each entry references the parent's envelope_id, the producing system, and the timestamp. The chain extends backward through every system that touched the data.

verification. Created_at and valid_until define the freshness window. Required_claims declares what must survive any downstream transformation. The signature is the producer's cryptographic attestation that the envelope's contents have not been tampered with in transit.

How Validation Actually Works

A receiving system runs four checks before consuming the payload.

Schema check. The payload conforms to the declared schema. Field names, types, required versus optional. Failed schema check means the producing system has drifted and the receiving system should not consume blindly.

Signature check. The signature matches the envelope's contents. Failed signature check means the envelope has been modified after the producer signed it, which is a tampering signal.

Freshness check. The current time is within the validity window. Envelopes outside their window are stale. The receiving system can choose to consume stale envelopes with a warning or reject them outright.

Lineage continuity check. If the envelope claims parents, the parent envelope_ids resolve to envelopes the receiving system can verify. Broken lineage chains do not necessarily fail validation, but they limit downstream traceability.

An envelope that passes all four checks is consumed. An envelope that fails one or more is either rejected or consumed with explicit warnings logged.

How Re-Emission Works

This is the most important architectural detail.

When a receiving system produces a new envelope based on a consumed envelope, the new envelope's lineage includes the consumed envelope. Like this:

"lineage": [
  {
    "system": "company-extractor-v3",
    "envelope_id": "acme-extraction-2026-08-14-001",
    "timestamp": "2026-08-14T09:14:22Z"
  },
  {
    "system": "fit-scorer-v2",
    "envelope_id": "acme-scored-2026-08-14-203",
    "timestamp": "2026-08-14T10:02:15Z"
  }
]

The downstream system's envelope now contains both lineage entries. Three systems consuming downstream see a chain that extends back through every transformation. A failure traced backward through the chain points at a specific producing system with a specific envelope_id at a specific timestamp.

This is what makes CORDspec a contract layer and not just a data format. The contract travels forward through every handoff. Lineage is preserved. Provenance is queryable. Errors are traceable.

What CORDspec Does Not Specify

Three important boundaries.

CORDspec does not specify storage. Envelopes can live in databases, object storage, queue systems, or files. The protocol describes the unit of exchange.

CORDspec does not specify transport. Envelopes can move over HTTP, gRPC, message queues, or shared filesystems. The protocol assumes nothing about delivery semantics.

CORDspec does not specify access control. Authorization, authentication, and confidentiality are layered on top. The envelope itself carries no permission information beyond the producer's signature.

These boundaries are intentional. CORDspec is the contract layer. Other layers handle transport, storage, and security. Conflating them makes the protocol harder to adopt.

What This Means for Implementation

If you are evaluating CORDspec for your AI pipeline, three things to think about first.

One. The producing system needs to add envelope creation logic. This is straightforward in any language. The reference implementation in the CORD Engine repository includes libraries for the common languages. The spec for the AI-to-AI handoff profile is at cordspec.org/ai-contract.

Two. The receiving system needs to add validation and consumption logic. This is more work because every existing consumer needs to be updated. The cost is amortized over the lifetime of the pipeline.

Three. The team needs to agree on envelope IDs, signing keys, and lineage conventions. The protocol does not enforce these. The team enforces them.

The next post in the series goes deeper into the lineage and provenance layer. Fidelity scoring across multi-hop pipelines. How an envelope traceable to its origin protects you from the failure modes the previous post catalogued.

Structure before tools. Strategy before speed. Systems before scale.

The AI Operator Framework is the methodology for designing, governing, and scaling AI operations inside a business, including the data and citation fidelity layers most companies skip. Explore the full framework at JamilAshkar.com/framework. Start with the free course at JamilAshkar.com/course.