Platform
How resh turns a request — from a person, a script, or an AI agent — into a governed change: who may ask, what may execute, what actually ran, and what state resulted.
The governed lifecycle
Every consequential operation moves through the same sequence, whether the caller is a person, a script, or an AI agent. Three of the steps can stop it — which is the point.
The governed lifecycle in eight ordered steps: the Application, which decides who may ask; the resource, establishing what the target really is; governance, where the runtime may refuse; consequence, weighed where it is known; approval, if policy requires it, which may be declined; execution of the bounded operation; verification, which may report failure; and evidence, the durable record.
The requester works through an Application — the purpose-oriented surface for their team, such as Security Operations or Deployment Operations. Application permissions decide whether they may see the resource and request the operation.
Without it
Every operator and every automation sees the whole estate, because the only alternative is a separate tool per team.
What you get
Teams get a surface that matches their responsibility. It decides who may ask — and nothing about what may execute.
The request names a resource and an operation on it, not a command to run. resh resolves it to a real resource and the provider that knows how to act on it.
Without it
Governance applied to a command string is guesswork. Nothing can tell what it will touch until it has already touched it.
What you get
Every later step reasons about this resource and this operation, rather than about text that resembles them.
The runtime on the managed server that owns the resource evaluates its own policy against the requester, the resource, and the operation — before any work starts, and regardless of which Application the request came through.
Without it
Rules that live in a runbook are advisory. Rules applied after the fact are a report.
What you get
The same decision applies whether the caller is a person, a script, or an AI agent, at the point where it can still prevent something.
The operation’s declared risk and, where dependency context has been modelled, what else depends on the resource are taken into account. Unknown impact is never treated as low impact.
Without it
Restarting a service nothing depends on and restarting the one everything calls are treated as the same decision.
What you get
Consequence can raise the requirement for a change. It is unable to lower one that policy set.
Policy can require an authorized approval before a consequential operation is allowed to continue. The request returns without running anything and waits. The approver must be named by runtime policy and cannot be the requester.
Without it
Self-approval, or an approval that quietly covers something other than what was asked for.
What you get
The approval is bound to exactly what was requested. When it is granted, that operation continues; alter the request and the approval no longer applies.
The operation runs through the provider’s bounded capability for that resource — not a generated command, and not a session that happens to be scoped to the right host.
Without it
The thing that executes is broader than the thing that was governed, and the gap is where incidents live.
What you get
What runs is the operation that was governed, and nothing adjacent to it.
resh takes a separate look at the resource afterwards and checks it against the post-condition the provider declared for that operation.
Without it
A process that came back up is reported as a service that is healthy, because the call returned without an error.
What you get
Success becomes a fact about the resource. An operation with no declared way to be observed is reported as unsupported for verification rather than assumed to have worked.
The request, the requester, the governance decision, any approval, what ran, and the observed outcome are preserved as one linked record, viewable by Application.
Without it
Reconstructing an automated change means correlating several log systems that were never designed to be read together.
What you get
The question an incident review asks — what happened, and who allowed it — has one place to be answered.
A worked example
Abstractions are easy to agree with and hard to evaluate. So here is a single operation — an engineer, or an AI assistant acting for them, asks to restart an API service — and what resh does with it at each step.
The request is made through the Deployment Operations Application, where the API service is a member and the requester holds permission to operate. That establishes that they may ask. It establishes nothing else.
The request names a resource and an operation — the API service, and restart. The requester is not handed a shell or a credential it could point somewhere else. resh resolves the name to the real service on the managed server that owns it.
That server’s runtime evaluates its own policy. Restarting this service may be allowed, may require an approver, or may be refused outright — and the answer is the same whichever Application, script, or agent the request arrived from.
Suppose policy requires approval. The request returns without running anything and waits. An approver that runtime policy names — and who is not the requester — reviews the resource, the operation, and who asked. Being an approver elsewhere grants nothing here.
On approval, the held restart continues: the runtime re-derives its governance inputs and runs the operation through the provider’s bounded capability. There is no separate step where someone goes and runs it.
resh reads the service state afterwards. The restart call returning is the execution result; the observed state is the verified outcome, and the two are recorded separately.
What remains is a linked record: who asked, the governance decision, who approved, what ran, and what was observed. It is listed under the Application the request came through.
Notice where the operation can stop. Being permitted to request a restart is not the same as the runtime allowing it, and a restart call that returned is not the same as a service observed to be running. Those are different questions, and each one is a place where automation quietly goes wrong today.
Three separations
Most tooling reports one word. resh keeps these apart, because any one of them can be true while the next is false — and the false one is usually the one you needed.
Application permission and runtime policy are two checks, and both must pass. The runtime can refuse what an Application allowed, and that refusal is never overridden from above.
A request that requires approval returns immediately without running anything. It continues only when an authorized approver acts on it — and at that moment governance inputs are re-derived rather than trusted from when the request was made.
A provider returning cleanly never produces a verified outcome on its own. That requires an independent observation checked against a declared post-condition. resh does not retry, and it claims no undo it cannot perform.
Technical depth
Providers expose bounded operations on named resources — services (svc://), containers (container://), configuration (config://), files, and others — each declaring its own risk, whether it changes state, and how it can be observed afterwards.
Rules are evaluated on the managed server that owns the resource, before execution, and denial is a first-class outcome. Centrally published policy is installed and enforced locally.
Management surfaces that decide who may see and request through a purpose. A resource may belong to several, and no Application carries execution authority.
Preview what an operation would do, or validate it against current state, without changing anything.
An approval covers exactly what was requested — the resource, the operation, and its arguments. Change any of it and the approval stops applying rather than becoming broader.
The chain from request and decision through execution and observed outcome is recorded as data rather than prose, so it can be searched and filtered by Application.
Terminology
Tool authorization decides whether a caller may invoke a tool. Once the call is allowed, what the tool does to the underlying system is generally outside the governance boundary. Governed execution keeps the boundary open through the whole operation: the target resource and its condition inform the decision, the operation is carried out through a bounded capability, the resulting state is verified, and the sequence is recorded.
restart on svc://api-service, on the server that owns it, under the policy installed there now — and is the service running afterwards?The two are complementary. A gateway can answer the first in front of resh, and resh still answers the second at the resource.
Identity and authorization remain essential, and resh does not replace them. They answer who is acting and what they are permitted to invoke. They do not establish whether this operation should execute against this resource right now, constrain how it is carried out, or confirm what actually changed. resh treats execution itself as the security boundary.
A command string is opaque to policy. A typed operation on a named resource is not. When governance and execution refer to the same resource identity, the same operation, and the same expected outcome, controls can be deterministic rather than heuristic — and the record left behind describes the change rather than the keystrokes.
Mechanism questions
Put it against a real operation
If you can name the operation — the one where an agent or a script changed something consequential and nobody could fully reconstruct what happened — that is the conversation we want to have. Design partners bring one real workflow to a controlled, non-production evaluation of this pre-GA preview, and we work through it together.