RECALL-JCL: The Contract at Every Boundary

The Problem Is Never the Connection

Connecting two systems is trivial. A POST request, a queue message, a function call. The transport layer has been solved for decades. What has not been solved is the gap between what one system thinks it sent and what the other system thinks it received.

That gap is not a bug. It is the default state of distributed systems. Every boundary between two independently developed programs carries an implicit contract — assumptions about field names, type lengths, status vocabularies, failure modes — that exists nowhere in the code. It lives in documentation that drifts, in team memory that turns over, in integration tests that cover the happy path and nothing else.

When the implicit contract breaks, it breaks at runtime. In production. At the boundary nobody thought to check. The cost of an undeclared gap in a distributed system is always paid later than it should be, always by someone who did not create it.

RECALL-JCL is built on a single premise: the contract at every boundary should be declared before anything runs, validated by a compiler, and embedded permanently in the artifact that proves the pipeline executed as designed.

Declaration as the Unit of Trust

A RECALL-JCL program is a declaration of a distributed workflow. Not a script that runs steps. A structured document that states, before execution begins, exactly what the workflow intends to do — and what every program it touches is expected to accept and return.

The structure is the same four divisions that govern every RECALL program:

IDENTIFICATION DIVISION.     — who this workflow is and what version it is
ENVIRONMENT DIVISION.        — where each program lives and how to reach it
DATA DIVISION.               — every field this workflow reads or writes, typed
PROCEDURE DIVISION.          — named steps with explicit orchestration verbs

The ENVIRONMENT DIVISION is where JCL answers the distributed question. An ADAPTERS SECTION declares every program the workflow will invoke — whether it runs in a Cloudflare Worker, an Azure VM, a local process, or a queue-backed service — and the transport that bridges the distance.

ENVIRONMENT DIVISION.
   CONFIGURATION SECTION.
      RUNTIME    cloudflare-durable-object.
      ON-FAILURE notify-ops-failure.

   ADAPTERS SECTION.
      ADAPTER recall-email
         TRANSPORT http
         ENDPOINT  "https://api.semanticintent.dev/email"
         AUTH      bearer-token
         SECRET    EMAIL_API_TOKEN.

      ADAPTER recall-llm
         TRANSPORT local
         EXEC      "recall-llm run"
         CWD       "/workspace/recall-llm".

      ADAPTER recall-devops
         TRANSPORT azure-devops-api
         ORG       "semanticintent"
         PROJECT   "recall"
         SECRET    AZURE_PAT.

Three programs. Three different runtimes. One declaration. The INVOKE verb in the PROCEDURE DIVISION stays identical regardless of where each program lives — the adapter layer handles the location. The contract layer handles the trust.

The Compile-Time Boundary

Every INVOKE statement in a JCL program crosses a boundary. Data leaves the workflow, enters a child program, and a result comes back. In every existing orchestration framework that boundary is validated at runtime — when the call is made and the response arrives.

In RECALL-JCL, the boundary is validated at compile time.

Each RECALL variant — RECALL-PUBLISH, RECALL-EMAIL, RECALL-DEVOPS — exposes a machine-readable manifest that declares its DATA DIVISION: every field it expects, every field it returns, with PIC types. Before the JCL compiler emits an execution plan, it resolves every manifest for every invoked program and runs cross-program CRD validation at each boundary.

$ recall-jcl compile content-workflow.jcl

  Resolving manifests...
    recall-publish   ✓  contract loaded
    recall-email     ✓  contract loaded
    recall-devops    ✓  contract loaded

  Validating boundaries...
    [JCL-E03]  PUBLISH step — field SLUG passed in WITH DATA
               has no matching declaration in recall-publish/content-page
               → Add SLUG PIC X(80) to content-page or remove from WITH DATA

  1 error — execution plan not emitted

The pipeline does not compile. Not because the transport failed. Not because a runtime exception was thrown. Because the compiler read the contract of the child program and found a field that does not belong there.

This is the shift that matters: from runtime discovery of contract violations to compile-time proof of contract validity. The boundary is verified before a single byte moves across it.

