Getting Started Guide

Turn the events already produced by your workflow into trusted operational evidence, then verify one complete case path before expanding.

By the end, you will have:

  • A deliberately selected Workspace and verifiable identities
  • One bounded Workstream with states, participants, and interactions
  • A signed test transaction correlated into a visible case path
  • A foundation for operational visibility, AI adoption, and measurable business impact
1

What Operon.Cloud Measures

Operon.Cloud turns observed workflow events into a verifiable operational record. It shows where work is, how it moves, who or what participated, and what changed.

Operational flow

  • Cycle time and time spent waiting in states/queues
  • Bottlenecks, rework loops, and SLA performance
  • Participant and resource attribution
  • AI and automation adoption within real workflows
  • Value Metrics that connect workflow changes to operational or financial impact
Start with one workflow whose events and desired operating outcome are already understood. A small end-to-end signal is more useful than a broad, incomplete model.
2

Platform Model

These building blocks connect a business process to its trusted event record.

Workspace
The top-level operational boundary. Choose Internal, Production, or the specialized RAED type deliberately because the selected type is permanent.
DID
A verifiable identity for an Organization, System, API Client, or Person.
Workstream
A defined business process within a Workspace.
State or queue
Where a case currently sits within the Workstream.
Participant
The actor, system, or operational role associated with workflow activity.
Interaction
A named Touch or Movement event. A Touch records work within a state; a Movement records a transition between states.
Transaction
A signed, immutable record of one observed interaction.
Case
The correlated sequence of transactions that share one stable correlation ID within a Workstream.
Value Metric
Optional business-value metadata associated with an interaction or submitted transaction.
3

Choose a Workspace

Open Workspaces, then select an existing Workspace or create one for the operational boundary you want to measure.

Standard setup

  1. Choose Internal or Production based on the intended use.
  2. Confirm the type before saving because it cannot be changed later.
  3. Select one bounded workflow instead of modeling the entire organization at once.

RAED workspaces

For a RAED Workspace, use LOB Sync to create and maintain the line-of-business Workstreams. Do not use the ordinary manual Workstream setup path for a RAED Workspace.

Keep the boundary clear: RAED synchronization is a specialized path. The remaining steps in this guide describe the standard Operon.Cloud setup unless noted otherwise.
4

Create DIDs

Open DIDs and choose Create DID for every identity that must participate in or verify the first workflow.

OrganizationSystemAPI ClientPerson

Service-to-service integrations normally use an API Client or System DID. Use a Person DID when a human action needs verifiable attribution, and an Organization DID for the accountable organizational identity.

5

Configure a Workstream

In a standard Workspace, create the Workstream with a clear name and description, then model only the path needed for the first signal.

  1. Define the states/queues where cases can wait or be worked.
  2. Add participants and associate their DIDs or operational roles.
  3. Define each interaction as a Touch or Movement.
  4. For a Movement, configure the expected current and next states.
  5. Add Value Metrics where an event has measurable operational or financial value.
The catalog gives the SDK the context it needs to resolve and sign a transaction consistently.
6

Send a Test Transaction

Initialize the Go SDK with issued machine credentials, then submit the smallest transaction that represents a configured interaction.

Go SDK v1.4.1 request

req := operon.TransactionRequest{
    CorrelationID: "claim-10482",
    InteractionID: "interaction-review-complete",
    Payload:       []byte(`{"source":"workflow-service"}`),
}
  • The stable correlation ID groups related events into one case within the Workstream.
  • The SDK hashes raw payload bytes locally and sends only the hash.
  • client.Init lets the SDK resolve Workstream, source, and target catalog details and handle signing.
  • Optional state, actor or assignee, and Value Metrics metadata can be added when those details are configured.

Official integration resources

Operon SDK repositorySupported SDKs, releases, and examplesGo transaction guideCurrent request fields and optional metadata
7

Verify the Results

Confirm the event first, then inspect the operational views enabled by the data you configured.

  • Transactions Explorer: verify the accepted, signed event.
  • Loop Atlas: inspect the correlated case path and state progression.
  • Control Tower and workflow analytics: review cycle time, queue behavior, bottlenecks, rework, and SLA signals.
  • Resource Tower: review actor attribution when participants are configured.
  • ROI Impact: review business impact when Value Metrics are present.
When the transaction and its correlated path are visible, the first end-to-end signal is complete.
8

Expand Deliberately

Expand after the first signal is visible and trusted.

  • Add the remaining interactions and states to the first Workstream.
  • Add additional Workstreams as their boundaries become clear.
  • Increase participant attribution and Value Metrics coverage.
  • Enable immutable ledger proofs where the use case requires them.
  • Bring verified workflow measures into operating reviews and improvement decisions.

Build from one trusted signal

Operon.Cloud becomes more useful as coverage grows, but each expansion should preserve clear workflow boundaries and reliable attribution.