Tags + Properties
Tag og Property hører til på blokken — ikke i et side-panel-træ, der overlever enhver omstrukturering.
- ··Klassifikation på atomet — Tag/Property som inline-DSL på blokken (#wettbewerber, status::offen).
- ··Filtre kører over blok-egenskaber i stedet for over fil-træet.
- ··En søgning på status::done finder handlinger, ikke dokumenter.
Transskription
Hvad nu hvis klassifikationen ikke lå i en tabel ved siden af indholdet, men på netop den blok, der bærer udsagnet? I de næste minutter hører du, hvorfor Excel-listen ved siden af notatet bliver den anden sandhed — og hvordan et Tag og en Property opløser det.
I en due diligence-hverdag løber indhold og klassifikation hver for sig. Notatet lever i Word, status står i en Excel-tabel ved siden af, med kolonner til kilde, frist og konkurrent. Så snart nogen opdaterer notatet, driver registret fra. Efter tolv uger ligger der atten poster med status review, hvis kildetekst for længst står på final. Ingen har løjet — det andet sted er bare ikke fulgt med.
Det er præcis her, risikoen sidder. To parallelle sandheder er et spørgsmål om audit trail, for den, der vedligeholder tabellen, er sjældent den, der ændrer indholdet. Kuren er ikke mere disciplin ved afstemningen, men at sætte klassifikationen dér, hvor udsagnet allerede står.
Til det skal du bruge to byggesten. Tagget er den flade tvær-klassifikation — konkurrent, risiko, leverandør, uden hierarki, til visninger på tværs af domæner. Property er den strukturerede metadata på blokken — status sat til review, kilde sat til bloomberg, en frist med en dato. Nøgle og værdi, søgbar og typet, lige på det udsagn, de hører til.
Og nu forsvinder tabellen ikke, den bliver til en Query. En enkelt forespørgsel over alle blokke med status review afløser det håndholdte register. Resultatet opdaterer sig, så snart en blok ændrer sig. Den, der vil se alle åbne punkter med nær frist, skriver forespørgslen én gang og læser den ny hver dag.
For at det holder, skal du bruge en konvention pr. domæne. Hvilke nøgler og hvilke værdier der er tilladt, fastlægges én gang og versioneres — ellers skriver tre personer status, statu og Status, og forespørgslen rammer i tomrummet. Én side pr. domæne er nok, og spredningen stopper, før den begynder.
Det ærlige spørgsmål til sidst: hvor ofte vedligeholder du den samme oplysning to steder — én gang i dokumentet, én gang i tabellen ved siden af? Er tallet over tre på en uge, er tabellen ikke længere en visning, men en anden kilde. Hæng betydningen på blokken, og din anden hjerne holder status og kilde dér, hvor udsagnet står.
#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.