WITH INTENT at the Boundary

Not every boundary can be fully declared upfront. Legacy vendor APIs with undocumented response formats. Systems where the business rule at the boundary exists only in someone's head. Integration contracts that are agreed in principle but not yet formalised in types.

These are the boundaries where every orchestration framework fails silently. The payload arrives. The type is wrong. The pipeline continues with corrupt state, or halts with a generic error, or — worst — succeeds with a silently wrong result.

RECALL-JCL handles these boundaries with PERFORM WITH INTENT — an AI-driven decision step that interprets an ambiguous payload against a declared intent and resolves it into typed DATA DIVISION fields before anything downstream touches it.

PROCEDURE DIVISION.
   INTERPRET-STATUS.
      PERFORM WITH INTENT
         "Map vendor status codes to internal workflow states.
          ACTIVE and ENABLED map to RUNNING.
          SUSPENDED and LOCKED map to HALTED.
          Anything else maps to UNKNOWN."
         WITH DATA  RAW-VENDOR-STATUS
         RESOLVE    WORKFLOW-STATE.

      GATE boundary-review
         WITH APPROVERS OPS-TEAM
         REASON "Unvalidated vendor boundary — human review required".

The AI interprets. The RESOLVE clause validates the result against the declared PIC type. The GATE suspends execution until a human confirms the interpretation before it crosses into the next program. Nothing is hidden. The gap is named, handled, gated, and auditable.

WITH INTENT at the boundary is not a permanent state — it is a formalisation runway. The GATE decisions accumulate. Patterns emerge. Eventually the implicit contract becomes explicit enough to replace WITH INTENT with a direct type declaration. The gap closes from intent to type, gradually and traceably.

The Covenant: Proof That a Program Belongs

Any program can claim to be RECALL-compatible. The manifest can be hand-written. The types can be asserted. The contract can be declared without the program actually honouring it at runtime.

The RECALL Covenant is the verification layer. Four properties that define any program as a first-class participant in a RECALL pipeline:

DECLARES-IDENTIFICATION    — PROGRAM-ID, version, author
DECLARES-DATA-CONTRACT    — all inputs and outputs typed before use
EXPOSES-MANIFEST          — manifest --json returns a valid contract
PRODUCES-SEALED-ARTIFACT  — execution produces a verifiable, auditable output

The VALIDATE RECALL-COMPLIANCE verb enforces this at compile time. The compiler calls each program's manifest endpoint, runs each property check in sequence, and either confirms compliance or emits a precise diagnostic.

PROCEDURE DIVISION.
   VALIDATE RECALL-COMPLIANCE "recall-email"
      AGAINST RECALL-COVENANT.

   VALIDATE RECALL-COMPLIANCE "legacy-billing-api"
      AGAINST RECALL-COVENANT
      WAIVE PRODUCES-SEALED-ARTIFACT
      REASON "vendor does not support artifact format — GATE required at boundary".

The waiver is not a failure. It is an honest declaration. The program is not excluded from the pipeline — it is classified as Managed, its gap is documented in the execution plan, and the waiver reason is embedded permanently in the sealed artifact. Every run carries a record of what was compliant, what was waived, and why.

The covenant produces a three-tier classification: Native (fully compliant), Managed (compliant with declared waivers), Excluded (cannot be validated, no waiver granted). Trust in the pipeline is not assumed. It is earned, declared, and auditable.

Why This Is AI-First Infrastructure

The RECALL philosophy is not about constraining AI. It is about giving AI the complete, typed, declared brief it needs to perform at full capability.

A RECALL-JCL execution plan is the cleanest possible input an AI compositor can receive. Every field is typed. Every boundary is validated. Every step is named. Every intent is declared. The AI does not need to infer what the workflow is trying to do — the workflow has stated it explicitly in the DATA DIVISION and the PROCEDURE DIVISION before the AI compositor is ever invoked.

