Observable and auditable execution

When workflows run in your infrastructure, you have logs. When they run in customer infrastructure, you have support tickets. Opscotch makes both better by emitting structured events for every run — visible to both you and your customer.

The event stream

Every workflow execution emits a stream of structured events: start, decision, completion, error, refusal, quota-exceeded, entitlement-checked, signature-verified. The schema is documented and stable — you can build tooling against it.

Who sees what

• You (the workflow vendor) get the full event stream from your customers' runtimes, scoped to your packages.
• Customers get the full event stream of their runs, regardless of which package.
• Both sides see the same events from the same runs, with the same timestamps and the same data.

Storage and forwarding

By default, the runtime emits events to stdout, where you can capture them with whatever logging infrastructure your customer has. You can configure the runtime to forward events to a specific endpoint (your SaaS, your SIEM, your customer's data lake) via a simple configuration flag.

What this enables

• Support tickets get faster. Did the workflow run becomes Yes, at 14:32:18 UTC, with this exact configuration, and here is what it did.
• Audits get easier. Customers can prove what your workflow did on their systems, with timestamps.
• Compliance gets simpler. Both sides have a paper trail of every execution, signed and verifiable.

Privacy

Event data is scoped to your packages only. You don't see what other workflows the customer runs. The customer doesn't see what features your package contains beyond what they explicitly invoke.

The result: workflows you ship are auditable, supportable, and trustworthy — even when they're running on hardware you don't own.