Skip to content

Checklists

The instrument a practitioner works through while carrying a change out, with a completion test and a named artifact on every item


Implementation Checklists

A research paper argues why something matters. A training course teaches how the thing works. A checklist is the instrument a practitioner works through while doing it, and it is the only one of the three that leaves evidence behind.

That last point sets the whole design. An item in a Journal checklist is not a task on a project plan. It is a claim the firm will later have to stand behind, in front of an auditor, a regulator, a client, or its own risk committee. So every item carries a completion test that says what "done" means in terms someone else can check, and a named artifact that says what document, record, or approval proves it. Every item that does not apply carries a reason for not applying, recorded at the time rather than reconstructed afterward.

#### What a checklist contains

Each checklist is organized into workstreams, the macro units of the work, each opening with its objective, its owner, its dependencies, and the criterion that closes it. Items sit beneath the workstreams and carry stable identifiers that do not change between editions, so an audit reference or a client annotation made against one edition still resolves in the next. Beside each item is a note pane, which is where the value sits: what the item is actually asking for, what commonly goes wrong with it, and what the acceptable evidence looks like.

Checklists come in two shapes. A countdown checklist is built against an anchor date, with phases running in T-minus windows toward it, and suits a migration, a go-live, or a regulatory deadline. An evergreen checklist is built against a lifecycle or a control cycle and suits recurring work such as counterparty diligence or an annual review.

Each checklist ships as a formatted document for reading and as a working register for use, so that a team can record owners, dates, status, and evidence against the items as it goes.

#### How they are sold

Checklists are catalog items in their own right. A checklist is priced and bought on its own, and it does not depend on owning any paper to be usable. Where an item rests on an argument the Journal has made elsewhere, the note pane states the conclusion in its own words; the cross-reference to the paper is a courtesy for a reader who wants the reasoning, never a load-bearing part of the item. Checklists are included in full in an [institutional license](/licensing/).

#### Coding

Each checklist carries a code: a topic code from the Journal's controlled vocabulary, the letter C, and a sequence within that topic. SET-C01 is the first settlement checklist; CUS-C01 is the first custody checklist. The topic is the permanent shelf and is fixed when the checklist is commissioned, so a checklist's code does not change if the way the catalog is organized does.

#### What they are not

A checklist is not a compliance opinion, a legal interpretation, or a substitute for the firm's own control framework. It is an experienced practitioner's account of the work a change requires and the evidence it ought to produce, written so that a team can adapt it to their own environment, delete what does not apply, and defend what they did. Firms remain responsible for their own obligations.