Coming soon · Contract draft
Artifacts, Diagrams & Files
A project artifact contract for canvas assets, diagrams, architecture views, files, versions, exports, and share lifecycle.
Reviewable specification — not callable
Canonical owner
Artifact, diagram, asset, version, export, and sharing services
Contract posture
P3 · Documentation first · implementation follows approval
Contract metadata
Draft version
0.2 review draft
Review owner
Commercial/Knowledge + Developer Platform
Last reviewed
July 14, 2026
Target wave
Wave 6 · Knowledge and intake
Contract dependencies
- • Canonical identity and provider mapping policy
- • Field-level visibility rules
- • Transactional event outbox
What this unlocks
Index project artifacts
Read a stable domain model for artifacts, diagrams & files without depending on GUI routes or database shapes.
Version diagrams and files
Create a reviewable proposal and apply only the bounded commands the canonical owner permits.
Publish and export safely
React to durable lifecycle facts and connect external systems with explicit direction and provenance.
Lifecycle and invariants
Artifacts, Diagrams & Files exposes a bounded lifecycle with explicit commands and named authority at every transition.
draftreviewpublishedsharedarchived| From | To | Command | Authority |
|---|---|---|---|
| draft | review | Request review | Artifact, diagram, and sharing services |
| review | published | Publish artifact | Artifact, diagram, and sharing services |
| published | shared | Create governed share | Artifact, diagram, and sharing services |
| shared | archived | Archive artifact | Artifact, diagram, and sharing services |
Lifecycle invariants
- • Artifact versions are immutable once published.
- • Diagram coordinates never become domain truth.
Authority boundaries
The interfaces expose canonical capabilities; they do not become a second owner of domain rules or state.
DigitalStack owns
- • Artifact metadata and project linkage
- • Version and publication lifecycle
- • Export and governed share state
Explicitly not building
- • Share links as ordinary resource IDs
- • Diagram coordinates as domain truth
- • External files overwriting canonical versions silently
Surface decisions
Deliberate additions, retained boundaries, and removals from the proposed external contract.
Metadata, versions, import/export Operations, publication, and governed share lifecycle
Integrations need stable artifact identity without exposing storage internals.
Provider mapping and project linkage separate from the artifact version
Files can move between providers without changing canonical identity.
Share links as ordinary IDs and external overwrite of published versions
Both weaken capability security and version integrity.
Interface plan
REST API
PlannedVersioned artifacts, diagrams & files resources, commands, idempotency, and operation status.
Reads + explicit commands
GraphQL
PlannedComposable Artifact reads with mutations delegated to the same canonical domain service.
Composable reads + bounded delegated mutations
MCP / Agent API
PlannedBounded read, draft, and confirmed apply tools with evidence and audit attribution.
Read + proposal/confirmed commands only
Webhooks
PlannedPast-tense artifact lifecycle facts with minimal payloads.
Past-tense durable facts only
Connected Apps
PlannedFigma / Drive / Box / SharePoint plus consumer clients, with declared direction and authority.
Declared direction and field authority required
Cross-interface parity
Each surface delegates to the named canonical owner; a blank surface is an intentional denial of authority, not missing documentation.
| Capability | REST | GraphQL | MCP | Webhook | Canonical owner |
|---|---|---|---|---|---|
| Primary read | GET /artifacts | artifact(id: ID!): Artifact | get_artifacts_diagrams | — | Artifact, diagram, asset, version, export, and sharing services |
| Primary command | POST /artifacts | draftArtifactChange(input: DraftArtifactChangeInput!): ArtifactChangeProposal! | draft_artifacts_diagrams_change | artifact.created | Artifact, diagram, asset, version, export, and sharing services |
Proposed scopes
Proposed scopes are not grantable yet.
artifacts:readplanned scopeartifacts:writeplanned scopeartifacts:operateplanned scopeBehavioral contract
Cross-cutting rules every implementation and interface must satisfy.
Canonical delegation
Every interface delegates to Artifact, diagram, asset, version, export, and sharing services; no resolver, gateway, worker, or connector reimplements domain rules.
Least-privilege principals
Scopes are evaluated with tenant, role, field-visibility, and principal-type constraints before data is read or changed.
Safe writes
Mutations use explicit confirmation where required, optimistic concurrency, idempotency, and durable actor attribution.
Transactional facts
Webhook facts are emitted from the canonical commit path, versioned, minimal, and safe to redeliver.
Declared provider authority
Every Connected App declares direction, field authority, provenance, and conflict behavior before activation.
REST API
Proposed endpoints
/api/v1/artifactsList artifacts, diagrams & files
Return an authorized, paginated collection with stable filters and provenance.
artifacts:read
/api/v1/artifactsconfirmationCreate Artifact
Create one canonical resource with idempotency and actor attribution.
artifacts:write
/api/v1/artifacts/{id}Retrieve Artifact
Return canonical detail, lifecycle state, permissions, and allowed actions.
artifacts:read
/api/v1/artifacts/{id}confirmationUpdate Artifact
Update bounded editable fields using optimistic versioning.
artifacts:write
/api/v1/artifacts/{id}/publishconfirmationpublish Artifact
Run one explicit domain command after validation and authorization.
artifacts:operate
publish a Artifact
curl --request POST \
+ --url https://www.digitalstack360.com/api/v1/artifacts/artifact_123/publish \
+ --header "Authorization: Bearer $DSTACK_API_KEY" \
+ --header "Content-Type: application/json" \
+ --header "Idempotency-Key: artifacts-diagrams-publish-v2" \
+ --data '{
"expected_version": 2,
"reason": "Confirmed through the reviewed integration workflow"
}'{
"data": {
"id": "artifact_123",
"status": "published",
"version": 3,
"operation_id": "op_01k4..."
}
}GraphQL
Proposed graph
Types
ArtifactArtifactConnectionArtifactChangeProposalOperationQueries
artifact(id: ID!): ArtifactartifactList(filter: ArtifactFilter, pagination: PaginationInput): ArtifactConnection!Mutations
draftArtifactChange(input: DraftArtifactChangeInput!): ArtifactChangeProposal!applyArtifactChange(input: ApplyArtifactChangeInput!): ArtifactPayload!query ArtifactDetail($id: ID!) {
artifact(id: $id) {
id
status
version
updatedAt
allowedActions { id label requiresConfirmation }
source { kind externalId }
}
}MCP / Agent API
Proposed tools
Get Artifacts, Diagrams & Files
get_artifacts_diagramsRead the authorized artifacts, diagrams & files state, provenance, and allowed actions.
- Scope
- artifacts:read
- Input
- Resource id or a bounded filter.
- Output
- Canonical detail with source provenance and allowed actions.
- Write boundary
- Read only.
Draft Artifacts, Diagrams & Files change
draft_artifacts_diagrams_changeBuild a reviewable proposal from explicit user intent and DigitalStack evidence.
- Scope
- artifacts:write
- Input
- Target, requested outcome, expected version, and optional evidence references.
- Output
- A persisted proposal, validation results, and conflicts.
- Write boundary
- Creates a proposal; it does not mutate canonical state.
Apply Artifacts, Diagrams & Files change
apply_artifacts_diagrams_changeApply a reviewed proposal through the canonical service.
- Scope
- artifacts:operate
- Input
- Proposal id, expected version, idempotency key, and explicit confirmation.
- Output
- Updated canonical resource and audit reference.
- Write boundary
- Confirmation, optimistic versioning, and idempotency required.
User: Review the proposed artifacts, diagrams & files change and help me apply it.
1. Call get_artifacts_diagrams to inspect current state, provenance, and allowed actions.
2. Call draft_artifacts_diagrams_change to create a proposal without changing canonical state.
3. Show validation results, conflicts, and the exact command to the user.
4. After explicit confirmation, call apply_artifacts_diagrams_change with the proposal version.
Never infer authority from access to the MCP client.Webhooks
Proposed event catalog
Event types
artifact.createdplanned eventA canonical Artifact was created.
payload: artifact_id, status, created_at
artifact.updatedplanned eventGoverned Artifact fields changed.
payload: artifact_id, changed_fields, version, occurred_at
artifact.publishedplanned eventThe publish command completed.
payload: artifact_id, prior_status, status, occurred_at
{
"event_id": "evt_01k4...",
"type": "artifact.published",
"event_version": 1,
"occurred_at": "2026-07-16T14:22:04Z",
"workspace_id": "ws_abc123",
"resource": {
"type": "artifact",
"id": "artifact_123"
},
"actor": {
"id": "user_123"
},
"payload": {
"artifact_id": "artifact_123",
"prior_status": "draft",
"status": "published"
},
"source": null
}Connected Apps
Proposed connection roles
Claude / ChatGPT / IDE clients
Consumer application
Read, explain, and submit bounded artifacts, diagrams & files proposals through MCP.
Authority: Client access never implies domain approval or unrestricted mutation authority.
Figma / Drive / Box / SharePoint
Synchronization provider
Import, export, or link governed artifacts.
Authority: Direction, version mapping, and share policy are explicit per connection.
Open contract decisions
Resolve before implementation approval
- • Which artifact formats support round-trip editing versus import/export only?
Proof obligations
| Must remain true | Failure indicator |
|---|---|
| Artifact, diagram, asset, version, export, and sharing services remains the singular canonical owner. | An interface or connector persists a second authoritative lifecycle state. |
| Draft and apply remain separate actions. | An agent or integration silently converts inferred intent into a canonical mutation. |
| Every write is attributable, versioned, and idempotent. | A retry duplicates work or stale state overwrites a newer human decision. |
| Connected App direction and field authority are explicit. | Provider data silently becomes canonical or conflicts are resolved without policy. |