← All writing

From Draft to Artifact: The First Thing You Build with RECALL

Most people who find RECALL want to publish one thing — a case study, a report, a structured brief. That instinct is correct, and it leads somewhere larger. Three use cases, one progression: publish one thing, make it a template, watch the audit trail appear.

Michael Shatny··6 min read

The Immediate Instinct

Most people who find RECALL want to publish one thing. Not a full site. Not a design system. One piece — a case study, a report, a structured brief — something they already have in draft form that they want to turn into a clean, shareable HTML artifact.

That instinct is correct. It is the right starting point. And it leads somewhere larger than it first appears.

Three Use Cases, One Progression

The three most common ways people reach for RECALL follow a natural arc. Each one unlocks the next.

1

Publish one thing

The first artifact

You have content — notes, a doc, a brief. You want to turn it into a formatted, self-contained HTML page. One file in, one polished artifact out. No build pipeline, no framework, no CSS decisions.

The DATA DIVISION is your brief. The PROCEDURE DIVISION is your layout. You declare the content, the compiler produces the artifact.

DATA DIVISION.
   WORKING-STORAGE SECTION.
      01 TITLE    PIC X(60)  VALUE "Q1 Market Analysis".
      01 SUMMARY  PIC X(400) VALUE "Revenue grew 18% quarter-on-quarter...".
      01 DATE     PIC DATE   VALUE "2026-04-14".

PROCEDURE DIVISION.
   RENDER.
      DISPLAY LABEL DATE.
      DISPLAY HEADING-1 TITLE WITH STYLE SANS.
      DISPLAY PARAGRAPH SUMMARY.
   STOP RUN.

The compiler produces a self-contained HTML file. No dependencies. Open it in a browser, email it, publish it. The source is embedded in the output — the artifact remembers what produced it.

2

Make it a template

The repeatable structure

Once the first page works, the next thought is always the same: I do this every month. The structure you defined once becomes a template. The PROCEDURE DIVISION does not change. The DATA DIVISION does.

New brief, same layout, new page. That is the ratio argument for RECALL — the gap between what you declare and what the compiler produces compounds with every repeat.

* Same PROCEDURE DIVISION — different DATA every month.

DATA DIVISION.
   WORKING-STORAGE SECTION.
      01 TITLE    PIC X(60)  VALUE "Q2 Market Analysis".
      01 SUMMARY  PIC X(400) VALUE "Momentum continued into Q2...".
      01 DATE     PIC DATE   VALUE "2026-07-14".

   ITEMS SECTION.
      01 KEY-METRICS.
         05 KM1.
            10 STAT-VALUE PIC X(10) VALUE "24%".
            10 STAT-LABEL PIC X(30) VALUE "Revenue growth".

The PROCEDURE DIVISION is your template. The DATA DIVISION is your brief. LOAD FROM can pull both from a JSON file — making the template drivable by any upstream system.

3

The audit trail appears

The one you did not plan for

This use case arrives uninvited. Once you are publishing at volume — or sharing externally — you start caring about something you did not anticipate: the artifact knowing who wrote it.

RECALL's IDENTIFICATION DIVISION is not metadata for the browser. It compiles into every artifact. The AUDIT DIVISION goes further — authorship is a compile-time constraint. Three valid values: Human, AI compositor, or AI agent. The compiler enforces it.

IDENTIFICATION DIVISION.
   PROGRAM-ID.   Q2-ANALYSIS.
   PAGE-TITLE.   "Q2 Market Analysis".
   AUTHOR.       Research & Intelligence.
   DATE-WRITTEN. 2026-07-14.

AUDIT DIVISION.
   CREATED-BY.    AI compositor.
   CREATED-DATE.  2026-07-14.
   CHANGE-LOG.
      2026-07-14  SUMMARY updated. Human. "Adjusted conclusion.".

The artifact does not just contain your content. It knows its own provenance — who created it, when, and which changes were made by a human versus an AI. That travels with the compiled HTML, permanently.

Who Reaches for It

Three profiles come up consistently. Each arrives with a different pain and reaches the same conclusion through a different door.

The Analyst

Produces structured deliverables repeatedly. Reports look different every time depending on who formats them.

RECALL gives a structure that compiles consistently. Same template, new data, every month.

The Product Person

Needs to ship a brief or announcement. Has the content, not the layout instinct.

RECALL compiles content into a clean artifact without touching a stylesheet. One compile, done.

The Researcher

Publishes structured analysis. Markdown is too loose — renders differently everywhere it lands.

RECALL gives typed fields, explicit authorship, a compiled artifact with embedded provenance.

The Shortest Path

The gap between “I’m excited” and “I have a working first page” should be measured in minutes, not hours. The playground closes it.

Load the CASE STUDY preset. Read the source on the left, see the compiled output on the right. Change a value in the DATA DIVISION — recompile. The source is the brief, the output is the artifact. That is the full loop, live in the browser.

RECALL Playground

Write source, compile to HTML, live in the browser. Start with the CASE STUDY preset.

Open Playground →

The three use cases above are not sequential requirements. Most people start at use case one and never need to go further — and that is a complete, useful outcome. The template and audit trail are there when the work demands them.

Related

Michael Shatny is a software developer and methodology engineer and founding contributor to .netTiers (2005–2010), one of the earliest schema-driven code generation frameworks for .NET. His work spans 28 years of the same architectural pattern: structured input, generated output, auditable artifacts. RECALL is the latest expression of that instinct — applied to the question of what a web language looks like when it is designed for intent first.

ORCID: 0009-0006-2011-3258