Artifacts
The immutable, reusable content unit that unifies contexts, tools, and schemas under one object type, with strict immutability invariants.
An artifact is the smallest reusable thing in Zumik: one immutable unit of content with a stable opaque ID. Instead of maintaining separate, inconsistent registries for contexts, tool definitions, and schemas, Zumik folds them all into a single object type distinguished by an artifact_type tag.
{
"id": "art_01jy7n3q8v...",
"object": "artifact",
"artifact_type": "policy",
"project_id": "prj_01jy...",
"content_media_type": "text/plain",
"created_at": "2026-06-09T20:15:00Z",
"retention_class": "standard",
"metadata": { "label": "repository-policy" }
}Artifact types
artifact_type records what the content is, which drives serialization and fingerprint domain separation. The supported values:
| Value | Typical content |
|---|---|
text_context | Stable instructions or workspace context |
tool_bundle_source | Tool / function definitions |
response_schema | A structured-output JSON schema |
document | A long-lived reference document |
retrieval_chunk | A retrieved knowledge fragment |
policy | A repository or tenant policy |
checkpoint | A session checkpoint reference |
compaction_summary | A compacted summary of prior history |
binary_attachment | Non-text attachment bytes |
Tip
The type participates in the internal fingerprint, so identical bytes registered as a policy and as a document are deliberately not treated as the same content. See handles and fingerprints.
Retention class
Each artifact carries a retention_class of ephemeral, standard, or extended. This expresses how long the content should be kept available and feeds into retention and purge behavior. It is a property of the content, not a billing knob.
Immutability invariants
Artifacts are immutable after creation. This is not a convenience; it is what makes them safely reusable and what makes deletion meaningful.
Content never changes
There is no update operation. To change content, you create a new artifact and get a new ID. The old ID always refers to exactly the bytes it was created with.
The public ID is opaque
IDs are random art_... handles, never content hashes. You cannot infer equality between two artifacts from their IDs, and a leaked ID reveals nothing about its content.
Deletion is explicit and irreversible
DELETE /v2/artifacts/{id} revokes the handle. Re-uploading identical bytes later creates a new opaque handle; it does not resurrect the old one or any cache relationship tied to it.
Because content is immutable, an artifact is the right home for anything stable and reused: system instructions, tool registries, schemas, long documents. Anything that mutates per turn belongs in a session event, not an artifact.
Where artifacts go next
An artifact on its own is just content. It becomes useful when ordered into a bundle and attached to a session, where the platform can measure how often it recurs and how much of it is actually reused.
API surfaces
Strict OpenAI compatibility on /v1, native state on /v2, and the one rule that keeps them apart - proprietary behavior travels through headers or /v2, never by changing upstream JSON.
Bundles
An ordered, immutable list of artifact references where the order carries meaning and is never sorted automatically.