DNA — unified metadata for composable apps

The Problem

HR.net already delivered one HR platform across multiple countries, but every metadata type had its own storage, structure, and services. Cross-feature enhancements and localizations were achievable, but only up to a point — some still needed custom scripts or copied/duplicated metadata to work around the fragmentation. We built mechanisms within HR.net to ease this, but the underlying per-type fragmentation remained.

As Lifion started greenfield, that was the opportunity to address the root cause rather than keep working around it.

The Goal

• Unify type definitions, algorithms, and services into a single consistent schema from the start, rather than continuing to patch around per-type fragmentation.
• Compose the right version of an app per request from shared, layered parts, instead of custom scripts, copied metadata, or duplicate builds.
• Make localization and customization a configuration-time concern, not a build-time or script-time one.

The Approach

• DNA — a single schema defining the rules all metadata types follow, replacing the prior per-type fragmentation with one consistent model.
• Capsules — on top of DNA, metadata objects are grouped into capsules. Every feature has one "global" capsule, always included at runtime, plus one or more capsules scoped to a specific context — typically a localization (e.g., US, GB).
• Ownership — each piece of metadata is owned by exactly one capsule: global if it's shared or localizable by default (e.g., the base address UI), or a context-specific capsule if it's a localization override (e.g., address UI under the US capsule).
• Two kinds of layering — localization (the same address-capture UI composed differently for US vs. UK, no duplicate definitions) and cross-feature enhancement (enabling both Time & Attendance and Payroll let Time & Attendance extend Payroll with PTO capabilities — only when both were enabled).
• Deterministic composition — the same inputs and enabled modules always produced the same output.
• The compiler — I designed and wrote it myself: the DNA model, the layering/override semantics, and the composition pipeline implementing the core algorithm described in the patent — flattening and hydrating, turning DNA's flat stored format into the hierarchical structure runtime consumers like the UI renderer and business rules engine need. After I handed it off, a team maintained it and added caching to improve reuse of compiled variants in production.

Co-inventor on US Patent 10,558,436 ("Dynamically Composing Products Using Capsules"), which describes this composition mechanism; the compiler is part of how it's implemented in production.

The Impact

• Every other platform service consumed the compiler — it became the foundation the entire shipped HCM product was built on, not a feature confined to one area.
• Verified correctness at two levels: unit tests on the composition algorithm itself, and scenario tests confirming compiled output met localization and override requirements.
• After handoff, the team's caching work targeted production efficiency of compiled variants; I don't have measured performance numbers to cite, so I'm not claiming a specific gain there.