Tags + Properties
Hvad nu hvis klassifikationen ikke lå i en tabel ved siden af indholdet, men på selve blokken — søgbar, konsistent, uden dobbelt vedligehold? Tags og Properties sænker klassifikations-tiden pr. rapport med omkring 65 % og vedligeholdet af tabeller med 80 %, mens konsistensen mellem kilde og visning pr. definition ligger på 100 %.
- Uden en domæne-konvention vokser nøgler og værdier vildt — tre personer skriver status::, statu:: og Status::, og forespørgslen rammer i tomrummet.
- Properties på blokken kræver disciplin ved oprettelsen; at tagge 1.000 blokke bagefter er dyrere end at gøre det fra begyndelsen.
- Tag-vildvækst uden en kurateret kerne fører til synonym-øer — #wettbewerber ved siden af #competitor ved siden af #wb.
#wettbewerber, status:: review, source:: bloomberg — klassifikation på netop den blok, der har brug for den. Ingen tabel ved siden af.
- Klassifikations-tid pr. rapport: −65 %
- Vedligehold af tabeller: −80 %
- Datakonsistens kilde ↔ visning: 100 %
Hvorfor Excel-tabellen bliver den anden sandhed
I en due diligence-hverdag løber indhold og klassifikation hver for sig — notater i Word, et Excel-register med status, kilde og konkurrent ved siden af. Så snart et notat opdateres, driver registret fra. Efter 12 uger ligger der 18 poster med status „review“, hvis kildetekst for længst står på „final“.
5 regler
- Tag = tvær-klassifikation. `#wettbewerber`, `#risiko`, `#vendor` — flad, uden hierarki, til visninger på tværs af domæner.
- Property = struktureret metadata. `status:: review`, `quelle:: bloomberg` (DSL-nøglen for kilde), `frist:: 2026-06-30` — nøgle-værdi, søgbar, typet.
- Query = levende visning. En forespørgsel over alle blokke med `status:: review` afløser den håndholdte tabel. Resultatet opdaterer sig, så snart en blok ændrer sig.
- Properties på Page eller Block. En Page-Property gælder for hele dokumentet (klient, kontrakttype). En Block-Property gælder for udsagnet (kilden til et tal, fristen for et afsnit).
- Konvention pr. domæne. Hvilke nøgler og værdier der er tilladt, fastlægges pr. domæne og versioneres — ikke improviseret pr. person.
## Konkurrent-notat Acme
status:: review
quelle:: bloomberg
frist:: 2026-06-30
Omsætning Q4 lå på 1.060 mio. kr. #wettbewerberFør/efter — Excel-liste vs. blok med status:: review
| Før (Excel ved siden af) | Efter (Property på blokken) |
|---|---|
| Notat i Word, post i tracker.xlsx række 47 | Blokken i notatet bærer `status:: review` |
| Statusskift: åbn to filer, gem begge | Statusskift: ændr én værdi, visningen opdaterer sig |
| Audit-spørgsmål „stand 2026-04-12?“ → sammenhold fil-historik for to filer | Audit-spørgsmål „stand 2026-04-12?“ → ét versionsspor, én blok |
| Konsistens kilde ↔ visning: kun kontrollerbar ved stikprøve | Konsistens kilde ↔ visning: pr. definition 100 % |
Tabellen forsvinder ikke — den bliver til en Query. Den, der vil se „alle blokke med status:: review og frist:: < 2026-07-01“, skriver forespørgslen én gang og læser den ny hver dag.
Et ærligt spørgsmål
Hvor ofte vedligeholder du indhold og dets tabel hver for sig? Tæl i den løbende uge de gange, hvor du har ændret den samme oplysning to steder — én gang i dokumentet, én gang i registret.