This matters because the failure mode of AI in distributed pipelines is not hallucination — it is incomplete context. An AI given a partial brief produces a partial result. An AI given an ambiguous schema fills gaps with assumptions. An AI given undeclared intent makes decisions that look correct locally and are wrong at the boundary.

RECALL-JCL eliminates the partial brief. The execution plan carries the full contract. The manifest carries the full schema. The covenant carries the full trust record. When the AI compositor receives a PERFORM WITH INTENT step, it has everything it needs: the declared intent, the input fields with types, the output fields with their PIC constraints, and the philosophy of the pipeline it is operating within.

Clean input. Full capability. No guessing.

Where This Fits in the Landscape

The distributed systems landscape has four existing categories. RECALL-JCL sits at the intersection of all of them without being any of them.

Category              Examples               What it solves      What it misses
──────────────────────────────────────────────────────────────────────────────
Workflow orchestration Airflow, Temporal      Running steps        Boundary contracts
Infrastructure as code Terraform, Bicep       Declaring state      Workflow intent
API contract standards OpenAPI, Protobuf      Typing boundaries    Orchestration
Enterprise integration MuleSoft, Logic Apps   Connectivity         Declaration

Workflow orchestration tools are excellent at running steps in order. They are imperative — the contract between steps is implicit in the code. A broken boundary fails at runtime. RECALL-JCL declares the boundary first and refuses to compile if it is wrong.

Infrastructure as code is declarative, typed, and auditable — closest in philosophy. But it describes infrastructure state, not workflow intent. It has no PERFORM WITH INTENT. It has no GATE. It has no covenant.

API contract standards specify what a service accepts and returns. Excellent type discipline at the boundary. But they describe interfaces, not workflows. They cannot orchestrate. They cannot validate that two contracts are compatible before a pipeline runs.

Enterprise integration tools solve the connectivity problem. They do not solve the declaration problem. The intent behind each step lives in documentation somewhere else — if it exists at all.

The genuinely novel combination is compile-time boundary validation across heterogeneous runtimes, WITH INTENT as a first-class orchestration primitive, and the covenant as a language-level trust mechanism. None of these exist together in any current framework.

The Sealed Artifact

Every RECALL-JCL workflow that runs to completion produces a sealed artifact — a structured, immutable JSON record of what ran, what each step received, what each step produced, and what the covenant assessment was for every program in the pipeline.

{
  "schema":     "recall-jcl-artifact/1.0",
  "programId":  "CONTENT-WORKFLOW",
  "workflowId": "wf-2026-04-10-0042",
  "status":     "COMPLETED",
  "sealedAt":   "2026-04-10T09:14:22.441Z",
  "covenant": {
    "recall-email":       { "tier": "Native",  "waivers": [] },
    "legacy-billing-api": { "tier": "Managed", "waivers": [
      { "property": "PRODUCES-SEALED-ARTIFACT",
        "reason": "vendor does not support artifact format" }
    ]}
  },
  "steps": [
    { "name": "CLASSIFY",  "status": "COMPLETED", "durationMs": 312  },
    { "name": "PUBLISH",   "status": "COMPLETED", "durationMs": 1840 },
    { "name": "NOTIFY",    "status": "COMPLETED", "durationMs": 203  }
  ]
}

The artifact is the proof that the pipeline executed as declared. Not as a log file appended during execution. As a sealed record written at STOP RUN — immutable, auditable, git-storable, comparable across runs.

For regulated environments — financial services, healthcare, compliance-bound infrastructure — this artifact is not a developer convenience. It is the audit evidence that the pipeline operated within its declared contract. The waiver record answers the question: we knew this boundary was unvalidated, here is why we permitted it, here is the human gate we placed at it.

The industry is still debating whether to put type annotations on REST APIs. RECALL-JCL proposes that the type annotation is only the beginning — that the declaration must extend from the field level to the boundary level to the program level to the workflow level, and that the proof of that declaration must be embedded permanently in every artifact the pipeline produces.

Distributed systems are not hard because the transport is hard. They are hard because the contract between systems is invisible. RECALL-JCL makes the contract the program. The rest is just execution.