Publishable artifacts and proof

Concrete deliverables:

• Files stakeholders can open, diff, or archive: PDFs, zips, static sites, repos.
• Reproducible generation steps (“run this command, get this artifact”).
• Evidence that work completed: logs, hashes, or release notes—not vibes.

The novel PDF on this site is an example of publishable proof for long-form work (download).

• Agents plus local execution can run compilers, formatters, and exporters when wired safely.
• Timeline visibility supports audit narratives: what produced the artifact.
• Approval gates help before artifacts leave your network or hit production.

1. Define the artifact (format, audience, acceptance checks).
2. Script the build where possible; avoid manual copy-paste from chat.
3. Version outputs or tag releases.
4. Validate with automated checks when available (lint, PDF sanity, link check).
5. Publish through your normal channel (drive, GitHub Releases, web).

• Toolchain installed for your target format.
• Naming/versioning scheme everyone understands.
• Storage for large binaries if applicable.

1. Prototype one artifact end to end.
2. Capture exact commands in docs or scripts.
3. Add CI or local check if the artifact matters.
4. Peer review the artifact—not just the prompt log.

• “Produce release notes from this diff; no internal ticket IDs.”
• “Validate this PDF plan: fonts, margins, chapter breaks.”
• “List acceptance checks a human should run before ship.”

• Artifact opens on a clean machine without secret steps.
• Checksums or tags exist if integrity matters.
• Owners agree on what “done” means.

• Chat screenshots as “deliverables”—not archivable.
• Fragile manual steps—automate when value justifies it.
• Huge binaries without retention policy—plan storage.