twimco.Let’s talk ↗︎
Menu
Field notes / Commerce

The clock does not advance on a promise.

Someone says the deal is ready while someone else is still waiting on a signature or a funds check that was "basically done." In a complex close, the clock should move when named conditions are met and proven, not when the room feels finished.

Editorial illustration for Field Note: The clock does not advance on a promise.

In a complex close, the clock should advance only when named gates are green. Decide which gates those are, which role may pause the clock, what evidence each gate needs, and the abort path if one fails. A verbal "we are done" is not a gate. The point is to make the close inspectable, not to measure the deal.

Close is a sequence, not a mood

In a simple cart, checkout is a short sequence and the awkward part starts after payment. In a private market, a fund close, or any deal that depends on several parties being ready at once, the awkward part is the clock itself. Someone says the deal is ready. Someone else is still waiting on a document, a signature, a funds check, or a disclosure that was "basically done." The clock moves because the room felt finished.

That feeling is not an operating fact. A settlement clock advances only when named gates are green, a named role is allowed to pause it, each gate carries evidence you can reopen, and a failed gate has an abort path that does not depend on whoever is loudest in the room.

This note is the TWIMCO Settlement Clock Spec. It is one page for one close type. It is not a legal opinion, not a disclosure checklist, and not a cutover runbook for a software release. Disclosure lists what must be in the package. A service evidence pack proves a partnership. A cutover runbook freezes a system. This spec answers a different question: what has to be true before this clock is allowed to tick, who may stop it, and how the close dies cleanly if it should not finish.

On Sutton|Place, verification, disclosure, and who may act are treated as inspectable facts rather than as confidence. Bring that habit to the close. If the clock lives in software you are building, the product surface is a web application with explicit state, not a shared spreadsheet that changes color when someone feels ready. There is no live tool on this site that fills the spec for you. The page is the asset.

Write the spec before the first deal of that type, not during it. A clock invented in the closing window will bless whatever is already true. A clock written earlier can still be wrong, but it can be wrong in daylight, with the gates visible enough to argue about.

Gates that must be green

A gate is a condition with evidence, an owner, and a fail behavior. "Legal is comfortable" is not a gate. "The subscription document is signed by the parties named on the order, and the signed file is in the deal room" can be a gate, if you also say who checks it and what happens when it is late.

On the TWIMCO Settlement Clock Spec, each gate gets six lines:

Name. A short condition a stranger could test. Prefer the artifact or the check, not the department's mood.

Owner. The role who marks it green. Not a committee. If two roles must both agree, that is two gates, or one gate with two evidence lines and a rule for disagreement. Disagreement defaults to not green.

Evidence. The thing you can reopen later: a file, a ledger entry, a message from a named system, a checklist signed by the role. "We talked" is not evidence. If the evidence can be edited after the gate goes green, say so, and say whether the gate must be reopened.

Blocking. Yes or no. A non-blocking gate is a note, not a gate. Do not mix them. If you care enough to put it on the clock, it blocks.

Freshness. How old the evidence may be when the clock advances. A funds check from last week may or may not still be the check. Write the rule. Do not invent a number to look precise. Write the rule your close actually uses, or "not yet decided," which means the gate is not ready.

Fail behavior. Pause, abort, or return to a named earlier gate. "We will figure it out" is not a behavior.

Four to seven gates is enough for one close type. More than that usually means two clocks glued together, or a wishlist. Fewer than three often means the close is still a mood with labels. The count is a planning habit, not a benchmark about your deals.

Order the gates in the sequence they must become green. Some may be parallel. Say so. Parallel gates still each need an owner. A gate that waits on "the rest of the list" is a circular clock. Break the circle before you build the screen that shows it.

Sequence of work

States of one settlement clock

  1. Not started

    The close type has a spec. This deal has not entered the gates.

  2. In progress

    Blocking gates are being evidenced. Absence of evidence is not green.

  3. Paused

    A named role paused a named gate and wrote what resume requires.

  4. Ready

    Every blocking gate is green and still fresh. Nothing has settled yet.

  5. Settled or aborted

    Effects are in the record, or the abort path has run and named what remains.

Illustrative close sequence, not a client screenshot or measured result.
A settlement clock that advances on a promise is not a clock.

Who may pause, and what they must leave behind

