Tags + Properties
Classification on the block, not in the table next door.
Transcript
What if classification did not sit in a table 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 table next door, with columns for source, deadline and competitor. The moment someone updates the memo, the table drifts. After twelve weeks you find eighteen entries marked review whose source text long since reads final. Nobody lied — the second place simply did not move along.
That is exactly where the risk sits. Two parallel truths are a question of the audit trail, because whoever keeps the table is rarely the person who changes the content. The cure is not more discipline at reconciling, but putting the classification where the statement already sits.
For that 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 with a date. Key and value, queryable and typed, right on the statement they belong to.
And now the table does not disappear, it becomes a query. A single query over every block with status review replaces the hand-kept register. The result updates the moment a block changes. Anyone who wants to see all open items with a near deadline writes the query once and reads it fresh each day.
For that to hold, you need a convention per domain. Which keys and which values are allowed is decided once and versioned — otherwise three people write status, statu and Status, and the query comes back empty. One page per domain is enough, and the scatter stops before it starts.
The honest question at the end: how often do you keep the same information in two places — once in the document, once in the table next door? If the figure is over three in a week, the table is no longer a view but a second source. Attach the meaning to the block, and your second brain holds status and source where the statement sits.
#wettbewerber, status:: review, quelle:: bloomberg — classification on the block that needs it. No table alongside.
- Classification time per report: −65%
- Table upkeep effort: −80%
- Data consistency source ↔ view: 100%
Why the Excel table 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 since moved to “final”.
5 rules
- Tag = cross-cutting classification. `#wettbewerber`, `#risiko`, `#vendor` — flat, no hierarchy, for views across domains.
- Property = structured metadata. `status:: review`, `quelle:: bloomberg`, `frist:: 2026-06-30` — key–value, queryable, typed (quelle:: is the literal DSL key for “source”).
- Query = living view. One query over every block with `status:: review` replaces the hand-kept table. The result updates the moment a block changes.
- Properties on the page or on 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 on a paragraph).
- A convention per domain. Which keys and values are allowed is set and versioned per domain — not improvised per person.
## Competitor memo Acme
status:: review
quelle:: bloomberg
frist:: 2026-06-30
Q4 revenue came in at £142m #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 updates |
| Audit question “state on 2026-04-12?” → reconcile the file history of two files | Audit question “state on 2026-04-12?” → one version trail, one block |
| Consistency source ↔ view: checkable only by sampling | Consistency source ↔ view: 100% by definition |
The table does not disappear — it becomes a query. Anyone who wants to see “every block with status:: review and frist:: < 2026-07-01” writes the query once and reads it fresh each day.
An honest question
How often do you keep content and its table separately? Count, over this week, the cases where you changed the same information in two places — once in the document, once in the register.
Classification that keeps itself.
Attach the meaning to the block, not to the table next door. Your second brain holds status and source where the statement sits — a companion, not a second set of books.
Reserve your slot··free →