Runs, receipts, and artifacts
Distinguish runs, receipts, artifacts, evidence, states, auditability, and retention while preserving current implementation boundaries.
Runs, receipts, and artifacts
Runs, receipts, and artifacts describe different parts of a task history. Use this page when reviewing whether an action was attempted, what evidence was recorded, and which output should be preserved. Ethen’s approved language supports visible work, evidence, receipts, request history, route decisions, logs, tool outputs, and verification notes, while exact run states and retention periods remain outside the Batch 01 evidence.
Runs
A run is one attempt to perform a supported task. It may be a direct model request, a stage in a workflow, or an agent-oriented operation, depending on the owning product. A run should be bounded by an objective, context, selected resources, and an observable outcome.
A useful run record answers:
- What task was attempted?
- Which model, provider, or route was selected?
- What context was supplied or referenced?
- Did the task remain read-only, produce a proposal, receive approval, or execute?
- What status or error ended the attempt?
- Which receipts, artifacts, logs, outputs, or notes were produced?
One task can have multiple runs. Retrying after a missing key, switching models, changing context, or revising a prompt should create a new attempt rather than silently rewriting the history of the earlier one.
A run is the bounded occurrence of supported work, such as a model request or workflow attempt. This is a conceptual definition for cross-page consistency, not a verified universal runtime object.
The sources do not establish run IDs, state enums, queues, retries, cancellation, or persistence. Product-specific documentation must provide those details.
States
The Batch 01 sources do not define one canonical run state machine. Do not publish exact state names such as queued, running, paused, succeeded, failed, or cancelled unless the product-specific implementation supplies them.
A documentation-safe state model is descriptive rather than normative:
| Descriptive condition | Meaning |
|---|---|
| Prepared | Goal, context, and selected resources are ready |
| Blocked before execution | Configuration, credential, modality, permission, or approval prevents the task |
| Response produced | A model or surface returned an output |
| Proposal awaiting review | Candidate work exists but has not been authorized |
| Execution attempted | A supported state-changing operation was called |
| Outcome verified | Evidence from the owning or target system confirms the result |
| Outcome unresolved | Available evidence cannot establish completion |
These phrases help readers reason about a task without pretending they are stored runtime values.
The platform uses several status vocabularies, including product maturity, workspace state, model runtime status, and possible proposal or execution stages.
Do not merge them. A preview product can display a runnable model; a catalog-only model can appear inside a GA-labeled documentation record. The relevant state must be named explicitly.
Receipts
A receipt is an inspectable record intended to summarize a request, route, action, or result. It is evidence about an event, not the event itself.
Depending on the product, a receipt may include request history, referenced context, a route decision, selected model and provider, logs, tool outputs, status, or verification notes. Batch 01 does not define a universal receipt schema, so documentation should name only fields visible in the owning surface.
A strong receipt supports traceability:
- It identifies the attempt.
- It preserves the selected path.
- It records the stage reached in the control model.
- It points to relevant evidence.
- It distinguishes confirmed facts from unresolved claims.
A receipt should not be used to claim success when the target system has not confirmed the effect. It may show that Ethen sent a request or received a response while leaving the external outcome unverified.
Receipts are intended to keep inspectable information about how work was produced, including request history, route choices, logs, tool outputs, or verification notes where the surface supports them.
A receipt supports review but is not automatically an immutable audit record. Do not claim a storage duration, legal effect, or completeness guarantee.
Artifacts
An artifact is a useful output preserved from work. Examples can include generated text, code, a comparison, a report, a media result, a proposed workflow, or another saved deliverable where the product supports it.
Artifacts differ from receipts:
- the artifact is the work product;
- the receipt explains the request or action that produced or handled it.
An artifact can be valuable even when execution never occurs. A proposed change, research brief, or model-selection record can be reviewed and approved later. Conversely, a run can complete without producing a durable artifact if the result is only a transient response or status.
When handing off an artifact, include enough context to interpret it: task objective, selected model or product, relevant sources, date, limitations, and whether it is a draft, proposal, or verified result.
An artifact is a visible work product that can be kept separate from the immediate interaction, such as a draft, analysis, or structured output. The shell recognizes an artifacts route.
The batch does not define artifact types, versioning, export, ownership, permissions, or retention. Use the term carefully and avoid equating every model response with a persisted artifact.
Artifact status
Label an artifact according to what has happened: draft, proposal, reviewed output, approved material, or verified result where the evidence supports those descriptions. Avoid using “final” when the underlying action or source review remains incomplete.
When an artifact is revised, preserve the reason for the change and the run or session that produced it. A clean final document is useful, but the decision trail explains which evidence was accepted and which earlier assumptions were rejected.
Auditability
Auditability means a reviewer can reconstruct the important parts of a decision or action from available evidence. It does not automatically imply a formal compliance standard or immutable audit log.
A review path can combine:
- the workspace or project identity;
- the session or run being examined;
- prompts, files, and context references;
- model, provider, capability, and status;
- route decisions or selection rationale;
- approval evidence;
- receipts, logs, and tool outputs;
- resulting artifacts;
- verification notes and unresolved questions.
No single item is sufficient for every task. A model ID without the prompt cannot explain a response. An artifact without source notes cannot establish provenance. An approval without execution evidence cannot prove completion.
When data is missing, preserve the gap. Auditability is improved by an honest “not recorded” more than by a reconstructed detail presented as fact.
Auditability means a reviewer can reconstruct enough of the path to understand what was requested, what context and model lane were used, what was proposed, and what result was produced.
The current product surfaces support the goal of visible work and receipts but do not establish immutable logs, access controls, or compliance evidence. Those claims require operations and security sources.
Reconstructing a decision
A decision review should be possible without relying on memory. Start with the artifact or final result and work backward: identify the run, receipt, selected model and provider, route or status, context sources, approval evidence, and any tool output. Then compare the reconstructed path with the original objective.
If a link is missing, label the gap. For example, an artifact may have source notes but no route decision, or a receipt may identify the model without preserving the exact context. The gap limits what can be concluded, but it does not make the remaining evidence useless.
Naming and identity
Use stable identifiers where the product exposes them. A run label should not be mistaken for a session name, and an artifact title should not replace the model ID or receipt reference. When an item lacks a verified identifier, describe it by route, date, task, and visible status rather than inventing one.
This discipline is especially important when similar tasks are retried. The second output may be better, but the first attempt remains part of the history and can explain why the prompt, model, provider, or approval changed.
Evidence quality by task type
A research run benefits from source files, profile quality flags, and a comparison record. A Gateway run benefits from model ID, provider, status, and response evidence. A tool-assisted run needs the proposal, approval, call result, and target verification. An artifact handoff needs provenance and limitations.
No universal receipt schema is established here. The expected evidence should therefore be derived from the task’s risk and the owning product rather than from a generic checklist.
Handling an unresolved outcome
An unresolved run is not necessarily a failed run. The system may have accepted a request while the external result remains unknown, or it may have produced a useful artifact without executing the proposed action. Record the confirmed stage and the missing evidence.
Do not overwrite an unresolved outcome with a later success. Link the later attempt as a separate run so reviewers can see the recovery path and determine whether duplicate effects were possible.
Retention
The current sources do not establish how long runs, receipts, artifacts, sessions, logs, or context are retained. Interface visibility is not a retention policy, and a shell route named audit log does not prove immutable or long-term storage.
Do not state deletion guarantees, backup behavior, archival periods, legal holds, geographic storage, or recovery commitments from this concepts page. Those claims require verified product and policy evidence.
Until retention is documented by the owning source:
- keep essential project records in the approved system of record for the team;
- avoid assuming Ethen history is permanent;
- do not upload material solely because it appears removable in the interface;
- preserve critical source references with the artifact;
- treat exports or copies as separate records with their own access and lifecycle.
This page remains a draft because exact state and retention models belong to later implementation and policy review. Its purpose is to prevent runs, receipts, artifacts, and audit evidence from being used as interchangeable terms.
No retention period is verified for runs, receipts, artifacts, sessions, or evidence in this batch.
Do not state that records persist indefinitely or are deleted on a schedule. Use current legal and product policy sources when retention documentation is available, and keep this section as an explicit limitation until then.