Workflows

Authorized workflow actions

Create tickets, route finding ownership, and record policy exceptions through capability-specific grants and separate human approval.

Hyperoru separates event delivery from consequential actions. A signed webhook can announce that an audit completed; it cannot create a ticket, assign a finding, or accept risk. Each action requires an active capability grant, a typed request, and a different authorized person to approve it.

Prepare, approve, execute, recordConsequential actions cross capability and human approval boundaries before a worker performs them.HYPERORU FIELD GUIDEEVIDENCE FIRSTPrepare, approve, execute, recordConsequential actions cross capability and human approval boundaries before a worker performs them.TB1TB2REQUESTAUTHORIZEEXECUTEcheckrequireenqueuerecord01Typed requestOne finding + reason02Capability grantTicket · owner · exception03Different approverAdmin or Owner04Durable workerOne authorized effect05Action historyAttempt + resultThe requester cannot approve their own action.
Prepare, approve, execute, record

Capabilities

CapabilityProviderEffect after approvalMinimum approver
Ticket creationJiraCreate one issue for the selected finding and retain its external ID and URLAdmin
Ownership routingInternalAssign the selected workspace member to one findingAdmin
Policy exceptionInternalRecord a bounded accepted-risk state with a reason and required expiryOwner

An authorization grants only one capability. Jira credentials are encrypted and write-only. Internal ownership and exception grants have no external credential.

Request and approval lifecycle

  1. An Owner or Admin creates a capability authorization in Settings → Automation.
  2. A workspace member requests a typed action for one finding.
  3. Hyperoru stores it as pending_approval; no side effect has occurred.
  4. A different Admin or Owner reviews the target, reason, and capability. Policy exceptions require an Owner.
  5. Approval enqueues a durable outbox item. Rejection ends the action without execution.
  6. The worker performs only the authorized capability and records attempts, result, external reference, and safe error code.

The requester cannot approve their own request. Directly changing a finding to accepted risk is rejected by the API; the policy-exception workflow is the only supported path.

Failure and replay behavior

Every action request requires an idempotency key. Worker execution is retry-safe and bounded. A Jira timeout or provider error keeps the error code visible without exposing the credential or external response body. Operators can inspect grant state, pending approvals, attempts, and results from the private admin dashboard.

No ambient agent authority

Specialist agents may prepare evidence and suggested text, but they cannot create or approve a workflow action. Authorization, approval, and worker execution are separate system boundaries.

For notification-only destinations, see team workflow destinations.

Provider and private model routing

Govern Luna, Terra, and Sol model assignments across approved LLMGateway routes and encrypted private endpoints.

Architecture change intelligence

Compare the latest architecture snapshots, distinguish removals from missing coverage, and evaluate deterministic regression gates.