Skip to content

flowgrid-orchestrator.boundary-model.md

Latest commit

 

History

History
83 lines (59 loc) · 3.62 KB

flowgrid-orchestrator.boundary-model.md

File metadata and controls

83 lines (59 loc) · 3.62 KB
Raw

MCP-Style Connector Registry Boundary Model

Purpose

This document closes public issue #3: Create an MCP-style connector registry map with identity, permission, and audit assumptions.

It provides concrete agentic-enterprise evidence for FlowGrid Orchestrator. The repo remains independent: it is not an AAIF project, not a Linux Foundation project, and not endorsed by either organization.

High-Risk Action Boundary

Connector execution that reads business data, writes to external systems, retries failed actions, or triggers AI-assisted routing.

Actors

Actor Responsibility
Workflow owner Defines workflow intent, allowed connectors, and approval requirements.
Operator Approves sensitive runs, retries, replays, and dead-letter recovery.
Connector runtime Executes scoped connector calls and emits audit events.
AI routing assistant Suggests routes or recovery steps but does not bypass connector permissions.

Identity Boundary

  • Each workflow run carries tenant, workflow, actor, and connector identity.
  • Connector credentials are referenced by secret name or provider binding, never by raw values in workflow definitions.
  • AI routing suggestions must resolve through the same connector permission model as human-authored workflows.

Tool And Action Boundary

Action Boundary
connector.discover Allowed to read connector metadata and declared capabilities.
connector.read Allowed only for declared sources and scoped tenant context.
connector.write Requires workflow policy and, for sensitive systems, operator approval.
connector.retry Allowed only with replay id, previous failure evidence, and retry limit.
connector.replay Requires operator approval and immutable reference to the original run.

Human Approval Gates

  • Before enabling a connector that writes to systems of record.
  • Before replaying or retrying a side-effecting workflow step.
  • Before promoting an AI-suggested route into an active workflow.
  • Before changing connector scopes, credentials, or tenant isolation rules.

Audit Event Model

Event Minimum Evidence
workflow.run_started tenant, workflow id, actor, version, trigger
connector.action_requested connector id, action, scope, side-effect class
operator.approval_recorded approver, action id, decision, timestamp
connector.action_completed status, duration, retry count, external reference
workflow.replay_requested original run id, requested by, reason, approval id

Local Proof Path

  • npm install to prove dependency resolution.
  • npm run lint for static validation.
  • npm run test for connector registry and workflow policy tests when present.
  • npm run build to prove the console compiles.
  • Static inspection of docs/AAIF_ALIGNMENT.md, agentic-readiness.json, and this boundary model when runtime dependencies are unavailable.

OSS And Self-Hosted Fallbacks

  • Evaluate Temporal or BullMQ for self-hosted workflow execution.
  • Use PostgreSQL for workflow metadata and audit events.
  • Use OpenTelemetry for trace propagation.
  • Keep n8n, hosted queues, and premium connector providers as adapters rather than hard requirements.

Contributor Follow-Up

Add a connector registry example that declares action type, side-effect class, required approval, and audit event names.

Issue Closure Evidence

This document satisfies the issue checklist by separating:

  • identity or actor boundary
  • tool/provider/action boundary
  • human approval or escalation point
  • audit or observability events
  • OSS/self-hosted fallback direction
  • validation and static inspection path