Artifacts and outputs

Outputs describe what a run or action produced; artifacts package material for review or downstream use; evidence supports a proposal or conclusion. The runtime contracts represent these concepts, but their storage and retention behavior is not fully established.

Storage locations, access controls, deletion, retention periods, and export durability require further verification.

Downstream reliability depends on provenance and persistence, not the label attached to a value. A structured run output may be transient, an evidence record may require human validation, and an artifact reference may point to material whose storage and retention are environment-dependent. Before another system acts on any of them, it should verify the producing run or action, final state, format, evidence, and persistence mode. The absence of a verified access or retention policy remains a blocking documentation boundary.

Artifact model

An output is the value produced by an action or run. Evidence supports review of what happened. An artifact is a separately identifiable deliverable or record associated with the run. A receipt summarizes execution. An audit event records a governance or lifecycle event. These objects can reference one another but should not be collapsed into a single result.

Evidence types explicitly include source data, screenshots, reports, logs, diffs, exports, and audit snapshots. The type alone does not define storage, access, retention, or export behavior.

Functional-agent contracts can reference artifacts alongside workflow steps, evidence, and proposed actions.

An artifact should remain traceable to the run or action that produced it.

Do not treat every output value as a durable artifact automatically.

An artifact is reviewable or reusable material associated with a run or action. It should remain distinct from the raw output value, evidence that supports a decision, an audit event, and a summarized receipt.

A downstream consumer should verify the producing run or action, final state, format, evidence, and persistence mode. Persistence can be durable, local-file, memory-only, or unavailable.

Output types

Action output belongs to one ordered step; run output represents the execution-level result. A run summary can report whether output exists without exposing the entire value. Functional-agent contracts can also describe artifacts and export readiness.

A missing output does not automatically mean the run failed, because a run may wait, be rejected, be canceled, or produce evidence without a final artifact. Read output together with state and action history.

Runs and actions can carry structured output.

Evidence types include source data, screenshot, report, log, diff, export, and audit snapshot, which may also be presented as reviewable materials.

Artifact MIME types and schemas are not governed by one universal catalog.

Output types are not constrained by one universal MIME or schema catalog in the supplied sources. Runs and actions can carry structured values, while evidence has a declared set of forms such as reports, logs, diffs, exports, and audit snapshots.

An in-memory client-safe store is not equivalent to durable server persistence. Do not claim durable storage, access policy, or retention periods when the supplied sources do not define them.

Storage

Contracts can retain references to artifacts and evidence alongside run metadata, but they do not prove that every artifact body is stored in the same service or persistence mode. A local-file fallback, memory-only execution, or unavailable persistence state changes what can be recovered later. Documentation should therefore describe the reference and observed persistence mode rather than promise a universal storage location.

Persistence mode can be durable, local_file, memory_only, or unavailable. Durable storage is detected through the configured Supabase path. Local-file mode is a private-beta fallback, not production database persistence. Memory-only records can disappear with the process, and unavailable mode cannot promise persistence.

Artifact bodies are not guaranteed to share a storage service with run metadata. Avoid describing a universal object store or download location.

The runtime checks Supabase first and can fall back to private-beta local-file storage.

Storage depends on persistence mode. Durable storage, private-beta local-file fallback, memory-only state, and unavailable persistence have different consequences for recovery and later access.

Functional contracts can reference artifacts alongside steps, evidence, and proposed actions.

Output, artifact, evidence, audit event, export, and receipt have different provenance and persistence expectations.

Access

Access decisions also need to account for persistence. A reference that resolves in one local-file environment may not resolve from another machine or deployment. Documentation should avoid promising portable access unless the durable storage path and authorization behavior are verified.

Access should be scoped through the project, run, agent, and current product controls, but exact artifact authorization rules are not included in the supplied sources. Do not invent public sharing, permanent URLs, role names, or download permissions.

When handing off an artifact, retain its identifier, run and action references, evidence links, type, timestamps, and persistence mode. Exclude secrets and unnecessary user content.

Access should follow the run, workspace, agent, and tool scope represented by the current environment.

The supplied source bundle does not establish a complete artifact role matrix or share-link model.

Avoid placing secrets in outputs or evidence intended for broad review.

A complete access-control matrix and share-link model are not verified. Keep artifacts within the run, workspace, agent, and tool context supported by the current environment, and exclude secrets from broadly reviewable material.

A structured output may still be transient, while an artifact reference may point to storage whose access and retention are environment-dependent.

Retention

No artifact or evidence retention period is verified. Query defaults, local files, and runtime summaries must not be converted into deletion schedules. An empty result can reflect the wrong environment, project, filter, retrieval limit, memory loss, or unavailable persistence.

Keep retention-requires-verification until an authoritative policy and implementation define lifecycle behavior.

No artifact retention period or guaranteed deletion schedule is verified.

Implementation query limits and local-file persistence behavior are not retention policies.

Keep retention claims pending until an authoritative policy and storage implementation are inspected.

No retention period, deletion schedule, or immutable archival guarantee is established. Query limits and local-file behavior are implementation details, not policy commitments.

The handoff should include the output value, evidence record, and artifact reference, with secrets or unnecessary payload content removed. Runs and actions can carry structured output.

Keep every reviewable item traceable to its producing run or action and verify persistence before another system depends on it.

No supplied source defines a universal retention clock. A reference may survive differently under durable, local-file, memory-only, or unavailable persistence, and an exported artifact can have a lifecycle outside the run store. Documentation should state the observed persistence mode and avoid promising deletion or long-term availability.

Downstream use

When a downstream consumer receives only a reference, it should fail closed if the referenced artifact or evidence cannot be resolved under the current persistence mode. Substituting an empty value or unrelated cached file can make a completed run appear valid while disconnecting it from its evidence.

Before another system consumes an output or artifact, verify its type, producing action, current run state, evidence, and export readiness. Tool output and future MCP output should be treated as untrusted context rather than authority.

A completed run does not automatically make every output safe to publish or execute. Downstream use remains subject to permissions, policy, approvals, and the consumer’s own validation.

A downstream consumer should verify run state, artifact provenance, evidence, and output format before acting.

Export-ready or referenced material does not prove delivery to another product.

Keep the identifiers together with avoid treating model-generated output as trusted instruction.

Downstream consumers should verify provenance, state, evidence, output format, and persistence before acting. An item labeled export or artifact does not prove that another product received or trusted it.

Runs and actions can carry structured output.

The artifact and output review contract includes the fact that functional contracts can reference artifacts alongside steps, evidence, and proposed actions. Evidence forms include source data, screenshot, report, log, diff, export, and audit snapshot.

Universal artifact schemas, share links, storage locations, retention periods, deletion schedules, and delivery guarantees remain unverified.

Downstream systems should consume an explicit output or artifact reference, not infer one from a completed state. An output is the result value associated with a run or action. An artifact is a separately identifiable produced object when the contract creates one. Evidence supports a claim or review, an audit event records activity, and a receipt summarizes references; none of those objects automatically substitutes for another.

Before handing material to another process, check its producing run and action, current or terminal state, evidence relationship, and any export-readiness field that is actually present. The source bundle does not verify universal storage location, sharing, deletion, retention, or access-control guarantees. Persistence mode also matters: durable, local-file private-beta, memory-only, and unavailable records offer different operational expectations and should remain visible to the consumer.