The through-line
Derivative Centric Development is the methodology underneath how Genval has built software for years. The principle is constant: the source of truth lives upstream, and downstream artifacts are derived from it. AI generates the derivations; humans own the source.
What's changed across the past decade is not the principle. It's the substrate — the shape of the source you actually edit. We've worked through three eras, and each one taught us why the next one mattered.
Three eras of derivation
Era 01 — Code-centric (the 2010s)
The source was a typed language artifact — a C# interface, a TypeScript type, an OpenAPI document. Code generators read those artifacts and produced clients, server stubs, integration scaffolding. Tools like Swagger, NSwag, GraphQL Code Generator, and a long tail of in-house generators all worked the same way: language types in, language code out.
This worked, but it was bounded. Sources were tied to one language ecosystem. Sharing them across organizations meant translating; evolving them meant breaking downstream consumers. The substrate was strong on types and weak on portability.
Era 02 — Markdown-centric (2024)
The first generation of the Genval platform. The source became Markdown specifications, and frontier LLMs reasoned across them to produce implementations spanning many files at once. This is what the industry now calls spec-driven development.
What we gained was language-neutrality, human-readability, and version-controllable specs that read like documentation. What we hit was the cost of being untyped. The LLM had to infer structure on every read. Two specs referring to the same concept used different words; downstream tools had no machine-checkable contract. There was no semantic versioning across specs, and no cross-organizational referencing — you couldn't safely import another team's spec the way you import a library.
Era 03 — Ontology-centric (today, on Kanonak)
The source is a typed ontology — a Kanonak package with classes, properties, instances, and stable publisher/package@version/name URIs. Derivation happens against the typed entities directly, not against natural language. The same recursive dispatch produces every output format the system needs.
Markdown becomes an output format, not the source. So does HTML. So does JSON. So does a DynamoDB attribute-value tree. So does an SVG.
The principle is constant
DCD doesn't change. In every era you have a source and you have derivations. What evolves is the substrate. The mindset — design upstream, derive downstream — survives the migration; the tooling changes underneath. That's why we still call this Derivative Centric Development: the methodology outlasts every era.
Universal derivations
The clearest illustration of ontology-centric DCD is the open-source universal-derivations package. It defines a single transformation that recursively dispatches over the value type — IsList, IsEmbedded, IsReference, IsBoolean, IsNumber, IsString — and produces typed structural output that backend bindings serialize into HTML, Markdown, JSON, DynamoDB-JSON, SVG, or a stylesheet.
The author of a new ontology doesn't write a derivation. They declare types. The formats fall out.
Why ontologies are the right substrate
- Types let derivations reason precisely instead of inferring shape on every read.
- Semantic versioning means a source can evolve and consumers can pin against a specific version — the same discipline as a library.
- URI-addressable — every entity has a stable
publisher/package@version/nameidentifier. Cross-organizational references work without a central registry. - Distributed publishing. Anyone with a domain can publish; consumers resolve imports over HTTP.
- Markdown, HTML, JSON become outputs — generated on demand, never the bottleneck.
Worldview — DCD in production
Worldview is the canonical real-world demonstration. It publishes a daily macro-market worldview as versioned Kanonak snapshots — typed theses with confidence levels, machine-evaluable invalidation conditions (AND / OR / Threshold / Event / Sequenced logic trees), and citation-backed evidence. Each snapshot is a frozen, typed ontology; the Timeline view traces how each thesis's confidence evolves across versions. This is ontology-centric DCD applied to a domain that changes daily.
Worldview also extends the derivation system itself. The worldview-chrome package defines custom SVG renderers for Worldview's typed resources, with a four-tier semantic-zoom convention — chip → icon → card → full — so one typed source produces an appropriate visual at every rendered size, from inline character-level chips to billboard-density layouts. Custom derivations stack on top of universal-derivations to specialize output where it matters; the rest falls out of the type system for free.
Conclusion
Derivative Centric Development is the through-line in how Genval has built software for years. The principle — source upstream, derivations downstream — outlasted code-centric tooling, outlasted Markdown-centric platforms, and now sits on typed ontologies via Kanonak. We don't think the substrate is done evolving. But the methodology is what carries forward.