Tags + Properties

Team Mut···last changed 2026-05-15

#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

1. Tag = cross-cutting classification. `#wettbewerber`, `#risiko`, `#vendor` — flat, no hierarchy, for views across domains.
2. Property = structured metadata. `status:: review`, `quelle:: bloomberg`, `frist:: 2026-06-30` — key–value, queryable, typed (quelle:: is the literal DSL key for “source”).
3. Query = living view. One query over every block with `status:: review` replaces the hand-kept table. The result updates the moment a block changes.
4. 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).
5. 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 #wettbewerber

Before and after — Excel list vs block with status:: review

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.