FALKTRON GMBH··BRIEF

Knowledge that works. — Oelde, Geiststraße 53.

AUTHOR	DATE	AUDIT ID	VERSION
Team Mut	2026-05-15	BRF-tags-properties-v1.0	v1.0

BRIEF··

Tags + Properties

Submitted by Team Mut, builds mium··Falktron, Oelde

EXECUTIVE SUMMARY

What if classification did not sit in a spreadsheet next to the content, but on the block itself — queryable, consistent, with no double upkeep? Tags and Properties cut the classification time per report by around 65% and the spreadsheet upkeep effort by 80%, while consistency between source and view stands at 100% by definition.

−65%

Classification time

−80%

Spreadsheet upkeep effort

100%

Consistency source ↔ view

Parallel registers

1 Query

Hand-upkeep → query

₹0

Toolchain cost

RISKS

Without a domain convention, keys and values run wild — three people write status::, statu:: and Status::, and the Query comes back empty.
Properties on the block demand discipline at the point of entry; tagging 1,000 blocks after the fact is costlier than doing it from the start.
Tag sprawl without a curated core leads to synonym islands — #wettbewerber beside #competitor beside #wb.

DECISION

Recommendation — move classification onto the block (Tags + Properties) and replace parallel status spreadsheets with a living Query; version the mandatory fields per domain.

#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 #wettbewerber

Before 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.