Real delivery work sometimes needs more time. BIMP treats that decision as a governed, time-bound Exception rather than an informal note or a permanently hidden result.
The visible task type is Snooze Requests. Reviewing and approving one creates the underlying Exception decision.
Workflow overview
Section titled “Workflow overview”- A developer comments on an eligible remediation pull or merge request.
- BIMP validates the command, repository context, image reference, and requested end date.
- A Snooze Requests task opens for an authorised reviewer.
- The reviewer inspects the request and current evidence.
- Approval creates a time-bound Exception. Denial leaves policy enforcement unchanged.
- Later policy, repository, remediation, or expiry changes are reflected in the task history and current state.
Approved Exception evidence is authoritative in BIMP and stored centrally. BIMP does not currently publish that evidence back into the repository.
Submit a Snooze Request
Section titled “Submit a Snooze Request”Post one of these commands as a pull or merge request comment:
/snooze 4d "Waiting for the upstream module release"/snooze 2w "Compatibility testing needs another sprint"/snooze 2026-08-31 "Migration completes at the end of August"A reason is required. Durations use d for days or w for weeks. An absolute
date uses YYYY-MM-DD. Requests must end in the future and cannot exceed 90
days.
The requested end must also reach the repository’s next active routine date. If it ends sooner, BIMP rejects the request and replies with the routine date to use. This prevents an approval from expiring before the next expected review point.
BIMP replies on the provider discussion when the request is accepted, already processed, invalid, or conflicts with an active request.
Review a request
Section titled “Review a request”Open Tasks → Snooze Requests and select the request. Review:
- repository, branch, and source artifact;
- remediation pull or merge request;
- affected image subjects;
- requester and requested expiry;
- the request reason;
- the policy and evidence snapshot; and
- any stale or changed-context diagnostic.
The requester cannot approve their own human-submitted Exception review. The review action also requires write authority for that Exception resource.
Choose:
- Approve to create the Exception through the requested expiry;
- Deny to reject the request with a review note; or
- Cancel when the requester withdraws an open request.
BIMP posts the decision back to the linked pull or merge request when the provider context is still available.
Understand the lifecycle
Section titled “Understand the lifecycle”| State | Meaning |
|---|---|
| Open | The Snooze Request is awaiting a decision. |
| Approved | A time-bound Exception currently applies. |
| Denied | The reviewer declined the request. |
| Cancelled | The request was withdrawn or its remediation completed first. |
| Revoked | An approved Exception was ended before its expiry. |
| Expired | The approved time window has ended. |
An authorised reviewer can reopen an eligible request when another decision is needed. Revocation records why the previous approval no longer applies. These are new lifecycle events, not edits that conceal the earlier decision.
If the linked remediation pull or merge request is merged or closed before an open request is approved, BIMP cancels the pending task because its original work context has completed.
How an Exception affects policy state
Section titled “How an Exception affects policy state”An open review can place the affected reference in Review. An approved Exception can place it in Exception until expiry or revocation. The published mapping remains in force throughout; the Exception records a temporary decision about that enforcement context.
After the Exception ends, BIMP evaluates the current repository reference against the current published policy again. A later policy or source change may produce a different result from the one captured in the original review.
Review well
Section titled “Review well”- Ask for a reason tied to delivery reality, not a generic “temporary issue”.
- Confirm the date covers the next routine without extending further than the team needs.
- Read stale-context warnings before deciding.
- Put the decision rationale in the review record, where the next reviewer can find it.
- Revoke an approval when its basis changes rather than waiting for the clock.
Exceptions are evidence of an explicit decision. They are not missing policy, and they should not need detective work later.