Coming soon · Contract draft

Automation & Policies

Planned

A governed automation contract with dry runs, approval gates, run history, failure explanation, and rollback evidence.

Reviewable specification — not callable

Documentation-first contract draft. The proposed additions on this page are not callable or available yet. Paths, payloads, scopes, names, and examples are intentionally concrete so customers can review the intended contract before and during implementation.

Canonical owner

Execute automation and AI policy services

Contract posture

P2 · Documentation first · implementation follows approval

Contract metadata

Draft version

0.2 review draft

Review owner

Delivery/Execute + Developer Platform

Last reviewed

July 14, 2026

Target wave

Wave 2–3 · Governed automation

Contract dependencies

• Canonical domain service adapter
• Optimistic concurrency and idempotency policy
• Transactional event outbox

What this unlocks

Manage rules as code

Read a stable domain model for automation & policies without depending on GUI routes or database shapes.

Preview automation impact

Create a reviewable proposal and apply only the bounded commands the canonical owner permits.

Explain failures and rollback

React to durable lifecycle facts and connect external systems with explicit direction and provenance.

Lifecycle and invariants

Automation & Policies exposes a bounded lifecycle with explicit commands and named authority at every transition.

drafttestingawaiting_approvalactivepausedfailedretired

From	To	Command	Authority
draft	testing	Run dry run	Automation policy service and target-domain services
testing	awaiting_approval	Request approval	Automation policy service and target-domain services
awaiting_approval	active	Approve automation	Automation policy service and target-domain services
active	paused	Pause automation	Automation policy service and target-domain services
paused	retired	Retire automation	Automation policy service and target-domain services

Lifecycle invariants

• Rules cannot exceed the approving principal’s authority.
• Every activation references a reviewed dry run.

Authority boundaries

The interfaces expose canonical capabilities; they do not become a second owner of domain rules or state.

DigitalStack owns

• Rule and policy definitions
• Approval and activation state
• Run, failure, and rollback history

Explicitly not building

• Broad execute-anything tools
• Rules bypassing domain authorization
• Activation without a reviewed dry run

Surface decisions

Deliberate additions, retained boundaries, and removals from the proposed external contract.

add

Rule/policy CRUD, dry run, approval, run history, failure, and rollback

Customers need observable governance around automation.

keep

Approval before activation and target-domain authorization

Automation must compose existing authority rather than create its own.

remove

Broad execute-anything tools and activation from an unreviewed draft

These would bypass domain contracts and human intent.

Interface plan

REST API

Planned

Versioned automation & policies resources, commands, idempotency, and operation status.

Reads + explicit commands

GraphQL

Planned

Composable AutomationRule reads with mutations delegated to the same canonical domain service.

Composable reads + bounded delegated mutations

MCP / Agent API

Planned

Bounded read, draft, and human-request tools with evidence and audit attribution.

Read + proposal/confirmed commands only

Webhooks

Planned

Past-tense automation lifecycle facts with minimal payloads.

Past-tense durable facts only

Connected Apps

Planned

Slack / Teams 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 /automations	automationRule(id: ID!): AutomationRule	get_automation_policies	—	Execute automation and AI policy services
Primary command	POST /automations	draftAutomationRuleChange(input: DraftAutomationRuleChangeInput!): AutomationRuleChangeProposal!	draft_automation_policies_change	automation.created	Execute automation and AI policy services

Proposed scopes

Proposed scopes are not grantable yet.

automations:readplanned scope

Read governed automation & policies resources.

automations:writeplanned scope

Create and edit bounded automation & policies fields.

automations:operateplanned scope

Run explicit automation & policies lifecycle commands.

Behavioral contract

Cross-cutting rules every implementation and interface must satisfy.

Canonical delegation

Every interface delegates to Execute automation and AI policy 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

Planned

GET/api/v1/automations

List automation & policies

Return an authorized, paginated collection with stable filters and provenance.

automations:read

POST/api/v1/automationsconfirmation

Create AutomationRule

Create one canonical resource with idempotency and actor attribution.

automations:write

GET/api/v1/automations/{id}

Retrieve AutomationRule

Return canonical detail, lifecycle state, permissions, and allowed actions.

