gedankenexperiment / philipp warmer
sign in contact

Gedankenexperiment Snippets

Regulated industries have already built their semantic layer

The contracts, lineage and field descriptions already exist. What's missing is one place an agent can read them all at once.

Snippet · August 2026

The semantic layer inside a regulated firm already exists. It sits in the data contracts, the named owners, the service levels, the lineage and the field descriptions that supervisors require, written down over years to a level of detail an auditor checks line by line. Any firm with serious data governance holds the same records; regulation only makes them non-optional.

A semantic layer is the shared answer to plain questions: what counts as an active policy, which field holds the premium, how a claim links back to a customer. Until recently the dependable way to hold those answers in software was to build a separate system for them, with its own language, release process and team. Route A in Fig. 1 is that build, and it still earns its keep wherever a firm wants its definitions written in one place and versioned.

TWO ROUTES · FIG. 01 Build the layer, or connect what you have Both routes reach the same answers. Route B runs on records your platform already keeps: contracts, service levels, named owners, lineage and field-level descriptions. ABuild a separate semantic layer and keep it runningSOURCESCore systemCRMExternalDATA PLATFORMDATA PRODUCTContractSLAOwnershipLineageField-level descriptionsRAWCORESERVINGUSE CASESReportingAnalyticsAgentsSEMANTICLAYERDefinitionsJoinsMetricsOperationsneeds active alignment BConnect the records the platform already keepsSOURCESCore systemCRMExternalDATA PLATFORMDATA PRODUCTContractSLAOwnershipLineageField-level descriptionsRAWCORESERVINGUSE CASESReportingAnalyticsAgentsaligned by default Route B adds nothing to operate. It asks that the records be readable by machines and kept current. GEDANKENEXPERIMENT

The difference is whether alignment is something you do. Route A holds the same logic twice, once in the data products and again in the semantic layer, so someone has to align the two on every release, and that work grows with each extension to either side. It is the real cost of the build, not the build itself. Route B holds the logic once, so alignment is not a task at all — there is no second copy to align it with.

What's new is that models can read the answers where they already sit. A field description that explains the field, together with lineage showing where the value came from, is enough for an agent to choose the right join and the right filter the moment a question arrives. Careful writing in the catalog now does the work a modeling language used to do.

The catch is that these records live apart. Contracts sit in one tool, lineage in a second, descriptions in the catalog, ownership in a governance register, and each was built for a human reader with a specific job. An agent asking a single question has to reach all of them together, which is why one unified interface over the existing artifacts is the whole task. Put the contract, the owner, the service level, the lineage and the field descriptions behind one endpoint that answers in a form a model can use, and the layer switches on.

So the next step is narrow enough to schedule. Expose those five things through a single interface on top of the data products you already publish, keep the descriptions accurate, and fix the field comments that point at a specification document instead of explaining the field. Each one you fix pays off twice, once for the auditor and once for the answer.

Gedankenexperiment · Zurich