Documentation Index

Fetch the complete documentation index at: https://docs.aifabrix.ai/llms.txt

Use this file to discover all available pages before exploring further.

Process Execution Output

Prev Next

Purpose

Process Execution Output is the validated business result of a Process Execution. It is the architecture source of truth for what governed work achieved — not chat history, not a UI-only summary, and not a raw dump of every Runtime Function.

Process Execution → Process Execution Output → Conversation / Review Workspace / Assistants / external AI presentation

Operators and employees see a business result. Architecture keeps that result honest by validating Output before any surface projects it.

What this shows / What this is not

What this shows: How admitted intent becomes a Process Execution, how Output records the business outcome, and how conversation channels, temporary Review Workspace, and external AI present that outcome without inventing enterprise facts.

What this is not: A second interaction model, a replacement for Evidence Fabrix articles, a predefined workflow engine, or permission to treat conversation memory as Reality.

Boundary

Layer Owns
Process Execution Stateful carrier of the business objective through Runtime decisions
Process Execution Output Validated business result (objective, measurements, contributions, outcome honesty)
Presentation User-safe projection for channels, Review Workspace, and Enterprise MCP — phrasing and depth, not a second truth
Evidence Certified reusable business-significant proof when validate→certify applies — not every Output field

Presentation may summarize or emphasize fields for a role. It must not invent outcomes, change deny/fail honesty, or replace Output with client memory.

How people find results

  1. Conversation / channels / external AI — daily home; governed outcome phrased for that surface.
  2. Review Workspace (Work) — temporary rich review when conversation cannot present the result safely.
  3. Assistants — operator evidence and trust across Role Assistants.
  4. From an approved external AI client, request the governed result for the same work — same meaning, not a privileged alternate path.

Human responses feed the Process Execution. An Approval accepts or rejects a proposed business change (including Evidence certification when that is the task); it does not invent Reality. An Ask answer that only fuels this execution is not certified Evidence. See Role Assistant Runtime and Conversation-first work.

Relationship to CIP and sync

CIP executes Connected System operations under capability governance. Sync, webhooks, and sync bridge supply governed information products according to information type: current authoritative business facts refresh Enterprise Reality, while reusable organisational understanding may refresh Enterprise Knowledge after the applicable validation. Process Execution Output records what this governed work proved after Runtime decisions — it is not a substitute for CIP logs or sync job status.

For CIP authoring, see Configure data flow. For business-facing result language, see Business value from work steps.

Architecture value

Keeping Output as a validated artifact lets every surface share one meaning of success, failure, denial, wait, and safe stop. That prevents chat clients from becoming a parallel system of record and keeps audit review aligned with what the Runtime actually completed.

Limits

Available result fields and presentation depth vary by deployment and Role Assistant. Expected contribution on Output is not the same as fully attributed realized business impact. This page describes the boundary; it does not publish internal schema filenames or require operators to read Runtime Function traces.