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, baut mium··Falktron, Oelde

EXECUTIVE SUMMARY

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

−65%

Classification time

−80%

Table upkeep effort

100%

Consistency source ↔ view

Parallel registers

1 query

Hand upkeep → query

£0

Toolchain cost

RISKS

Without a domain convention, keys and values sprawl — three people write status::, statu:: and Status::, and the query comes back empty.
Properties on the block take discipline to set; tagging 1,000 blocks after the fact is dearer than doing it from the start.
Tag sprawl with no curated core leads to synonym islands — #wettbewerber alongside #competitor alongside #wb.

DECISION

Recommendation — move classification onto the block (tags + properties) and retire parallel status tables as a living query; version the required fields per domain.

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