Artifacts & publishing

Everything an agent produces that someone might read, use, or ship is an artifact: a document, a page, an image, a video, an audio file, a data file. Three decisions about artifacts shape the whole review-and-publish experience.

1. The registry owns identity; storage holds bytes

An artifact is identified by a stable id in a registry, not by a file name or a folder. Its bytes live in durable storage under a content hash; a name or path is a label that can change. Prose that people edit canons as files in version control; media canons in the registry with durable object storage behind it — but in both cases the thing a chat card, a task, or a calendar entry points at is the identity, not the location.

What this buys you: rename a deliverable, retitle a task, reorganise a folder, and every link still resolves. The rule exists because the opposite kept happening — four different spellings of a file path each broke rendering, silently.

2. Versions are explicit, and feedback attaches to them

A version is one explicit state of an artifact. Editing creates a new version; the previous one stays, with its comments and its rating. “Approve” always means approve this version. The trail of versions with their notes is also the raw material for the improvement contract: which change moved the rating, and why.

3. Structure is a by-product of the work, never a separate declaration

Where an artifact sits, what it is tagged, which task it belongs to — all of that is written by the tool that produced it, at the moment it was produced. Nobody files things afterwards, and nothing is inferred later from a path. It is the only way the picture stays complete when hundreds of artifacts a week are made by agents rather than people.

Three organising axes are available without duplicating anything: tags (what it is about), task (what it was made for), and recency (what is current). A deliverable is marked as a deliverable; the current version of a brand asset is promoted into the brand’s asset library from a task, rather than copied.

Publishing

Approval is a decision; publishing is an action. When you publish an approved version:

1. It goes out through a named connection — a store, Pinterest, a site, an ad platform, email — under that connection’s scope and permissions.
2. The connection records success or failure per item and the external identifier that came back: the listing, the post id, the page URL.
3. That identifier is what later lets a click, a sale, or a comment be matched to exactly the version that shipped.

Media has one extra guard: the publish gate. A task cannot be marked review or done while a media file in it has no completed publish to durable storage — so “approved” never refers to a file that only exists on someone’s disk. See Media generation.

What is not an artifact

• A chat message. It can reference artifacts by identity.
• A run. A run is what produced the artifact; it has a receipt of its own.
• A working file inside a task that nobody marked as a deliverable — it is kept for lineage, not surfaced for review.

live Registry-owned identity, content-addressed bytes with durable primary storage, labels, explicit versions with anchored comments, deliverable marking, and recorded external identifiers on publish are live. direction Bringing every remaining path-keyed reader onto identity-based references is the current completion work; a consistent published-artifact lifecycle for hand-authored documents and diagrams is proposed.

Related

Tasks and the WorkbenchWhere versions are reviewed and approved.

Media generationReceipts, the asset model, and the publish gate.

ConnectionsWhat publishing goes through.

FoundationsThe governance plane these rules belong to.