Tags + Properties
Classification on the block, not in the spreadsheet next to it.
- 1Review the existing status spreadsheet (Excel or Notion DB) and note its columns as future properties.☐Checkpoint: Column list = future property keys.
- 2Fix the allowed keys and values per domain (e.g. status:: offen|review|final) and version the convention on a single page.☐Checkpoint: A convention page with keys and allowed values exists.
- 3In the source document, set the Property on the block for each statement (status::, quelle::, frist::); add Tags for cross-cutting views (#wettbewerber).☐Checkpoint: Every relevant block carries its Property.
- 4Rebuild the status spreadsheet as a Query — all blocks with status:: review, sorted by frist::.☐Checkpoint: The query result matches the old spreadsheet.
- 5Archive the old Excel sheet as read-only — do not maintain it further. From now on, the Query is the view.☐Checkpoint: tracker.xlsx in `archiv/`, Query set as a bookmark.
- 6Spot check: verify on five blocks that the property value and the source text agree.☐Checkpoint: Consistency source ↔ view confirmed.
#wettbewerber, status:: review, source:: bloomberg — classification on the very block that needs it. No spreadsheet alongside.
- Classification time per report: −65%
- Spreadsheet upkeep effort: −80%
- Data consistency source ↔ view: 100%
Why the Excel sheet becomes a second truth
In day-to-day due diligence, content and classification run apart — memos in Word, an Excel register with status, source and competitor sitting next to them. The moment a memo is updated, the register drifts. After 12 weeks you find 18 entries marked “review” whose source text has long read “final”.
5 rules
- Tag = cross-cutting classification. `#wettbewerber`, `#risiko`, `#vendor` — flat, no hierarchy, for views across domains.
- Property = structured metadata. `status:: review`, `quelle:: bloomberg` (quelle:: is the German DSL key for source), `frist:: 2026-06-30` (frist:: = deadline) — key-value, queryable, typed.
- Query = living view. One query over all blocks with `status:: review` replaces the hand-maintained spreadsheet. The result refreshes the moment a block changes.
- Properties on the Page or the block. A Page property holds for the whole document (client, contract type). A block property holds for the statement (the source of a figure, the deadline of a paragraph).
- A convention per domain. Which keys and values are allowed is fixed per domain and versioned — not improvised per person.
## Competitor memo Acme
status:: review
quelle:: bloomberg
frist:: 2026-06-30
Q4 revenue stood at ₹142 crore #wettbewerberBefore and after — Excel list vs. block with status:: review
| Before (Excel alongside) | After (Property on the block) |
|---|---|
| Memo in Word, entry in tracker.xlsx row 47 | The block in the memo carries `status:: review` |
| Status change: open two files, save both | Status change: edit one value, the view refreshes itself |
| Audit question “state as on 2026-04-12?” → reconcile the file history of two files | Audit question “state as on 2026-04-12?” → one version trail, one block |
| Consistency source ↔ view: checkable only by sampling | Consistency source ↔ view: 100% by definition |
The spreadsheet does not vanish — it becomes the Query. Whoever wants to see “all blocks with status:: review and frist:: < 2026-07-01” writes the query once and reads it afresh each day.
An honest question
How often do you maintain content and its spreadsheet separately? Over the current week, count the cases where you changed the same information in two places — once in the document, once in the register.
Classification that maintains itself.
Hang the meaning on the block, not on the spreadsheet alongside. Your second brain holds the status and the source right where the statement sits — a companion, not a second set of books.
Reserve your slot··free of cost →