01
Continuous
Incitatus runs without a release cycle. There is no "v3 next year" — instead, models are refined hour by hour against the latest accumulated signal. The protection a Silbad product carries today is no older than the last refresh.
Bucephalus, Marengo, Babieca and Chetak look very different to their respective audiences — a bank's compliance team, a central bank's financial-stability desk, an internal-audit function, an economic-crime investigator. What they share is Incitatus. Lindwurm reasons; Incitatus builds the models. Incitatus is Silbad's model-development infrastructure, built on Lindwurm: it continuously develops, evaluates and refreshes the domain models every Silbad product runs on — while detection and reasoning themselves are performed by Lindwurm, Lile's neuro-symbolic reasoning engine.
Incitatus is not sold separately, and it is not exposed as a product API. It runs inside Silbad infrastructure and ships its outputs — refined models — to the deployable products inside our customers' environments.
Three structural characteristics define Incitatus and explain why every Silbad product can carry the same depth of modelling without re-implementing it.
Incitatus runs without a release cycle. There is no "v3 next year" — instead, models are refined hour by hour against the latest accumulated signal. The protection a Silbad product carries today is no older than the last refresh.
Thousands of model variants are developed simultaneously, evaluated against millions of evolving signals every hour. The objective is not a single best-fit model but a living portfolio of variants — different emphases, blind spots, time horizons — that the deployable products choose from for a given context.
The engine runs on infrastructure built for this single purpose, not on a shared cloud tenancy. Compute, storage and networking are tuned for the modelling workload, isolated from customer-facing systems, and operated under the same European regulatory frame as everything else Silbad does.
The model factory is deliberately separated from the deployable products by a federated boundary. The products run inside the customer's environment; Incitatus runs in Silbad's. What crosses between them is mathematics, not records.
Develops, validates and refines model variants against accumulated abstract signals. Holds no customer transaction data, no customer counterparty data and no personally identifying information.
Receives refined models from the engine and applies them locally against customer-resident data. Sends back only mathematical signals — no records, no identities, no transaction details.
The boundary is enforced by architecture, not by policy. Even if a Silbad engineer wanted to read customer data through the engine, the system contains none to read — it never arrives at the engine in the first place. This is the structural form of GDPR and banking-secrecy compliance that the public engagement page describes from the citizen's perspective.
A single model — however well-tuned — has a fixed point of view. Incitatus runs many variants in parallel because financial-crime patterns shift, evolve and diverge faster than any one model can keep up with.
Some variants weight transactional anomalies; others weight counterparty graphs; others, behavioural drift. Combined, they cover the territory a single architecture would force a trade-off on.
Real-time scoring asks one question; retrospective forensic analysis asks another. Variants are tuned for both, so the products that need each can draw on appropriate models without a forced compromise.
A coordinated SFMA attack signature differs from the signature of a single-actor mule network or an insider-collusion ring. Different variants carry different prior assumptions about who is on the other side.
The same underlying pattern can be a "high-priority alert" in one jurisdiction and "informational" in another, depending on the local regulatory taxonomy. Variants encode the regulatory frame so the deployable products do not have to.
The four deployable products draw from the same engine but apply it to different audiences and operational frames.
Incitatus is part of Silbad's internal infrastructure. It is not licensed separately, not exposed as a public API, and not packaged as a developer-facing platform. The engagement model with Silbad is always at the deployable-product level — Bucephalus, Marengo, Babieca, Chetak — and Incitatus comes along for the ride as the engine those products run on.
The reason is simple: the engine's value is realised in the form of a deployable, regulated, auditable product inside the customer's environment. Selling the engine alone would dilute the regulatory frame that makes the deployable products defensible.