One thesis about the world and four rules every product has to pass. They explain why the products look and behave the way they do, and they are the standard you can hold us to.
Every application collects more data than it uses. Orders, events, readings, logs, the results of every decision the software already made. The gap between what is collected and what is understood is where most of the value in a business sits, and the tools decide whether that gap closes.
For a decade the tools that closed it were Python tools. Notebooks, DataFrames, a rich ecosystem of connectors and plots. .NET teams built the applications that produced the data and then left the platform to look at it: a sidecar script, a spreadsheet, a warehouse someone else owned. Every hop lost context, and every hop was a reason not to look.
We think that is a tooling problem, not a platform problem. .NET is fast, typed, and already running in the place where the data is born. What it never got was a data layer, an exploration loop, and a way to verify what came out the other end. Those are the three products.
.NET builds the applications. It never got the tools for the data inside them.
The same gap is opening again for AI agents. An agent that works beside a developer needs to query the data, run the notebook, and drive the browser, through the same surfaces the developer uses. So the products expose themselves to agents on purpose: Verso ships language-model tools that let an agent run cells and read outputs, and Motus ships an MCP server that lets one drive a real browser.
No Node.js sidecars, no Python bridges, no bundled driver binaries. A tool built for .NET should install with dotnet add package, run inside your process, debug with your debugger, and deploy with your application.
This is why Motus speaks CDP and WebDriver BiDi itself instead of wrapping a JavaScript framework, why the Verso engine is a NuGet library rather than a kernel process, and why the SDK's core has no external dependencies. Borrowed runtimes are borrowed problems: a second toolchain in CI, a second set of versions to match, a process boundary between you and the thing you are trying to control.
Every built-in feature is implemented on the same public interfaces available to any third party. There are no private APIs for first-party code.
In Verso, the notebook surface is a layout and layouts are extensions; the kernels, formatters, and panels ship on the interfaces in Verso.Abstractions. In Motus, every selector strategy, wait condition, lifecycle hook, and reporter registers through the same plugin context you would use. The rule is expensive, and that is the point:
If the extension surface is not good enough for our own features, it is not good enough to ship.
When something we need is missing from the public surface, we add it to the public surface, not to a back door.
Verso and Motus are MIT licensed and developed in public: the repositories, the issues, the release notes, and the documentation are the same ones we work from. The license will not change under you. We contribute under a Developer Certificate of Origin, and so does everyone else.
The Datafication SDK is a commercial product, and it says so up front. It is free for small teams and open-source projects and licensed for larger organizations. We would rather be clear about what is open and what pays for the open parts than blur the two.
Every product began as something we needed. The SDK grew out of building data products for other people. Verso grew out of wanting a place to look at what the SDK produced. Motus grew out of testing Verso's browser host and refusing to install a Node.js toolchain to do it. We still use all three every day, which is the fastest way to find out what is wrong with them.
Documentation is written alongside the code, not after it, and the docs on the product sites are generated from the same markdown that lives in the repositories. When a feature ships, its guide ships with it.
If a product violates one of these rules, tell us. The address is support@datafication.co, and it reaches the people who write the code. The public repositories accept issues, and the blog records the decisions behind each release so you can see the reasoning, not just the result.