The Page That Proves Itself

The Gap Every Publishing System Ignores

Every publishing tool has the same blind spot. You write source, compile it, and deploy the output. From that point on, the source and the artifact live separately. The artifact is what the world sees. The source is what you have locally. There is no mechanism connecting them — nothing that can look at a live page and say: this is what the compiler produced. Nothing has been changed.

For most publishing systems, this gap is tolerated as a fact of life. HTML is mutable. Servers get patched. CDN caches serve stale content. Editors make post-deploy fixes directly in the output. The live page drifts from the source quietly, invisibly, without record.

This gap matters more now than it used to. When AI is generating meaningful portions of published content — reports, case studies, briefings — the question of whether the live page matches the compiled source is not just a quality concern. It is a provenance concern. The AUDIT DIVISION records who wrote the source. But nothing has ever verified that the deployed artifact is the source.

RECALL v1.2 closes that gap with one command.

What RECALL Already Does

Every file compiled by recall compile embeds its own .rcl source in a structured HTML comment at the top of the output. Not a reference. Not a path. The full source, line by line, in the artifact itself.

<!--
******************************************************
* RECALL COMPILED OUTPUT
* SOURCE: (embedded below)
* RECALL VERSION: 1.2.0
******************************************************

* IDENTIFICATION DIVISION.
*    PROGRAM-ID.   Q2-ANALYSIS.
*    PAGE-TITLE.   "Q2 Market Analysis".
*    AUTHOR.       Research & Intelligence.
*    DATE-WRITTEN. 2026-05-30.
*
* DATA DIVISION.
*    WORKING-STORAGE SECTION.
* ...

******************************************************
-->

This is the “source is the artifact” principle in its literal form. Open any RECALL-compiled page in a browser, view source, and the .rcl that produced it is right there. The artifact remembers.

But remembering is not the same as proving. Embedding the source answers the question what was this compiled from? It does not answer: does the live artifact still match that source? The comment can be read. The HTML around it can be changed independently. Until now, there was no way to check.

recall validate

The command is exactly what it sounds like. Point it at any compiled RECALL artifact — a local file or a live URL — and it verifies the artifact against its own embedded source.

recall validate page.html
recall validate https://recall.semanticintent.dev

When the artifact is clean — when the compiled output matches its embedded source — the result is direct:

  ✓ VALID  page.html
  Artifact matches its embedded source.

When it does not match, the artifact has been changed after compilation:

  VALID-001  page.html
  The compiled output does not match the embedded source.
  The HTML file may have been modified after compilation.
  Run: recall compile page.rcl to regenerate a clean artifact.

For CI pipelines, structured output is available:

recall validate page.html --format json

{
  "ok": false,
  "code": "VALID-001",
  "file": "page.html",
  "message": "Compiled HTML does not match the embedded source."
}

# Exit codes: 0 = valid, 1 = invalid or no embedded source

How the Validation Works

The validation runs three steps, and the order matters.

The key design decision is in step 2. When the .rcl source file is alongside the compiled .html, the validator uses it — because COPY FROM and LOAD FROM require the filesystem to resolve. For URL validation — or when only the .html exists — the embedded source is used directly. Simple pages validate cleanly either way. Complex pages with external references should be validated locally with the source alongside.

What It Catches

The failure mode recall validate is designed for is specific: the HTML body has been edited after compilation, but the embedded source comment has not been updated to match.

This is the most common form of post-deploy drift. A heading gets corrected. A number gets updated. A link gets patched. The edit is made directly in the output file — faster than recompiling, invisible in most workflows. The source and the artifact have diverged, and nothing records it.

What recall validate does not catch: a person who changes both the HTML and the embedded source comment consistently — updating both sides of the gap. That is not tampering; that is editing the source by hand. The fix for that is recall compile. The fix for everything else is recall validate.

The Diagnostic Codes

Three outcomes, three codes. All are stable identifiers — they appear in --format json output, scriptable in CI, and listed in recall explain --list.

Provenance and Integrity

RECALL has had two complementary ways of thinking about trust in an artifact.

The AUDIT DIVISION — introduced in v1.1 — addresses provenance: who wrote the source, when, and what changed between versions. It makes authorship a compile-time constraint rather than a convention. A RECALL source with a valid AUDIT DIVISION is both compiled and traceable.

recall validate addresses the other half: integrity. Not who wrote it, but whether what is live is what was compiled. Provenance without integrity means you know who wrote the source but cannot verify the artifact matches it. Integrity without provenance means the artifact is clean but carries no authorship record.

Together, they describe a RECALL artifact with a complete trust model. The source declares who wrote it. The compiler enforces both the authorship record and the output format. The validator confirms the deployed artifact has not drifted from the compiled source. The full chain — author to source to artifact to deployment — is verifiable at every link.

No other publishing language has this. The COBOL instinct that produced RECALL was always about encoding intent so precisely that the artifact could stand alone. “The source is the artifact” started as a design constraint. recall validate makes it a runtime guarantee.

Related