Tags + Properties
A Tag and a Property belong on the block — not in a side-panel tree that outlives every restructuring.
- ··Classification at the atom — Tag/Property as inline DSL on the block (#wettbewerber, status::offen).
- ··Filters run over block properties instead of over the file tree.
- ··A search for status::done finds actions, not documents.
Transcript
What if classification did not sit in a spreadsheet next to the content, but on the very block that carries the statement? Over the next few minutes you will hear why the Excel list beside the memo becomes a second truth — and how a Tag and a Property dissolve it.
In day-to-day due diligence, content and classification run apart. The memo lives in Word, the status sits in an Excel sheet alongside, with columns for source, deadline and competitor. The moment someone updates the memo, the register drifts. After twelve weeks you find eighteen entries marked review whose source text has long read final. Nobody has erred — the second place has simply not moved along.
That is precisely where the risk sits. Two parallel truths are a question of the audit trail, since the person who maintains the spreadsheet is rarely the person who changes the content. The remedy is not more discipline at reconciling, but placing the classification where the statement already sits.
For this you need two building blocks. The Tag is the flat cross-cutting classification — competitor, risk, vendor, with no hierarchy, for views across domains. The Property is the structured metadata on the block — status set to review, source set to bloomberg, a deadline carrying a date. Key and value, queryable and typed, right on the statement to which they belong.
And now the spreadsheet does not vanish, it becomes a Query. A single query over all blocks with status review replaces the hand-maintained register. The result refreshes the moment a block changes. Whoever wishes to see all open items with a near deadline writes the query once and reads it afresh each day.
For this to hold, you need a convention per domain. Which keys and which values are permitted is fixed once and versioned — otherwise three people write status, statu and Status, and the query comes back empty. One page per domain suffices, and the scatter stops before it begins.
The honest question at the end: how often do you maintain the same information in two places — once in the document, once in the spreadsheet alongside? If the figure is over thrice in a week, the spreadsheet is no longer a view but a second source. Kindly attach the meaning to the block, and your second brain holds the status and the source right where the statement sits.
#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.