Products
Alongside the advisory work, Ferantos is building a suite of governance-aware tools in the same space. The first is Cadastral.
Cadastral
Hold the thread of your architecture as AI accelerates the pace of change.
Cadastral does for software estates what a cadastre does for land. It encodes your domain as a formal model (objects, relationships, and a bounded vocabulary) that wraps every intended change in a declaration of what will shift, and checks on completion whether delivery matched intent, what drifted, and what evidence backs the claim.
It holds the longitudinal record of an architecture: what changed, what's planned, and what the system is becoming, kept as a live working artefact rather than a documentation aside.
The ideas it's built on
A set of connected concepts we've been developing in depth. We're actively developing this now, and we'll be showing more soon.
Why a tool of this shape.
-
Around, not inside
A symbolic frame around the agents, not inside them.
The aim of neurosymbolic AI is to embed deterministic symbolic systems inside an LLM. It's an active area of research but not yet as useful as current LLMs. Cadastral inverts this idea; it's a persistent, governed structure that sits around the coding agents, holding checkable representations of what was decided, what's in scope, what must not break, over time and across a potentially large software estate.
The two layers Cadastral executes on.
-
Capability model & interfaces
Model the work by what needs doing, not who does it.
Work is organised into capability areas: named domains of concern, independent of who performs them. Each publishes an interface of inputs, outputs, and triggers, so the operating model becomes a graph that work flows through.
-
The subject model
A live map of what's load-bearing in your system.
A typed graph of a project's load-bearing concepts: the structures that are expensive to change. Artefact mapping links each concept to the code and documents that realise it, and the document graph keeps those references queryable.
How change is declared and governed.
-
Proposed Change Set
Every change wrapped in a checkable declaration.
Each intended change is described as a Proposed Change Set, which is a structured statement of what will shift, and checked deterministically against the model before it's merged or approved. Governance is zoned: core areas need human approval, peripheral ones may move on their own.
-
Plan-as-code
Declare intent as code; verify delivery matched it.
A plan declares, in machine-checkable form, what it will add, modify, remove, and preserve. After the work is submitted, Cadastral compares intent against the actual change and reports what was delivered, what drifted, and what evidence backs each claim.
The software realisation, and where it scales.
-
Executable architecture
Architecture that's enforced, not just illustrated.
Dependency rules, interface contracts, ownership boundaries, and principles become structured constraints the system enforces on every change, not boxes on a page. Cheap deterministic checks catch most drift; review handles the rest, and the review task itself is highly structured by the system.
-
Estate & scoping
One living architecture across every team and repo.
Real systems sit inside an estate of related projects with shared principles and contracts. Cadastral's model spans that estate through federated, scoped instances that compose into one coherent, governed architecture.
Interested in Cadastral?
We're sharing it with a small number of early teams as it takes shape. If the problem resonates, we'd like to hear from you.
Get in touch