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 (temporary rich view) / 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
Five things are easy to conflate: what was said (conversation), what the platform tracked while work was running (runtime state), what business result was actually reached (execution result), what was certified as reusable proof (Evidence), and the technical trace of what executed underneath (operational/audit log — restricted, not a business record). The table below owns the first four; the operational/audit log is addressed separately, right after the table.
| 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.
Customer-facing Work and external AI result prose follows the task's admitted response language when available; a fallback is explicit. Technical keys and source content are not translated merely to make a presentation read naturally.
Operators read labels and state, not the operational/audit log: technical identifiers and Runtime Function internals stay in a restricted trace, available for investigation but never the business record of what happened. Output is not a dump of that trace.
How people find results
- Conversation / channels / external AI — daily home; governed outcome phrased for that surface.
- Review Workspace (Work) — temporary rich review when conversation cannot present the result safely.
- Assistants — operator evidence and trust across Role Assistants.
- From an approved external AI client, request the governed result for the same work — same meaning, not a privileged alternate path.
Assistants operators may list another person's task with worker:read, but viewing that task's bound Result or execution details additionally requires audit:read or worker-runtime-trace:read. An access-denied projection is not a partial Result. Work and external AI keep the signed-in task owner's Result boundary.
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.
A capability call that succeeds is not, by itself, completed work. When a governed action such as a CIP write reports success, that success is a reported mutation — not confirmation that the Task is complete. Process Execution Output only records the objective as done once status, timing, what actually changed, and any human questions raised during the work all agree; a successful system write that has not yet been confirmed, or that leaves an open question unanswered, keeps the Task in progress rather than complete.
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. A shared Task Execution detail surface and bounded Result projections are available, but specialized named-record, service, and document acceptance remains incomplete in the source lifecycle; do not infer blanket production readiness from a screen or an archived plan. Browser and accessibility follow-ups may remain. This page describes the boundary, not a screenshot of those screens, and does not require operators to read Runtime Function traces.