Where decisions land

Where decisions land

Business Summary: After you sign off at a checkpoint, approved decisions land in predictable places — inside the workstream, in connected systems, and in your organization's operating memory — so stakeholders can find outcomes without digging through chat.

When you approve a checkpoint, Nimbus commits the decision to one or more destinations depending on what the run proposed.

How this fits in Nimbus

Decision commits are the output of the HITL flow. Sign-off releases artifacts and approved writes; Nimbus records each destination in Outputs, Activity, and (when configured) external systems and audit views.

flowchart TB
  SO[Sign-off approved] --> Out[Outputs tab]
  SO --> Act[Activity timeline]
  SO --> Mile[Milestones]
  SO --> Ext[External systems]
  Out --> OM[Operating memory]
  Act --> OM
  Ext --> OM

Inside the workstream

Most committed decisions land first in the workstream workspace:

Destination What appears
Outputs Published reports, board artifacts, and structured deliverables
Activity Timeline entry with actor, timestamp, and decision trace link
Milestones Progress updates when the decision completes a gate
Chat Confirmation message and links to new artifacts

Outputs are the primary internal record — durable artifacts your team can reference without opening chat history.

See Workstream workspace and .

External systems (action connectors)

When a run included downstream write actions and you approved a Critical checkpoint, Nimbus executes the write after sign-off: CRM record updates, ERP or planning system commits, messaging or ticketing actions, and document storage uploads.

Activity may show Committed to with the target system name. Writes never execute without Critical approval when action connectors and governance are enabled.

See Intelligence vs Action connectors and Connector and export rules.

Operating memory

Committed decisions also feed your organization's operating memory — the durable graph of what happened and why: Lifecycle Graph (planned), Lifecycle Graph domain context, and Audit & History (partial today).

Per-workstream Activity is the most reliable view today; org-wide history is still rolling out.

Recurring plans

Roadmap: Recurring plan templates and scheduled re-runs from saved plans are not yet in the web app. When they ship, committed decisions from scheduled re-runs will follow the same landing pattern — Outputs first, then approved connector writes.

Example scenario

A revenue operations workstream runs a Plan mode agent to produce a pipeline health report and update CRM stages. You sign off on the Hard checkpoint; the report appears in Outputs and Activity shows "Report published." You and a second approver sign off on the Critical CRM write; Activity shows Committed to Salesforce and the CRM reflects the approved changes. Finance later pairs the Activity run ID with NTU usage on the billing dashboard.

What you'll see

What you'll see: After approval, a new row in Outputs, an Activity line such as "Report published" or "Committed to Workday," and optionally a connector status badge on the run timeline.

FAQs {#faqs}

Q: Does every approval push data externally? A: No. Many decisions commit only to Outputs inside Nimbus. External writes require action connectors and Critical sign-off.

Q: Can I see what evidence supported the decision? A: Yes. The decision trace in Activity links evidence, agents, and approvals. See Tracking committed decisions.

Q: I approved but nothing appeared in Outputs — why? A: The run may still be processing, or you approved a Soft checkpoint that only clarified intent. Check Activity for errors or pending stages.

Q: Where do wiki updates land? A: Wiki sync is separate from run commits. Connector-driven wiki content appears in Company Wiki. See Connectors and the Wiki.

Q: How do committed decisions relate to NTU billing? A: NTU usage is recorded when the run executes, not when you commit the decision. See Where NTUs appear.

Q: Can committed outputs be shared outside the workstream team? A: Access follows workstream team and org tier rules. Viewers on the team can read Outputs; guests typically cannot access restricted workstreams.