Pause is a power. If everyone can pause, nobody knows whose pause is real. If nobody can pause, the clock runs over a gate that just failed because reversing feels impolite.

Name one pause authority on the spec, and name the delegate when that role is absent. The delegate is a role, not "whoever is online." A pause without a reason code is a delay. Give the pause a small set of reasons that match real stops: evidence stale, party missing, amount mismatch, disclosure incomplete, external dependency down. Add "other" only with a required sentence. Do not add a reason you have never seen just to look complete.

A pause records four things: who paused, when, which gate, and what would make it legal to resume. Resume is not the absence of objection. Resume is a new green on the gate that failed, or an explicit waiver by a role you named in advance. If waivers exist, the spec says which gates may be waived and which may not. A waiver of identity, of funds, or of a required disclosure should be hard to grant and easy to see afterward. If your close truly allows it, write the role. If it does not, write "not waiveable" so the software cannot grow a quiet override.

The clock has visible states. At minimum: not started, in progress, paused, ready to settle, settled, aborted. "Ready to settle" is not "settled." Settled means the effects you care about have been written to the system of record, not that a person clicked a button that said complete. If settlement itself can half-finish, the spec points at the recovery for that partial write. Do not hide a second problem inside the last gate.

Operators should be able to tell these states apart without reading a chat log. If the only way to know the clock is paused is that someone remembers, the spec has not reached the product yet. The state belongs on the deal, next to the gate that caused it.

Abort is a path, not a panic

Deals die. A clock that can only succeed will be forced forward, because abort was never designed. The TWIMCO Settlement Clock Spec includes an abort path for the close type.

Abort names: who may abort, which states allow it, what is already true that must be unwound, what is allowed to remain, and who tells the parties. Unwind is specific. If a hold was placed on funds, who releases it. If a document was marked final, who returns it to draft. If a notification already went out, what the correction says and who sends it. If nothing was written yet, say that abort at that stage is only a status change, so people do not invent cleanup.

Do not promise that abort is free. Say which effects are hard to reverse and therefore which gates must come before those effects. That ordering is the real design of the clock. Teams get this backward when they send the "you are done" notice before the last blocking gate, because the notice feels like hospitality. Hospitality can wait. A notice that must be corrected is an incident.

Partial settlement is the case the spec should be embarrassed to leave blank. Some gates green, money or title or access already moved, one gate red. The abort path either completes a compensating action or parks the deal in a named state with an owner and a next review time. Parked without an owner is how closes become folklore.

These situations are composites from how complex closes and marketplace settlements behave, not measurements from a client book and not a claim that any particular deal failed this way. Use them to pressure-test the page. Do not turn them into a chart.

Keep the spec next to the deal type, and revise it when a close teaches you a gate you did not have. Revision is a change to the spec, with a date and a role, not a quiet edit in the middle of a live deal. A live deal runs on the spec that was in force when it started, unless the pause authority records an explicit switch.

Decision guide

A felt close versus a clock

ConsiderationThe room feels doneThe spec can advance
Ready meansPeople say they are comfortable.Named gates are green, each with evidence you can reopen.
Something is lateThe clock keeps moving out of politeness.A named role pauses, with a reason and a resume rule.
A gate fails lateSomeone improvises a cleanup in chat.Abort names what unwinds, what remains, and who tells the parties.
WaiverAn override appears because the button exists.Only gates the spec marked waiveable, by the role it named.
Decision framework: assess these conditions against your own close.

Put this into practice

  1. Pick one close type. Not every transaction you run. One clock.
  2. List four to seven blocking gates. For each, write owner, evidence, freshness, and fail behavior on the TWIMCO Settlement Clock Spec.
  3. Name the pause authority, the delegate, the reasons, and which gates are not waiveable.
  4. Write the abort path, including the effects that are hard to reverse and the order that keeps those effects after the gates that protect them.
  5. Only then ask software to show the states. If you are building that surface, treat it as a web application whose states match the spec. Ground the habit in work like Sutton|Place, where verification and permission stay inspectable after the meeting is over.

A room can feel ready and still be missing a gate. The clock is there so the feeling does not get a vote.

twimco.

We build alongside the people doing the work.
Bring us the problem you’re thinking about.

Related work

Sutton Place ↗︎