Skip to main content
An artifact is a recorded output of work. It may be a specification, code review link, report, brief, plan, or another durable work product created by a person, agent, or connected provider. An artifact record is not the same thing as the external content it references. It can tell you what OrgX recorded, where the source lives, what review state was recorded, and which evidence is available. It does not by itself prove that an external provider accepted, merged, deployed, published, or paid for the work.

​
What an artifact can contain

The fields depend on the surface that created it. Common fields include:
  • an identifier, title, type, and owning entity;
  • an internal or external source URL, and optionally a short preview;
  • a review or lifecycle status;
  • citations, evidence references, or execution receipts when available;
  • timestamps and integration metadata.
The canonical REST API v1 does not publish a general artifact operation. Use the MCP Tools Reference for model-facing artifact workflows and the compatibility guide only when maintaining an older workspace client.

​
Review states

When OrgX records artifact review state, the common statuses are: These are record states, not universal external delivery states. Use a provider receipt or external system record to confirm a merge, deployment, send, publication, payment, or other outcome.

​
Evidence and verification

Where the workflow provides them, review an artifact with:
  1. the source or linked work item;
  2. the concise public rationale and material findings;
  3. citations or evidence references;
  4. verification results and their scope;
  5. the requested decision and any external follow-up.
Verification is configured per workflow. A check can validate a schema, policy, source reference, or other acceptance condition, but a passed check is only evidence for that check. It is not a blanket claim that every artifact is correct or externally shipped.

​
Approval boundary

Approval records a human decision about the OrgX artifact or configured next step. It does not silently grant new provider permissions and it does not replace the provider’s own merge, deploy, send, publish, or payment result. For programmatic review, use the MCP decision flow described in Decisions. The canonical REST API v1 does not publish a general artifact-lifecycle write API.

​
Practical review checklist

Open the linked source or work item and confirm that it is the intended version. An OrgX record or URL is supporting context, not external proof.
Identify what the record shows, what the producer claims, and what an independent provider receipt confirms. Keep those states separate.
Before approving, check scope, destination, evidence, unresolved questions, and the exact next action. If the action leaves OrgX, confirm the external result separately.
Keep API keys, OAuth tokens, and raw provider transcripts out of artifacts. Redact sensitive data before sharing links.

​
Next steps

Decisions

Review approval and decision boundaries.

REST API compatibility

Maintain older workspace clients without treating compatibility routes as the current REST API v1 contract.