# Resolve an encounter

Issuer: ZLAR Inc.

Edition: 0.3 · Updated 6 November 2026

Scope: public reference; establish the request’s current status and applicable permission from destination records and governing instructions.

## Read the response in context

Use the response to identify its source, the particular request, the reported decision and what is known about the effect. A checkpoint reports its decision; a destination can report what it did. A client reporting a lost response may not know whether the action completed.

A reference link identifies explanatory material. It does not authenticate the sender or supply permission. Use the trusted channels and evidence available for this interaction. Keep private request details in those channels, out of website links.

Fictional response · invented request reference

```text
ZLAR — request refused
Source: destination response
Request: example-42
Proposed effect: deploy build A to the payment network
Decision: refused
Execution outcome: not established by this response
Next: retain the refusal; use a supplied review route if needed
Reference: https://zlar.io/authority.html#refused
```

The decision above does not resolve an earlier or parallel attempt. Preserve the request reference and check the relevant outcome separately. Continue independent work already covered by valid permission.

[Existing permission](authority.html#permitted) · [Decision needed](authority.html#decision-needed) · [Refused](authority.html#refused) · [Unknown result](authority.html#unknown) · [Changed conditions](authority.html#changed) · [Withdrawn or expired](authority.html#ended)

## 01 / Identify the encounter

Retain the response and request reference within the task’s permitted handling of information. Establish what the destination actually reported and which source supplied it.

| Question | Useful information |
| --- | --- |
| What was attempted? | The specific change, affected resource and intended consequence. |
| What permission applies? | The relevant decision-maker or recognized grant, its scope and current conditions. |
| What did the destination report? | The actual decision or error. Keep the reported reason attributable to its source. |
| What happened? | Observed effects, completed work, partial effects and what remains unknown. |
| What can happen next? | A supported path available to this actor: proceed, check status, obtain a decision, recover or request review. |

A name or link alone leaves these questions open. Use the information available; identify what is missing. This public reference does not carry the destination’s current request state.

## 02 / Select the next supported step

| Situation established | Response |
| --- | --- |
| An unblocked step is covered by valid permission | Continue through the supported path. A new step does not automatically require a new human ask. |
| A decision is still required | Prepare the exact proposed change and the material consequences for the relevant decision-maker. Continue independent permitted work. |
| An authenticated, applicable refusal was issued | Retain the refusal as a refusal. Do not carry out the same refused consequence through another actor or route. A separate review may be available. |
| The outcome is unknown | Check through an available supported status or recovery route before a consequential retry. Report uncertainty if no such route is available. |
| The action or a material condition changed | Compare the revised consequence with the current permission. Obtain a new decision where the existing permission no longer covers it. |
| Permission was withdrawn or expired | Use the applicable stopping procedure. Establish what stopped, what already happened and what may still be unfolding. |

Permission and execution are separate dimensions. A refusal of this request does not establish the outcome of an earlier request. An acknowledgment does not establish completion.

## 03 / Locate the relevant authority

### Acting inside the organization

Use the instructions and channels available to your role. Employment, an internal account or technical access does not supply every decision right.

### Acting from outside

Use the destination’s external instructions and the access provided for this interaction. Your principal’s request does not automatically supply another party’s permission.

The requester, decision-maker and affected people may be different. A destination can report the authority its process recognizes; that does not settle every question about whether a restriction is justified.

## 04 / Explain a disputed restriction

State the particular change, the reason given, the conflict you see and the outcome sought. Use information you are permitted to share. Identify an actual review route, if one is available.

If no review route is supplied, report that gap. It establishes neither that the restriction is justified nor that the refused change is authorized. Continue independent analysis already within scope.

Examination of public claims is distinct from access to private systems, disclosure of information or active security testing. Each consequential action retains its own scope.

[The place of disagreement](people.html#disagreement)

## Example / A live-system repair

Fictional workflow · a reading example

Separate independent work from the protected change.

WITHIN EXISTING PERMISSION

Inspect approved diagnostics  →  Prepare a repair  →  Test in the permitted environment

SEPARATE PROTECTED CONSEQUENCE

Establish valid approval for this deployment  →  Deploy the identified build to the live payment network

In this example, preparation and testing have their own valid permission. The protected deployment decision does not suspend unrelated work. If the build or destination changes, compare that new proposal with the permission actually given.

[Read the example records as JSON](examples.json)