The register that only grows.

Reporting a boundary and owning one

The distinction is easy to state and easy to lose.

Reporting a boundary means knowing it exists, describing what happens there, and telling people about it on a cycle. It produces an accurate document and it changes nothing.

Owning a boundary means being answerable for whether it is resolved. That requires the ability to force a question to a decision, which is a different thing from the ability to write the question down.

The title implies the second. Where a project has only the first, the gap between them is where a year of open items comes from.

What closing an item actually means

This is the load-bearing definition and it is stricter than the one most registers use.

An interface item is not closed when the parties agree what should happen there. It is not closed when a drawing is issued showing the detail. It is not closed when everybody in a meeting nods.

It is closed when one party has accepted the work into their scope, with a price and a date. Until that has happened, what exists is a shared understanding, and week 3 covered what a shared understanding is worth when money is involved.

Applying that definition to an existing register is uncomfortable and useful. Items that have been marked closed for months turn out to be agreements nobody priced. That is not a bookkeeping correction; those are live exposures that the register was reporting as resolved.

The authority problem

Whoever holds the function generally can't close anything themselves, and the reason is structural rather than personal.

Closing an item means somebody takes scope and cost. That is a commercial decision inside one of the contracting parties, and as week 8 established, it may sit above the site's delegation limit and require a body that meets monthly.

So the function can't instruct. What it can do is narrower and still substantial: make the boundary visible before anybody reaches it, put the question in front of a named person on each side, and escalate on a date rather than on a crisis.

The third is the one that distinguishes the job from administration. An item raised in March with a required-by date of June, escalated in April because no answer has come, is being managed. The same item raised in March and reported every month until June is being watched.

The instrument the register stands in for

There is a contract that does what the register can't, and on a job let as packages it is the critical one of the structure. It sits across all of the packages rather than under any of them, every contractor signs it, and it is drafted for the job — there is no published form to reach for.

What it carries is the duty that runs sideways. It allocates the interface risk between the packages, gives the contractors somewhere to work a boundary out among themselves instead of sending every question up through the employer, and sets a dispute route common to the contractors, the engineer and the employer. Some versions attach a bonus to finishing early, so that cooperation has a price attached as well as an obligation.

That changes what closure is. Where one exists, accepting scope at a boundary is a contractual act between the two parties who meet there. Where one doesn't, the same acceptance rests on goodwill and on an employer willing to carry the question — which is why the register on most jobs escalates rather than closes.

It is also why they are not universal, and the objection deserves stating properly rather than being treated as reluctance. Some contractors welcome one and read it as a workable regime for reaching a completion date they all share. Others refuse the concept outright, because it hands them a second source of liability alongside the one they priced — exposure sideways, for coordination somebody else used to be paid to carry. That is not an unreasonable position, and a week that ended by recommending these agreements wouldn't have understood it.

None of it is yours to draft. By the time you arrive it either exists or it doesn't, and finding out which is one question to the contracts team. The answer tells you whether your register has a route to closure or only a route to escalation, and those are two different jobs run in the same chair.

Where the function sits

Three placements are common and two of them have a structural problem.

Inside one of the contracting parties, the function is doing its own company's commercial work. That may be entirely legitimate and it is not neutral, and the other parties will treat the register accordingly.

With the employer alone, it has the standing to escalate without necessarily having the technical detail to know a boundary exists before somebody reaches it.

The version that works sits with project controls, for the reason Reporting Week 14 gave about noticing inconsistencies: it is the only function with the programme, the scope documents and the records of every party open at the same time. That doesn't confer authority. It confers early sight, which is the input the authority needs.

The harm in a good-looking register

One more point, because it is the reason this matters more than it appears.

A project with no interface register has a visible problem. Somebody will eventually notice that nobody is looking at the boundaries.

A project with a well-maintained register that closes nothing has an invisible one. The document is evidence that the subject is being handled. It is presented monthly, it is accurate, and it satisfies the question. Meanwhile the items on it arrive in the field one by one, exactly as they would have without it.

Which is the same shape as Reporting Week 26: a report that is entirely correct and changes nothing. The difference is that here the report is also the reason nobody asks.

System design

Five fields, of which most registers carry the first and the last in a weaker form. The middle three are what make the function a job rather than a report.

Record	Produced by	Required quality	Verified against	Feeds
Interface item	Project controls	What physically happens at the boundary, in one line	The boundary register	Scope acceptance
Named person each side	Project controls	A person who can take it internally, not a company	The organisation charts	Escalation
Required-by date	Project controls	When the answer is needed, derived from the programme	The look-ahead	Escalation date
Escalation date	Project controls	Set in advance and acted on whether or not there is news	The decision lead times	Governance route
Closure evidence	The accepting party	Scope accepted, priced, dated — not an agreement	The variation or instruction	Budget · programme
Interface agreement status	Contracts	Whether one exists, and which packages have signed it	The package contracts	Whether closure has a contractual route

The escalation date is the field that does the work and the one nobody sets. A date fixed in advance and acted on regardless converts chasing into a routine, which is the only form in which it survives a busy month.

Practical insight

Open your own interface register and apply the closure test to every item you have marked closed. Has a party accepted that work into their scope, with a price and a date?

Whatever fails goes back to open. Your register will look considerably worse than it did this morning, and the number you are left with is the one you actually have.

Then take your oldest genuinely open item and give it the two things it probably lacks: a named person on each side rather than a company, and a date by which you need the answer rather than the date you raised it. Put that escalation date in your calendar and act on it whether or not anything has happened. That one change is most of the distance between the two versions of your job.

Key takeaways

• A register that only grows has nothing on it connected to somebody who can decide.
• Reporting a boundary produces an accurate document. Owning one means being answerable for whether it resolves.
• An item is not closed by agreement, by a drawing, or by a meeting.
• It is closed when one party accepts the work into scope, with a price and a date.
• Items that fail that stricter test are live exposures the register was reporting as resolved.
• The function can't instruct, because closure is a commercial decision inside a contracting party.
• What it can do is make the boundary visible early, name a person on each side, and escalate on a date rather than on a crisis.
• A well-maintained register that closes nothing is worse than none, because it answers the question that would otherwise be asked.
• The agreement that carries the boundary duty sits across the packages, not under them, and has no published form — so it exists only where somebody wrote it in before they were signed.
• Contractors refuse it for a real reason: a second source of liability alongside the one they priced. Recommending one is not an answer to that.

Records born here. The interface register with a named person per side · the required-by date and the escalation date · the closure evidence: scope accepted, priced, dated · whether an agreement across the packages exists at all.

What is coming next

Boundaries in space are one problem. The same packages also produce boundaries in time, and each party arrives with a programme built to its own rules.

Next week: three programmes and one project — detail, data dates and calendars that don't match.