← All writing

Research note

ResilienceOps: make approval part of the execution path

A project-based research note on policy checks, explicit approval and audit evidence, with a flowchart connecting intent to a reviewable operational result.

By Lakshay Walia2 min read
ResilienceOpsPolicyDevOpsEvidence

The question

How can an operations interface make a proposed action understandable before it changes a system? ResilienceOps explores that question through structured operations, policy decisions, approvals and recorded evidence.

The portfolio presents the original application interface and an interactive browser edition. The browser edition uses fictional data and does not run real infrastructure operations.

ResilienceOps original application interface

Put the decision in the path

A warning next to a button is easy to overlook. A gate inside the execution path is an actual boundary: validate the request, evaluate the rule, require the relevant approval and only then proceed to the permitted action.

flowchart LR
    R[Structured request] --> V[Validate]
    V --> P{Policy decision}
    P -->|Blocked| E[Explain the reason]
    P -->|Allowed| A[Required approval]
    A --> X[Permitted execution]
    X --> L[Recorded evidence]

Separate intent, decision and result

These are different records. Intent explains what was requested. The decision explains why the request was allowed or blocked. The result describes what happened after the action was permitted. Conflating them makes a dashboard look successful even when the action never completed.

Explain a blocked action

A useful policy response gives the operator a reason they can act on. It identifies the failed condition and the next legitimate step. The public ResilienceOps tour demonstrates the distinction between a blocked request and an approved sample run, then asks the visitor to inspect the audit view.

Define the evidence boundary

The gallery and case study document the interface and verified engineering behavior. They do not establish a measured reduction in incidents or a client business outcome. Those claims need actual operational data, a defined baseline and permission to publish it.

Follow-up questions

  • Which operations require an additional human decision?
  • What happens if permission changes after approval?
  • Which identifiers connect a request to its outcome?
  • How does an operator investigate an incomplete execution?
  • How are evidence retention and access reviewed?

Explore the ResilienceOps case study

References & further reading

  1. ResilienceOps project case study

Put the idea to work

Have a workflow in mind?

Explore a related project or turn the idea into a clear brief.