GovOPlaN/govoplan-core
1
0
Fork 0
Code Issues 44 Pull Requests Actions Packages Projects Releases Wiki Activity
Page: Repo docs AUTOMATION CONTRACTS
Pages
Codex Project Index Product govoplan split concept action plan Repo-README Repo README Repo docs ACCESS RBAC MODEL Repo docs ACTION EFFECT AUTOMATION LAYER Repo docs AUTOMATION CONTRACTS Repo docs CODEX WORKFLOW Repo docs CONFIGURATION PACKAGES Repo-docs-DEPENDENCY-AUDITS Repo docs DEPENDENCY AUDITS Repo docs DEPLOYMENT OPERATOR GUIDE Repo-docs-DOCUMENTATION-MAP Repo docs DOCUMENTATION MAP Repo docs EVENTS AND AUDIT Repo docs GITEA ISSUES Repo docs GOVERNANCE MODEL Repo docs GOVOPLAN MASTER ROADMAP Repo docs INTERFACE ETHICS AND DESIGN DOCTRINE Repo-docs-MODULE-ARCHITECTURE Repo docs MODULE ARCHITECTURE Repo docs POLICY CONTRACTS Repo docs POSTBOX E2EE ARCHITECTURE Repo docs PUBLIC SECTOR INTEGRATION STRATEGY Repo-docs-RELEASE-DEPENDENCIES Repo docs RELEASE DEPENDENCIES Repo docs REMOTE WEBUI BUNDLES Repo docs SECURITY AUDIT Repo docs SELF HOSTED INSTALLABILITY Repo docs THROTTLING Repo docs UI UX DECISION LEDGER Repo-docs-audits-2026-07-09-dependency-audit Repo docs audits 2026 07 09 dependency audit
Clone
1
Repo docs AUTOMATION CONTRACTS
Albrecht Degering edited this page 2026-07-28 15:08:25 +02:00
Table of Contents

Mirrored from /mnt/DATA/git/govoplan-core/docs/AUTOMATION_CONTRACTS.md. Origin: repository. Active tasks and changing state belong in Gitea issues; this wiki page is durable project context.

Automation Contracts

Core defines provider-neutral automation contracts. It does not own domain schedules, Workflow graphs, or Dataflow execution.

Invocation Envelope

AutomationInvocation classifies a start as manual, api, schedule, event, workflow, dependency, retry, or backfill. It carries opaque trigger and delivery references, event identity, correlation and causation IDs, scheduled time, requesting actor, and bounded metadata. Domain runs store this envelope with their immutable definition revision.

Current Authorization

An automated trigger must not persist a user session, bearer token, API key, or a snapshot of all current permissions. It stores:

  • tenant, account, and membership IDs;
  • an opaque authorization reference;
  • the minimum scopes required by the pinned definition and output target.

At delivery time the optional auth.automationPrincipalProvider capability resolves current account, membership, role, group, function, and delegation state. It intersects current authorization with the stored grant. Missing, inactive, or reduced authorization blocks the delivery before effects occur.

Definition Governance

The optional policy.definitionGovernance capability evaluates view, edit, run, reuse, derive, and automate for system, tenant, group, and user definitions. A decision contains an ordered source path and effective limits. Derived definitions pin their source revision and hash and retain ancestor ceilings. Templates are reusable definitions and cannot run on their own.

Without Policy, domain modules use a conservative tenant-local fallback: local definitions remain viewable/editable and active complete flows may run; inheritance, reuse, derivation, and automation are unavailable.

Delivery Durability

Domain trigger implementations persist idempotent deliveries before running. The existing PlatformEvent bus is process-local and is not a durable automation source. A transactional Core event/outbox bridge is still required to guarantee capture across commits, restarts, and multiple workers. Until that bridge exists, direct event ingestion must be authenticated, tenant scoped, and limited to public or internal event envelopes.