Nothing closes by itself.

The two chains

Two paths run through those eight, and almost everything that goes wrong on a project travels one of them.

The first is about things you believed. An assumption that stops holding becomes a risk. A risk that occurs becomes a change, or a delay event, or both. Most change registers are full of items that began life as an assumption nobody revisited.

The second is about things you have to coordinate. An interface that is not resolved becomes a constraint on somebody's work. A constraint that is not closed becomes a delay, which is where Week 9 ends up.

Non-conformances sit slightly apart and feed both: an NCR produces rework, which reverses reported progress and often produces a change as well.

Read that way, the registers stop being a filing convention and start being a description of how a problem matures. The earlier in a chain you catch something, the cheaper it is, which is the entire argument for keeping the registers nobody thinks are urgent.

The two that close things

Six of the eight only accumulate. They record that something exists, and they can record that it stopped existing, but they can't cause it.

Two are different. The decision register records that somebody with the authority chose, and the action register records that somebody with the responsibility is doing. Those are the only two mechanisms a project has for making an entry in any of the others go away.

Which explains a pattern most planners will recognise: a risk register that grows every month and never shrinks. It is not that the risks are unmanageable. It is that nothing connects them to a decision or an action, so the register can only add.

State and inventory

One distinction keeps this manageable, because a project has far more than eight lists.

Submittal registers, document registers, material status reports, procurement logs — these are inventories. They record what exists and where it is. They are useful and they don't need a topology, because nothing flows between them.

The eight above track state: something is open, unresolved, or waiting on somebody. State needs the arrows. Inventory doesn't.

Confusing the two produces the catalogue that this week is designed to avoid: fifteen registers presented as equally important, when only a handful of them describe anything that can get worse.

The entry that belongs in two registers

A common objection to the chains is that items refuse to stay in one list, and the objection is correct.

A late vendor document is an interface question, a constraint on the crew waiting for it, and a risk to the completion date. Recording it three times produces three entries that drift apart, each updated by somebody who can't see the others. Recording it once means two of the three teams can't find it.

The workable answer is to record it where it is being managed and reference it elsewhere. The constraint log holds it while somebody is chasing the document, because that is where the daily work happens. The risk register points at it rather than restating it.

Which means the registers need to be able to refer to each other at all — a single identifier that travels. That is a small design decision, taken at the start or not at all, and it is the difference between a set of registers and a system of them.

Which ones get read

Honestly, few of them. The action list gets read because it names people. The constraint log gets read on the days somebody can't start. The risk register is read when it is reviewed and rarely between.

That is not an argument for keeping fewer. It is an argument for knowing which is which, because a register that is only read after the fact has a different job: it is evidence rather than management, and it should be kept to a standard that survives being read by somebody hostile a year later.

The ones that are read weekly should be short. The ones that are read afterwards should be complete. Trying to make every register do both is why most of them do neither.

System design

Not fifteen registers. Eight that track state, with the relationships between them written down where they can be seen.

Record	Produced by	Required quality	Verified against	Feeds
Assumption register	Project controls	Written down while it is still an assumption	Reality	Risk register
Risk register	Risk owner	Each entry linked to a decision that would close it	Assumptions, events	Change, decisions
Interface register	Project controls	One identifier that travels between registers	The other registers	Constraint log
Constraint log	Project controls	Closure with evidence	The workfront	Look-ahead
Decision register	Whoever has authority	The decision, dated, and what it closed	The register it closed	All six others
Action register	The meeting	Owner and date	Follow-up	All six others

The last two columns are the ones most register templates omit, and they are the reason six of these lists grow without ever shrinking.

Practical insight

Open your change register and take the last ten entries. For each one, work backwards: was there an assumption behind it, and was that assumption ever written down anywhere?

You will usually find that several of them were foreseeable — not certain, but visible as an assumption somebody was carrying. Those are the ones the chain would have caught.

Then do the reverse. Take your risk register and find the entries that have been open longest. For each, ask what decision would close it and who would have to take it. Any entry where you can't name that person is not being managed, whatever the review meeting concluded.

Key takeaways

• Eight registers, and the value is in the relationships rather than the lists.
• Assumption, then risk, then change: most change registers are full of assumptions nobody revisited.
• Interface, then constraint, then delay: the second chain, and the one that stops work.
• NCRs feed both, through rework that reverses progress and often produces a change.
• Only decisions and actions can close anything. The other six accumulate.
• A risk register that only grows is one with nothing connecting it to a decision.
• Separate state registers from inventories. Only state needs a topology.
• Weekly registers should be short. Registers read afterwards should be complete. Few can be both.

Records born here. The eight state registers · the map above · the review that walks the arrows rather than the rows.

What is coming next

Everything so far assumes the records can be made to agree. Once a month they won't, and both sides will be right.

Next week: progress against valuation — two legitimate methods, one number, and who gets to decide.