risk-nexus/docs/method/dependencies.md

---
id: RISK-METHOD-DEPENDENCIES
type: method
title: "Waiting: how this register depends on other people without becoming a queue"
status: adopted
owner: risk-nexus
adopted: "2026-08-20"
workplan: RISK-WP-0001
review_interval: 6m
disclosure: public
revision: "adopted-1"
last_reviewed: "2026-08-20"
---

# Waiting

By 2026-08-20 the register had accumulated nine waits in four days, one of them
four hops deep: `RISK-F-0003`'s embargo waited on `RISK-F-0009`, which waited
on `railiance-platform` fixing a deny set, which waited on someone verifying it
against live OpenBao, which waited on a credential nobody has.

Nothing in that chain is anyone's fault, and every link was individually
reasonable. That is exactly why it needs a rule: deep dependencies are not
built deliberately, they accrete one sensible step at a time.

## The principle

**The register never waits to decide. It decides, and revises when told.**

A wait is a *refinement* pending, not a decision pending. If the register
cannot act until someone answers, the register has made that person's silence
into its own paralysis — and `INTENT.md` is explicit that a register nobody
acts on is worse than none.

## The four rules

### 1. Every wait is typed

No record may say "waiting on X". A wait carries six things:

```yaml
waiting_on:
  - who: tenant-engine
    what: "confirm or correct the unfiltered events() read; open fix tracking"
    since: "2026-08-19"
    would_change: "grade rises if the log carries payload rather than metadata"
    default: "grade stands as recorded; absent fix tracking noted as a stall"
    default_at: "2026-09-03"
```

`would_change` is the discipline. If nobody can say what the answer would
change, there is nothing being waited for, and the wait should be deleted
rather than carried.

### 2. Depth one

**A record may wait on at most one other record, and never on a record that is
itself waiting.**

When the chain would go deeper, the far end is cut: the record takes its own
default and says which unresolved thing it declined to wait for. Two hops is
the point at which nobody can see the whole line any more, and a wait nobody
can see is indistinguishable from a thing that was dropped.

Applied 2026-08-20: `RISK-F-0009`'s embargo condition was
"verified against live OpenBao", which no one in the estate can currently do.
It now lifts on **`railiance-platform` reporting the coverage**, with live
verification recorded as a refinement rather than a condition. That cut the
`RISK-F-0003` chain from four hops to two.

### 3. Defaults are dates, and defaults are pessimistic

Every wait resolves on a date whether or not anyone answers. The default is
**the reading the stated facts already support** — never a hold, never a
downgrade earned by silence.

This is what removes the incentive to wait. Silence does not buy an owner a
softer grade or a quieter register; it costs them the grade the evidence
supports, which is usually the one they would want corrected. Answering is how
a grade improves, and that is the right shape for the incentive.

The register says so in advance, to the owner, in writing. A default nobody was
warned about is an ambush, not a rule.

### 4. A condition naming somebody else's action carries a date beside it

"Embargo lifts when X ships" is a dependency with no end. "Lifts when X ships,
or is re-decided on 2026-09-20" terminates.

Re-decided is not the same as lifted — the re-decision may extend the hold with
a fresh reason. What it may not do is extend by default, which is how holds
quietly become permanent.

## What this does not solve

Some dependencies are real and cannot be defaulted away. Nobody can verify an
OpenBao policy without a token, and no rule here conjures one.

What the rules do is stop that from propagating: the register grades on what is
stated, records what it could not verify, and keeps its own position
independent of the blockage. `docs/method/verification.md` bounds what this repo
can establish itself, and every grade resting on a document rather than a probe
says so on its face.

## Waits outlive statuses

A finding that is `fixed` can still owe something. `RISK-F-0001` was closed on
2026-08-19 and is still waiting on `policy-nexus` for the publication entry
that turns `disclosure: public` into an actual address.

So the waiting list is built from **every** finding, not from the watched ones.
A closed record with an open obligation is precisely the thing that goes quiet,
because nothing is prompting anyone to look at it any more.

## A wait is not a findings-only idea

Adopting a rule is nobody's finding. Registering a canon kind is nobody's
finding. Publishing a document is nobody's finding. All three are obligations
someone owes, and each one that lived outside the mechanism was invisible to it.

So waits attach to **any** record this repo keeps — findings, regulatory
records, workplans — and `make check` reports them together. `RISK-WP-0001`
carries two: the escalation rule that is producing decisions while still
`status: proposed`, and the canon question about what kind of thing a finding
is.

The first of those has the most uncomfortable default in the register, and it
points inward: **if the rule is not adopted by 2026-09-17, it is recorded as de
facto in force but unratified, and every escalation sent under it says so on
its face.** That is worse than either adopting or rejecting it, which is the
point — a draft that quietly governs is the thing this register was built to
notice.

## Where the waits are visible

`make check` reports every open wait with its age, its owner and its default
date, flags any default that has come due, and flags any wait that points at a
record which is itself waiting — a depth-two violation, caught by tooling
rather than by someone noticing.