Unclassified

06 · Pipeline View

How Work moves through the system — Business Intent → Context Assembly → Work → Plan → Capability → Governance → Execution → Outcome → Verify → Spine. The most important technical/product view.

How Work Moves

This is one of the most important technical/product views.

Business Intent
      ↓
Context Assembly        (Spine → Projection → Active Context Bundle)
      ↓
Work                  (common unit, with objective + state)
      ↓
Plan                  (capability selection, sequencing)
      ↓
Capability Resolution (Capability Fabric: what can be done?)
      ↓
Governance            (may it be done? policy → verdict)
      ↓
Approval / Authority  (human or delegated, scoped)
      ↓
Execution             (Hermes: execute what has been authorized)
      ↓
Outcome               (external system response + evidence)
      ↓
Evidence
      ↓
Verification          (expected vs observed)
      ↓
Reconciliation        (resolve mismatch, decide what becomes truth)
      ↓
Spine / Memory / Projection
      ↓
Rehydrate             (Human Workbench + AI Workbench invalidate & refresh)
      ↓
Continue Work / Next Work

Execution is not closure. Provider success is not completion. The loop closes only after verify → reconcile → governed Spine update → rehydration.

Stage by Stage

The Spine projects a Business Context slice for the participant and Work. The UI and AI both hydrate from the **Active Context Bundle** (Business Context + Work + evidence + authority + continuity). No participant works from raw SaaS payloads.


Work carries objective, participants, state, and history. Agents take subtasks of Work, not free-floating tool calls. Handoffs transfer Work state and evidence, not transcripts.


The Capability Fabric resolves a provider-neutral capability to an available execution route (MCP, native, external). Availability is discovered and activated per tenant/runtime — see [Capability Fabric](/platform/capability-fabric-view) and [Discovery & Activation](/platform/discovery-activation-view).


Identity → Authority → Policy → Plan → Approval → Authorization → Evidence. Governance verdicts are durable and auditable. See [Governance & Authority](/platform/governance-authority-view).


Hermes executes only authorized plans. It does not decide authority. It returns outcome + evidence. See [Hermes Execution](/platform/hermes-execution-view).


Expected vs observed outcome, evidence capture, mismatch handling, and governed promotion to the Business Context Spine. Projection invalidation and workbench rehydration follow. See [Verification & Reconciliation](/closure/verification-reconciliation).

Separation That Matters

Capability Fabric          Governance                Hermes
 "What can be done?"  →  "May it be done?"  →  "Execute it."
       │                       │                      │
   ADK / MCP               Policy /               Provider
  resolution               Approval               execution

Hermes does not become an authority of its own.

What Answers Where

Question	Answer lives in
What exists / what is available?	Discovery & Activation
What can be done?	Capability Fabric
May it be done?	Governance
Execute it	Hermes
Did it become truth?	Verification & Reconciliation
How to see it?	Projection & Context Assembly

Where to Go Next

What happens when AI receives this Work.


The IntegrateWise runtime that runs this pipeline end-to-end.


The critical differentiator: why we don't close on provider success.

</CardGroup>