Skip to content

Workflows

Target Architecture — Final-State Design

This page describes the final-state Factory Studio workflows. They build on the implemented Blazor MFE shell, SignalR real-time stack, and OpenIddict auth; the review engine (ReviewCenterService) and its aggregates are the designed end state.

The Factory Studio is where human authority enters an otherwise autonomous factory. Its two defining workflows are the human review lifecycle — the governed loop that lets a person approve, reject, escalate, or override agent output — and the dashboard refresh flow that keeps the command center live. Both are designed so that human judgement is a first-class, audited control action that never silently forks factory truth.

Human review workflow

When a factory workflow reaches a point that requires human judgement — a generated artifact, a risky decision, a policy-gated promotion — the owning platform raises a review. The Studio's ReviewCenterService owns the ReviewRequest and ReviewDecision aggregates that drive this lifecycle, and emits the human-authority events the Control Plane and Agent Mesh consume to proceed.

Review request lifecycle

stateDiagram-v2
    [*] --> Pending : ReviewRequested
    Pending --> InReview : ReviewClaimed
    InReview --> Approved : ReviewApproved
    InReview --> Rejected : ReviewRejected
    InReview --> ChangesRequested : ChangesRequested
    InReview --> Escalated : ReviewEscalated
    Pending --> Escalated : Sla breached
    Escalated --> InReview : ReviewClaimed
    Escalated --> Overridden : AgentDecisionOverridden
    ChangesRequested --> Pending : Revision submitted
    Approved --> [*]
    Rejected --> [*]
    Overridden --> [*]
    Pending --> Expired : Sla expired no action
    Expired --> [*]
Hold "Alt" / "Option" to enable pan & zoom
State Meaning Entered by
Pending A review is queued and awaiting a reviewer to claim it. ReviewRequested from a source platform
InReview A reviewer has claimed the item and is evaluating the subject. ReviewClaimed
Approved The subject is accepted; the factory may proceed. ReviewApproved
Rejected The subject is rejected; the factory must rework or abandon. ReviewRejected
ChangesRequested Conditional accept — specific changes required before re-review. ChangesRequested
Escalated Raised to a higher authority (Approver) due to risk, SLA breach, or reviewer request. ReviewEscalated
Overridden A human with override authority forced a decision against the agent's recommendation. AgentDecisionOverridden
Expired SLA elapsed with no decision; routed per escalation policy. SLA timer

Approval, rejection, escalation, and override

  • Approval. A reviewer with authority over the subject's project records a ReviewDecision of Approved, optionally with conditions. The service emits ReviewApproved; the Control Plane unblocks the gated workflow step.
  • Rejection. A Rejected decision emits ReviewRejected with a mandatory rationale; the Agent Mesh receives it as feedback and the originating task is reworked or abandoned.
  • Changes requested. A conditional decision (ChangesRequested) returns the subject to the producer with specific, structured change items; on revision the request re-enters Pending.
  • Escalation. Any reviewer can escalate, and unattended items auto-escalate on SLA breach. Escalation re-targets the request to the Approver role and raises a high-priority notification. Escalation preserves the full traceId and review history.
  • Human override. An Approver or Platform Administrator may override an agent's recommendation (or a prior decision) when business judgement supersedes the autonomous choice. Override is the most privileged action: it requires elevated RBAC, a mandatory rationale, and emits AgentDecisionOverridden, which is always audited to Governance. Overrides are surfaced back to the Knowledge Platform so the factory learns where human judgement diverged from agent reasoning.

All four outcomes are recorded as immutable ReviewDecision events in the canonical envelope, keeping the human-in-the-loop fully traceable.

Review sequence

sequenceDiagram
    participant CP as Control Plane
    participant RTG as StudioRealtimeGateway
    participant RC as ReviewCenterService
    participant MFE as Review Center MFE
    participant Reviewer as Reviewer
    participant GOV as Governance

    CP->>RC: ReviewRequested (subject, traceId)
    RC->>RC: Create ReviewRequest (Pending)
    RC->>RTG: ReviewQueueChanged
    RTG-->>MFE: push ReviewQueueChanged
    Reviewer->>MFE: Open review detail
    MFE->>RC: POST /reviews/{id}/claim
    RC->>RC: Transition to InReview (ReviewClaimed)
    Reviewer->>MFE: Inspect artifact preview + lineage
    Reviewer->>MFE: Submit decision (Approved + rationale)
    MFE->>RC: POST /reviews/{id}/decisions (Idempotency-Key)
    RC->>RC: Record ReviewDecision (immutable)
    RC->>GOV: Audit ReviewApproved
    RC->>CP: ReviewApproved (unblock step)
    RC->>RTG: ReviewQueueChanged
    RTG-->>MFE: push update (item resolved)
Hold "Alt" / "Option" to enable pan & zoom

Escalation and override path

sequenceDiagram
    participant RC as ReviewCenterService
    participant RTG as StudioRealtimeGateway
    participant Reviewer as Reviewer
    participant Approver as Approver
    participant GOV as Governance
    participant AM as Agent Mesh

    Reviewer->>RC: Escalate (rationale)
    RC->>RC: Transition to Escalated (ReviewEscalated)
    RC->>RTG: high-priority NotificationReceived
    RTG-->>Approver: push escalation notification
    Approver->>RC: Claim escalated review
    Approver->>RC: Override decision (elevated RBAC, rationale)
    RC->>GOV: Audit AgentDecisionOverridden
    RC->>AM: AgentDecisionOverridden (redirect/abandon task)
    RC->>RC: Transition to Overridden
Hold "Alt" / "Option" to enable pan & zoom

Dashboard refresh flow

The command center stays live through an event-driven refresh with interval fallback, balancing freshness against load on the source platforms.

sequenceDiagram
    participant Bus as Azure Service Bus
    participant RTG as StudioRealtimeGateway
    participant Dash as DashboardAggregationService
    participant Redis as Redis
    participant MFE as Dashboard MFE

    MFE->>Dash: GET dashboard view (first load)
    Dash->>Redis: Lookup cached DashboardView
    alt Cache miss or stale
        Dash->>Dash: Aggregate Control Plane + Observability
        Dash->>Redis: Store view (TTL + version)
    end
    Dash-->>MFE: DashboardView read model
    MFE->>RTG: Join tenant:project group
    Bus->>RTG: AgentTaskCompleted / RuntimeSignalRaised
    RTG->>Redis: Invalidate affected view keys
    RTG-->>MFE: push DashboardTileUpdated (traceId)
    MFE->>Dash: Refetch changed tile only
    Dash-->>MFE: patched tile
    Note over MFE: Fallback timer refetches if no event within interval
Hold "Alt" / "Option" to enable pan & zoom
  • Event-driven primary. Relevant factory events invalidate the affected cached tiles in Redis and push a targeted DashboardTileUpdated over SignalR; the client refetches only what changed.
  • Interval fallback. Each dashboard carries a refreshPolicy with a fallback interval (default 30s) so a missed event still self-heals.
  • Tenant- and role-scoped. Refresh signals are only delivered to authorized SignalR groups, so a tenant never sees another tenant's change.
  • Staleness honesty. When a source platform is slow or degraded, the view is served from cache and flagged stale rather than blocking the page, consistent with the BFF degradation pattern.

Saved views and workspace

User-curated dashboards, graph explorations, and filter sets are persisted as SavedView aggregates within a UserWorkspace, so an operator returns to exactly the cockpit configuration they left — per user, per tenant.