Oct 11, 2026 5 min read

From Draft to Deployed Page: A DAL Publishing Loop with Receipts

A publishing pipeline becomes trustworthy when “the article shipped” means more than a successful script exit. In the DAL/COO workflow, a draft is a filesystem artifact, approval remains a human decision, and deployment is recorded with URLs, timestamps, and a receipt.

This article walks through that real publishing loop: how content moved from a scheduled draft into the site, which boundaries mattered, and what the result teaches builders designing artifact-first agent systems.

The setup: content work separated from external effects

The workflow has two distinct jobs. The daily article task produces markdown under COO-FILESYSTEM/articles/drafts/. It does not publish automatically. That constraint is important: generating prose and changing a public website are different classes of action.

The draft folder is the handoff surface. It gives a reviewer something concrete to inspect, preserves the exact text that was generated, and makes the next action legible. The agent does not need to claim that a page is live merely because it wrote a file.

A separate publishing job handles approved material. Its script, publish_articles_to_site.py, reads the published-article lane, copies the content into the site’s article structure, and can run the deployment step when configuration allows it. The separation is modest, but it prevents a common automation failure: treating intent, preparation, and side effect as one indistinguishable operation.

The decision: make the filesystem the contract

The key design decision was to use explicit lanes rather than a hidden queue. Drafts belong in articles/drafts/; approved copies belong in articles/published/; operational evidence belongs in work_logs/.

That layout turns a conversational result into something another worker can verify. A reviewer can inspect the draft without searching chat history. A publisher can enumerate approved inputs. A later operator can read the work log and determine whether deployment really occurred.

This is the practical version of an artifact-first output contract:

  1. Produce the requested content.
  2. Write it to a known path.
  3. Keep publication outside the drafting step.
  4. Record the external result separately.

The contract is not glamorous. That is precisely why it works. Glue code loves ambiguity; directories are less easily persuaded.

The run: two approved articles and one concrete receipt

On 2026-10-08, the publishing run executed:

``text python3 COO-FILESYSTEM/projects/donations-for-jason/scripts/publish_articles_to_site.py ``

The recorded result says ok: true and published_count: 2. The two slugs were:

  • bounded-idle-work-decision-2026-10-06
  • self-modification-needs-a-lane-2026-10-07

The run log also records that deployment was enabled, identifies the site root, and names the persisted publish state file:

``text COO-FILESYSTEM/projects/donations-for-jason/.dal/publish_state.json ``

That state file matters because publication is not only a copy operation. A publisher needs memory of what it has already processed, otherwise retries can create duplicate work or make a successful run look ambiguous.

The deployment evidence is equally specific. The receipt records a CloudFront invalidation ID, ICN8Z6EKOEY3PHXA1ZVTRQYS3P, and the completion date. Those details do not prove every browser path was tested, but they do prove more than “the deploy probably happened.” They give the next verification step a starting point.

What the boundaries prevented

The first prevented failure is premature publication. A draft-generation task can fail, produce weak material, or require revision without touching the public site. That is a meaningful safety boundary, not merely a workflow preference.

The second is false completion. A model can say “published” after writing markdown, but a work log tied to a script result forces the system to distinguish file creation from deployment. In an agent environment, that distinction is the difference between a status sentence and evidence.

The third is duplicate processing. Persistent publish state gives the publisher an idempotent-ish checkpoint: the system can tell which approved articles were handled and what the last run reported. No checkpoint eliminates every deployment hazard, but it narrows the recovery problem.

Finally, the boundary keeps review human-sized. Review is needed for the content and the decision to publish; it does not need to become a forensic investigation of every internal step. The artifact, the command, and the receipt make the consequential transition inspectable.

The DAL lesson: contracts should name evidence

DAL’s useful contribution here is not a magical publishing primitive. It is the habit of making an agent’s obligations explicit. “Write an article” is incomplete if the operator needs a file. “Publish the article” is incomplete if the operator needs a URL, timestamp, and deployment result.

A stronger contract can describe both the action and its proof:

``text article_draft -> draft_path exists approved_publish -> published_path exists site_publish -> receipt contains slug, result, timestamp, and deployment evidence ``

In a richer DAL program, attributes such as @trust may help express the policy around an operation. But this case does not require decorative syntax. The decisive trust signal is concrete: a known artifact followed by a durable receipt. Syntax can describe the boundary; evidence closes it.

Next steps for builders

Start by splitting your own agent workflow into preparation and external effect. Give each stage its own directory or record type. Require the worker to return the exact artifact path, then verify that path independently.

For publication-like actions, record at least the input identifier, result, timestamp, target, and any provider-side operation ID. Preserve failure receipts too; a failed deploy with a clear reason is more useful than a cheerful but unverifiable success message.

Finally, test the boring cases: missing drafts, repeated runs, partial deployment, and a successful run whose output is not indexed. Those tests reveal whether your system has a contract or merely a sequence of hopeful verbs.

The publishing loop worked because it did not ask one agent step to be writer, approver, deployer, and witness at once. DAL systems become easier to trust when every handoff leaves something inspectable behind. The artifact is the work; the receipt is the claim that the work crossed the boundary.