Request Lifecycle

This page describes the operator-facing lifecycle of a request after it enters Beav3r.

High-level flow

The common lifecycle is:

1. request submitted
2. policy evaluated
3. request enters pending review or resolves immediately
4. signer approves or rejects, or the request expires
5. final state is recorded and optional callbacks are delivered

Request states

pending

pending means the request is waiting for signer review.

This is the main Inbox state for human review.

approved

approved means a signer accepted the request.

Depending on the integration, this may be the final business decision or the point where another system continues execution.

executed

executed means the request was completed after approval or immediate allow.

This is the strongest completion signal when execution is part of the Beav3r-controlled flow.

denied

denied means policy blocked the request before it reached signer approval.

Inbox review is often not involved in this path.

rejected

rejected means a signer reviewed the request and chose to block it.

This differs from denied, which is policy-driven.

expired

expired means the request stayed unresolved until the action expiry time passed.

This usually points to:

• no signer action in time
• too short an expiry window
• a stalled review flow

Operator checkpoints

At pending, the main questions are:

• does the actor identity make sense
• does the action summary make sense
• does the business context make sense
• does the matched condition explain the review requirement

At approved or executed, the main question is:

• did the request resolve the way the product expected

At rejected, denied, or expired, the main question is:

• did the request fail for the intended reason, or does the policy or trigger need adjustment

Lifecycle events outside Inbox

Other systems may also observe the lifecycle through:

• SDK polling
• callback delivery
• recent action history
• project audit and activity views