automations:read

PATCH/api/v1/automations/{id}confirmation

Update AutomationRule

Update bounded editable fields using optimistic versioning.

automations:write

POST/api/v1/automations/{id}/approveconfirmation

approve AutomationRule

Run one explicit domain command after validation and authorization.

automations:operate

approve a AutomationRule

Planned request

curl --request POST \
+  --url https://www.digitalstack360.com/api/v1/automations/automation_123/approve \
+  --header "Authorization: Bearer $DSTACK_API_KEY" \
+  --header "Content-Type: application/json" \
+  --header "Idempotency-Key: automation-policies-approve-v2" \
+  --data '{
    "expected_version": 2,
    "reason": "Confirmed through the reviewed integration workflow"
  }'

Planned response

{
  "data": {
    "id": "automation_123",
    "status": "approved",
    "version": 3,
    "operation_id": "op_01k4..."
  }
}

GraphQL

Proposed graph

Planned

Types

AutomationRule

AutomationRuleConnection

AutomationRuleChangeProposal

Operation

Queries

automationRule(id: ID!): AutomationRule

automationRuleList(filter: AutomationRuleFilter, pagination: PaginationInput): AutomationRuleConnection!

Mutations

draftAutomationRuleChange(input: DraftAutomationRuleChangeInput!): AutomationRuleChangeProposal!

Planned GraphQL query

query AutomationRuleDetail($id: ID!) {
  automationRule(id: $id) {
    id
    status
    version
    updatedAt
    allowedActions { id label requiresConfirmation }
    source { kind externalId }
  }
}

MCP / Agent API

Proposed tools

Planned

Get Automation & Policies

get_automation_policies

Planned

Read the authorized automation & policies state, provenance, and allowed actions.

Scope: automations:read
Input: Resource id or a bounded filter.
Output: Canonical detail with source provenance and allowed actions.
Write boundary: Read only.

Draft Automation & Policies change

draft_automation_policies_change

Planned

Build a reviewable proposal from explicit user intent and DigitalStack evidence.

Scope: automations: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.

Request Automation & Policies action

request_automation_policies_action

Planned

Prepare an authorized human action request without executing the high-risk command.

Scope: automations:operate
Input: Proposal id, expected version, named decision maker, and reason.
Output: A pending human-action request and audit reference.
Write boundary: The agent cannot execute the final command.

Planned agent workflow

User: Review the proposed automation & policies change and help me apply it.

1. Call get_automation_policies to inspect current state, provenance, and allowed actions.
2. Call draft_automation_policies_change to create a proposal without changing canonical state.
3. Show validation results, conflicts, and the exact command to the user.
4. Call request_automation_policies_action so an authorized human can decide.

Never infer authority from access to the MCP client.

Webhooks

Proposed event catalog

Planned

Event types

automation.createdplanned event

A canonical AutomationRule was created.

payload: automation_id, status, created_at

automation.updatedplanned event

Governed AutomationRule fields changed.

payload: automation_id, changed_fields, version, occurred_at

automation.approvedplanned event

The approve command completed.

payload: automation_id, prior_status, status, occurred_at

Planned event example

{
  "event_id": "evt_01k4...",
  "type": "automation.approved",
  "event_version": 1,
  "occurred_at": "2026-07-16T14:22:04Z",
  "workspace_id": "ws_abc123",
  "resource": {
    "type": "automation",
    "id": "automation_123"
  },
  "actor": {
    "id": "user_123"
  },
  "payload": {
    "automation_id": "automation_123",
    "prior_status": "draft",
    "status": "approved"
  },
  "source": null
}

Connected Apps

Proposed connection roles

Planned

Claude / ChatGPT / IDE clients

Consumer application

Read, explain, and submit bounded automation & policies proposals through MCP.

Authority: Client access never implies domain approval or unrestricted mutation authority.

Slack / Teams

Action sink

Deliver approval requests and failure alerts.

Authority: Approval responses are bounded to one reviewed automation version.

Open contract decisions

Resolve before implementation approval

• Which rule changes invalidate an existing approval versus creating a patch version?

Proof obligations

Must remain true	Failure indicator
Execute automation and AI policy 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.