handover

How do I hand over a project's notes without sending a pile of files?

Choose the dated blocks that matter, collect them in a cart, and download one file that opens in any browser with no account. The recipient gets the text, the references and the numbers, and nothing you did not pick.

A handover usually fails in the folder. You export a month of notes, attach three spreadsheets, forward a thread, and the person taking over has to work out which of it matters before they can start. Meanwhile your own notes also hold things you never meant to send, because a working log mixes the project with everything else you did that week.

The alternative is to decide what the handover contains before anything leaves your hands. Choosing is the work, and the file should do nothing more than carry your choice faithfully. This article walks through how that looks in the app, and where it stops.

Pick blocks, not files

A block is one dated entry from your notes, with its references, tags and measurements read out of the prose. There are two ways to choose which blocks go in. The first starts from a subject: on a subject's dossier page, such as a ticket like TICK-1842 or a person like @dana, a link offers to build a pack for every mention of that subject. If you have set a date window on the dossier, the link says so and the pack covers only that window.

The second way is one block at a time. Every block's page carries an Add to evidence pack button, and the same place shows a count of what you have collected so far. That route suits a handover where the story is a handful of specific entries: the day the fault was found, the decision to roll back, the day it held. A subject-wide pack would include every passing mention too, so you choose the cart when you want the short version.

The instruments page has a third door. It offers to build a pack from the blocks that page lists for its date, which is useful when the thing you are handing over is a set of tracked counts and the entries behind them.

Choose

A subject's dossier, a block's own page, or the instruments page.

Review the cart

Each picked block is listed by date, with a link back to it and a Remove button.

Download

One HTML file, named with the build date, saved to your computer.

Open anywhere

Any browser, no account, no connection to your notes.

The four steps of a handover: choose the blocks, check them in the cart, download one file, and let the recipient open it in a browser without signing in to anything.

Check the cart before you build

The subject and instruments links build the file straight away, so read the dossier or the page first. The cart is for the one-block-at-a-time route, and its page lists exactly the blocks you picked, oldest first, each with its date and a link back to the block so you can reread it. Remove takes one out, and Clear empties the list. The page says what the file will be made from: those blocks, their entities and metrics, and nothing else from your account.

Read the list as the recipient would. In a handover, the test for each entry is whether the person receiving it should see it, and interest does not enter into it. An entry mentioning a colleague's performance beside a ticket reference belongs in your notes and out of the pack, and the cart is where you notice that.

What the file carries

Download Evidence pack produces a single HTML file with its styling and scripts inside it. It makes no network requests, so it opens from an email attachment, a shared drive or a memory stick, and it keeps working after your account is closed.

What an evidence pack includes and leaves out
Part of your notesIn the file?How it appears
The blocks you picked Yes A timeline, oldest first, each with its date and current text.
References, tags, people and numbers in those blocks Yes Listed under each block, with an index you can filter the timeline by.
Instruments written into those blocks Yes, frozen The value as it stood on the build date, labelled with that date.
The rules needed to read the blocks Only the ones used The entity types and numbers those blocks actually mention.
Locked blocks Never Dropped, with a count of how many were left out.
Every other block in your account No Absent, including blocks from other subjects and other days.
Earlier versions of a block No The file holds the current text only.

The rules row matters more than it looks. A pack that mentions only one person carries what the app learned about that person and nothing about anyone else, so a name you taught the app for another project does not ride along. The file also embeds a machine-readable copy of its contents.

Frozen instruments and links that stay true

If one of your blocks contains an instrument, such as a count of every mention of a ticket, the file shows the value as of the day you built it. Three months later the recipient sees the number you saw, not a recalculation against notes they cannot reach.

Where an instrument counts blocks that are also in the pack, its value links to them, and a click jumps to those entries inside the same file. Where some of the blocks it counted were left out, the value stands alone and says it was recorded on the build date, rather than pointing at entries the recipient was never given. The count is still true, but the file does not pretend to prove it.

What the recipient can check

Blocks whose history your account has already recorded carry a proof, and the file offers a Verify button beside each one. The check runs in the recipient's browser and needs no secret. It confirms the proof's chain is intact, and the panel states plainly that it cannot confirm that this exact block text matches what your account holds. That last step can only be done from your own account.

Blocks without a proof have no button, because the pack never invents one. Packs built from this morning's entries can therefore carry proofs for older blocks and none for the newest, and a recipient who sees a missing button knows what it means.

What this costs you

Every pack is a snapshot, and a snapshot goes stale. If the ticket reopens next week, the recipient's copy still says it was closed, so a handover file should be treated as dated evidence and not a live view. Rebuilding is cheap, but you have to remember to send the new one.

Your cart is a working list for the current session and not a saved record in your account, so a half-picked pack does not survive a long absence. It is also kept small, and a pack has a ceiling on size: when more blocks match than fit, the file keeps the earliest ones and says so at the top. For a long project, pick by subject and window, in pieces, instead of asking for everything at once.

Locked blocks are the strictest limit. Their text never enters a pack, whatever you select, and the cart tells you when a block you picked has since been locked. Should the handover depend on a locked entry, you would need to remove the lock deliberately, or write the relevant facts into a new block that is safe to share.

Finally, the pack is only as good as the notes. Blocks written as “the thing broke again” arrive as exactly that, with no reference attached and nothing for an index to filter on. The handover you can build tomorrow depends on whether you named things today.

Where to start

Open a subject you are about to hand over and read its dossier first, then use the link at the bottom to build a pack for it, with a date window if only part of the story is the recipient's. Open the file in a private browser window before you send it, so you see what they will see. The trial shows the dossier and the instruments page on sample notes without an account.

Keep reading

blk/txt reads log files you already keep and makes them searchable by date, reference, and tag. The FAQ covers accounts and privacy.