Actions and review workflow

Documentation status: tutorial — see Maturity and evidence.

Action surface

Use explicit business actions. A representative set is:

SubmitRequest(request)
ComputeRisk(request) -> assessment
AskForReview(request, assessment) -> reviewProcess
ValidateDecision(reviewProcess, decision)
Finalize(reviewProcess) -> riskDecision

The exact generated .NET signatures depend on the published model and generator. Treat the names and parameter meanings above as the conceptual contract, not as hand-written ABI signatures.

When to introduce a process

A single object action is enough when one object owns the full operation and it completes immediately. Use RiskReviewProcess once the operation spans objects, waits for external or human input, emits several events, or must resume later.

Process state

A practical state model can include:

Created -> IndicatorsPending -> AssessmentReady
        -> HumanReviewPending -> DecisionReady -> Finalized
        -> Failed

Only use states actually required by the application. The important property is that each externally meaningful transition is explicit and testable.

Events

Emit semantic events at important boundaries, for example RiskRequest.Submitted, RiskAssessment.Ready, RiskReview.Requested, RiskDecision.Validated and RiskReview.Finalized. Event names describe what happened, not which button or transport triggered it.

Async boundary

External verification, message exchange, agent work and human approval should be modeled as asynchronous continuation when necessary. The initial action may acknowledge the request while the process continues through events and messages.